1.6.1

Description

Abstract

Fix errors on CheckMessageDepsUpdate workflow

Description

Use non-containerized environment

Related Issues

1.6.0

Caution

This release was created by miss operation.
There are no additional changes with this release.

Description

Description

Abstract

• consider z-axis in euclidean distance evaluation
• fit pitch angle of entity poses to HDMap
• add consider_pose_by_road_slope flag to switch function
• update new scenarios and tests

Note: All the features can be toggled by consider_pose_by_road_slope.

Background

One of the characteristics of scenario_simualtor_v2 is that it is a simple and lightweight simulator.
Therefore, we have mainly dealt with simulations on a 2D plane without considering the Z direction or pitch/roll axes.

However, as the behavior on slopes is now being checked in autoware developing, simulation on a 2D plane alone is no longer able to cover the evaluation of Planning/Control, which is the main evaluation target of scenario_simualtor_v2.

So, we started to support simulation on 3D pose.

Details

Note: I would like to thank @dmoszynski for his great efforts for this pull-request.

Entity pose pitch-fitting to HDMap

As long as lane matching is successful, scenario_simulator_v2 tries to constrain the pose on the HDMap.
Specifically, the situation is as follows.

• spawning entity to position: OpenSCENARIO AddEntityAction
• teleporting entity to position: OpenSCENARIO TeleportAction
• setting goal: OpenSCENARIO AcquirePositionAction
• setting route
  • OpenSCENARIO FollowTrajectoryAction
  • OpenSCENARIO AssignRouteAction

The z fitting to HDMap was already performed in scenario_simulator_v2 until now.
But the entity pose fitting was not complete until now: pitch and roll angle were not fitted to HDMap.
In this pull-request, pitch-fitting is implemented.

With OpenSCENARIO WorldPosition / RelativeWorldPosition / RelativeObjectPosition, scenario_simulator_v2 will be performing both of z-fitting and pitch-fitting.
With OpenSCENARIO LanePosition, scenario_simulator_v2 will be performing only pitch fitting.
( Other position types are not supported in scenario_simulator_v2 now )

The pitch-fitting is also affected to bounding-box-based distance evaluation(freespace=true), because the orientation of entity bounding-box can be changed by pitch-fitting.

Distance evaluation

The euclidean distance evaluation in OpenSCENARIO DistanceCondition / RelativeDistanceCondition / ReachPositionCondition is performed in 2D plane previously.
In this pull-request, I implemented 3D euclidean dintance evaluation.

References

INTERNAL INVESTIGATION LINK

Regression Test: Pass

Destructive Changes

behavior changes

Some of OpenSCENARIO Actions, Conditions, traffic_simulator::API functions have destructive changes in terms of the behavior.
Please see detail section for a detailed explanation of the behavior changes.
All bahavior changes are caused by sloped or uneven roads on the map.
There should be almost no difference on a flat map, but there are some changes, so you may need to modify the scenario.
However, these changes correct what was wrong in the past, so it is recommended that you accept them.
If you really want to use the old behavior, please use the version before this pull-request or specify consider_pose_by_road_slope=False.
There are some destructive behavior changes
Some of scenarios or APIs behaviors are changed as mentioned in detail section.

API schema changes

In this pull-request, some of API functions were added a boolean argument to toggle its behavior.
But the changes have backward-compatibility in terms of API interface, because all the additional argument have default value.

Known Limitations

No roll-fitting to HDMap

In this pull-request, orientation fitting is implemented for pitch angle only.
This is because it follows the implementation of simple_planning_simulator in autoware.universe.

No orientation-fitting to HDMap in OccupancyGridSensor

The GridMap output from scenario_simulator_v2 is always horizontal regardless of the road slope.
This is because current implementation of autoware.universe does not consider the roll and pitch axes.

Related Issues

1.5.1

Description

Abstract

scenario_simulator_v2 starts to recording the /planning/scenario_planning/lane_driving/behavior_planning/behavior_velocity_planner/debug/intersection topic again.

Background

In #829, the /planning/scenario_planning/lane_driving/behavior_planning/behavior_velocity_planner/debug/intersection topic has excluded from recording target due to its so large size.
But after autowarefoundation/autoware.universe#1483, Internal research has confirmed that the size has improved significantly.

Details

N/A

References

#829
autowarefoundation/autoware.universe#1483

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

1.5.0

Description

Abstract

• consider z-axis in euclidean distance evaluation
• fit pitch angle of entity poses to HDMap
• add consider_pose_by_road_slope flag to switch function
• update new scenarios and tests

Note: All the features can be toggled by consider_pose_by_road_slope.

Background

One of the characteristics of scenario_simualtor_v2 is that it is a simple and lightweight simulator.
Therefore, we have mainly dealt with simulations on a 2D plane without considering the Z direction or pitch/roll axes.

However, as the behavior on slopes is now being checked in autoware developing, simulation on a 2D plane alone is no longer able to cover the evaluation of Planning/Control, which is the main evaluation target of scenario_simualtor_v2.

So, we started to support simulation on 3D pose.

Details

Note: I would like to thank @dmoszynski for his great efforts for this pull-request.

Entity pose pitch-fitting to HDMap

As long as lane matching is successful, scenario_simulator_v2 tries to constrain the pose on the HDMap.
Specifically, the situation is as follows.

• spawning entity to position: OpenSCENARIO AddEntityAction
• teleporting entity to position: OpenSCENARIO TeleportAction
• setting goal: OpenSCENARIO AcquirePositionAction
• setting route
  • OpenSCENARIO FollowTrajectoryAction
  • OpenSCENARIO AssignRouteAction

The z fitting to HDMap was already performed in scenario_simulator_v2 until now.
But the entity pose fitting was not complete until now: pitch and roll angle were not fitted to HDMap.
In this pull-request, pitch-fitting is implemented.

With OpenSCENARIO WorldPosition / RelativeWorldPosition / RelativeObjectPosition, scenario_simulator_v2 will be performing both of z-fitting and pitch-fitting.
With OpenSCENARIO LanePosition, scenario_simulator_v2 will be performing only pitch fitting.
( Other position types are not supported in scenario_simulator_v2 now )

The pitch-fitting is also affected to bounding-box-based distance evaluation(freespace=true), because the orientation of entity bounding-box can be changed by pitch-fitting.

Distance evaluation

The euclidean distance evaluation in OpenSCENARIO DistanceCondition / RelativeDistanceCondition / ReachPositionCondition is performed in 2D plane previously.
In this pull-request, I implemented 3D euclidean dintance evaluation.

References

INTERNAL INVESTIGATION LINK

Regression Test: Pass

Destructive Changes

No API breaking changes, but some of API functions have additional options with backward compatibility.
Some of scenarios or APIs behaviors are changed as mentioned in detail section.
There should be almost no difference on a flat map, but there are some changes, so you may need to modify the scenario.
However, these changes correct what was wrong in the past, so it is recommended that you accept them.
If you really want to use the old behavior, please use the version before this pull-request or specify consider_pose_by_road_slope=False.

Known Limitations

No roll-fitting to HDMap

In this pull-request, orientation fitting is implemented for pitch angle only.
This is because it follows the implementation of simple_planning_simulator in autoware.universe.

No orientation-fitting to HDMap in OccupancyGridSensor

The GridMap output from scenario_simulator_v2 is always horizontal regardless of the road slope.
This is because current implementation of autoware.universe does not consider the roll and pitch axes.

Related Issues

1.4.2

Description

Abstract

Update reusable workflow / external workflow in GitHub Actions workflows.

Background

External workflow versions were different for each workflow, some of them were outdated.

Details

Update external workflow and refactor some workflows.

Note: Docker workflow will be updated by #1141 , so not modified

References

None

Destructive Changes

None

Known Limitations

None

1.4.1

Description

Abstract

This PR will add some Actions workflow to track updates of ROS 2 message definition(msgs) files.

Background

When msgs changes, we sometimes need to modify simulator to adopt these changes.
The change could not be known until someone on the team noticed.
Therefore, This PR will establish a workflow for automatic notification of changes.

Details

• Add Python scripts to notify changes by following procedure.
  1. Scan all source code to extract all used msgs.
  2. Check recent updates of msgs by git log command
  3. Post it to automated issues #1203
• Add workflow to run the script every Monday.

Destructive Changes

None

Known Limitations

The script does not scan ROS 2 official msgs. It will scan autoware msgs.

Related Issues

1.4.0

Description

Abstract

Ego moved too fast (did not respect the limits) in the case of the 2 test scenarios shared on jira RJD-834.

• The main cause was the not passing of the maxSpeed controller parameter to FollowTrajectoryAction - when action is used in EgoEntitySimulation as an Autoware "disturbance".
• In addition, I’ve noticed that FollowTrajectoryAction does not take into account the speed limits from lanelet2.

Changes related to this issue:

• Moved execution of FollowTrajectoryAction from EgoEntitySimulation to EgoVehicle - added a flag to activate action update. Also ensured that Ego status is overwritten only for this action.

• Added ability to setup FollowTrajectoryAction (used in cooperation with Autoware) parameters via requestSpeedChange and setVelocityLimit in EgoVehicle

• Added setting of lanelet_pose to FollowTrajectoryAction update - without this, the EntityStatus after makeUpdatedStatus had lanelet_pose_valid = false which did not allow lanelet2 limits to be processed.
  Note: matching_distance equal to 3.0 is necessary to ensure that the lanelet2 position updates successfully for the scenarios from this task.

• Added setup of waypoints in route_planner when using FollowTrajectoryAction - this is necessary in order to obtain correct lanelet2 limits using route_lanelets VehicleEntity::requestFollowTrajectory, route_lanelets are used here.

• Added consideration of current linear speed in the FollowTrajectoryAction in the behavior tree pedestrian_tree, vehicle_tree and in ego_entity_simulation - If target_speed is set its value is used, if it is not set then the value of the current linear speed is used. lanelet2 limit is completely ignored because of using FollowTrajectoryAction outside lanelet2.

Background

Changes unrelated to the issue:

• Added to FollowTrajectoryAction the case when a waypoint is passed in a step innerProduct < 0.0 - also improved the calculation of current_velocity.

• Added small improvement to FollowTrajectoryAction - part without waypoint arrival time follow_waypoint_controller.

Details

Video showing the run of a FollowTrajectoryAction for Ego controlled by Autoware. target_speed is taken as the current linear speed at the time when the action is triggered.

video_1280.mp4

Destructive Changes

• Now if the time to arrive at any waypoint is not defined and target_speed is not set, its value is taken as the current speed, previously it was the maximum speed from BehaviorParameter (default 50 m/s).
• EgoEntity::getBehaviorParameter() has been modified, removed the assignment of max_acceleration = 0 to the returned BehaviorParameter.

Related Issues

1.3.1

Description

Abstract

A non-intuitive package arrangement was identified and corrected.

Background

• The openscenario_visualization_components is not related to OpenSCENARIO, it is just visualize traffic simulation result.
• Some of the rviz plugins does not in rviz_plugins directory.
  

Details

• The openscenario_visualization_components is not related to OpenSCENARIO, it is just visualize traffic simulation result.
  • Rename openscneario_visualization::OpenScenarioVisualizationComponent into traffic_simulator::VisualizationComponent and move it to traffic_simulator package.
• Some of the rviz plugins does not in rviz_plugins directory.
  
  • Move openscenario_visualization packages to rviz_plugins direcotyr.

References

Since we only moved the code for the visualization part, no regression test was performed except for the GitHub Actions.
Since the path of the rviz file has been changed, the launch file, which reads the rviz file, was tested locally to confirm that it works properly.

Destructive Changes

This pull request just changing directory of source code.
So no destructive changes.

Known Limitations

N/A

Related Issues

1.3.0

Description

Abstract

Add support PULL_OVER as minimul risk manuever behavior in autoware_adapi_v1_msgs/system/msg/MrmState.msg.

Background

N/A

Details

This pull-request alows UserDefinedValueCondition to use PULL_OVER as a value in scenarios like below.

- name: 'a piece of condition group'
  delay: 0
  conditionEdge: none
  ByValueCondition:
    UserDefinedValueCondition:
      value: PULL_OVER
      name: ego.currentMinimumRiskManeuverState.behavior
      rule: equalTo

This pull-request has backward-compatibility.
(No errors are occured with PULL_OVER-less version of autoware_adapi_v1_msgs.)

References

autoware_adapi_v1_msgs/system/msg /MrmState.msg

regression test result (INTERNAL LINK)

Destructive Changes

N/A (See Details section for backward-compatibility)

Known Limitations

N/A

Related Issues

1.2.0

Description

Abstract

• Unify the calculation criteria of threshold values used for lane coordinate system pose calculation to some extent for each Entity.
• Changed MiscObject/Pedestrian Entity to take crosswalks into account.

Background

In #1189 and #1192, it was indicated that the existing lane coordinate system calculations were extremely complex, with different thresholds in various places, etc., and that it was presumed that proper processing was not being done.

Details

• Unify the calculation criteria of threshold values used for lane coordinate system pose calculation to some extent for each Entity.
  • The matching distance values for the pose calculation in the lane coordinate system varied depending on various conditions. These were simplified and changed to basically use the matching distance determined for each Entity.
  • If the entity is the Ego or Vehicle entity, let $L_m$ be the length of the horizontal bar used in the lane coordinate system calculation and the tread of the front wheels be $t_f$ and the tread of the rear wheels be $t_r$. $$L_m = max(t_r, t_f) + 2.0$$
  • If the entity is the Pedestrian or MiscObject entity, let $L_m$ be the length of the horizontal bar used in the lane coordinate system calculation and width of the bounding box be $L_w$ $$L_m = L_w + 2.0$$

• Changed MiscObject/Pedestrian Entity to take crosswalks into account
  • They were set not to be taken into account for all Entities at spawn.

References

Related issues / Pull requests

#1189
This pull request is depends on #1192. This pull request become ready for review after merging #1192.

Regression test result

tier4/sim_evaluation_tools#244

Destructive Changes

Although this Pull Request does not significantly change the processing flow of the existing algorithm, 100% backward compatibility does not exist because some of the thresholds have been changed.
However, it is assumed that the impact will be limited to a level that does not affect the existing scenario.
In fact, it has been confirmed that regression does not occur in existing scenarios.
See test log for details.

Known Limitations

This Pull Request only changes the thresholds of the existing algorithm, and no major processing method changes exist.
Therefore, the specification that the lane coordinate system calculation fails if the horizontal bar extending from the Entity does not touch the curve at the center of the lane remains.

Related Issues