4.2.2

Description

Abstract

This PR contains revisions of the geometry package unit tests.

Details

Test directory of the geometry package has been restructured to resemble directory tree of the corresponding source tree and other, existing test directories.

Tests that have been refactored, now contain descriptions.

List of tests updated in this PR:

1. LineSegment.getPoint_outOfBounds_denormalized
2. LineSegment.getPoint_outOfBounds_normalized
3. LineSegment.getPoint_inside_denormalized
4. LineSegment.getPoint_inside_normalized
5. LineSegment.getPose_denormalized
6. LineSegment.getPose_normalized
7. LineSegment.getPose_pitch
8. LineSegment.isIntersect2D_collinear
9. LineSegment.isIntersect2D_pointInside
10. LineSegment.isIntersect2D_pointOutside
11. LineSegment.isIntersect2D_pointCollinear
12. LineSegment.isIntersect2D_pointOnEnd
13. LineSegment.getIntersection2DSValue_line_vertical
14. LineSegment.getIntersection2DSValue_line_horizontal
15. LineSegment.getIntersection2DSValue_line_bounds
16. LineSegment.getIntersection2DSValue_line_outside
17. LineSegment.getIntersection2DSValue_line_collinear
18. LineSegment.getIntersection2DSValue_point_vertical
19. LineSegment.getIntersection2DSValue_point_horizontal
20. LineSegment.getIntersection2DSValue_point_bounds
21. LineSegment.getIntersection2DSValue_point_outside
22. LineSegment.getIntersection2DIntersect
23. LineSegment.getIntersection2DIdentical
24. Quaternion.operator+
25. Quaternion.operator-
26. Quaternion.operator*
27. Quaternion.operator+=
28. HermiteCurveTest.getTangentVectorDenormalized1
29. HermiteCurveTest.getTangentVectorDenormalized2
30. HermiteCurveTest.getTangentVectorDenormalized3
31. HermiteCurveTest.getTangentVectorDenormalized4
32. HermiteCurveTest.getNormalVectorDenormalized1
33. HermiteCurveTest.getNormalVectorDenormalized2
34. HermiteCurveTest.getNormalVectorDenormalized3
35. HermiteCurveTest.getNormalVectorDenormalized4
36. HermiteCurveTest.getSValueDenormalized
37. Vector3.norm_msgVector
38. Vector3.normalize_zeroLength
39. BoundingBox.toPolygon2D_ZeroPose
40. BoundingBox.toPolygon2D_OnlyTranslation
41. BoundingBox.toPolygon2D_FullPose

References

Jira ticket: internal link

Destructive Changes

There are no destructive changes.

Related Issues

4.2.1

Description

Abstract

This PR contains unit tests for CanonicalizedLaneletPose class, which is a part of traffic_simulator package

Details

List of tests included in this PR:

1. CanonicalizedLaneletPose.CanonicalizedLaneletPose_withRoute_invalid
2. CanonicalizedLaneletPose.CanonicalizedLaneletPose_withRoute
3. CanonicalizedLaneletPose.CanonicalizedLaneletPose_withoutRoute_invalid
4. CanonicalizedLaneletPose.CanonicalizedLaneletPose_withoutRoute
5. CanonicalizedLaneletPose.CanonicalizedLaneletPose_copyConstructor
6. CanonicalizedLaneletPose.CanonicalizedLaneletPose_moveConstructor
7. CanonicalizedLaneletPose.copyAssignment
8. CanonicalizedLaneletPose.conversionLaneletPose
9. CanonicalizedLaneletPose.conversionPose
10. CanonicalizedLaneletPose.hasAlternativeLaneletPose_true
11. CanonicalizedLaneletPose.hasAlternativeLaneletPose_false
12. CanonicalizedLaneletPose.getAlternativeLaneletPoseBaseOnShortestRouteFrom_empty
13. CanonicalizedLaneletPose.getAlternativeLaneletPoseBaseOnShortestRouteFrom_single
14. CanonicalizedLaneletPose.getAlternativeLaneletPoseBaseOnShortestRouteFrom_multiple
15. CanonicalizedLaneletPose.setConsiderPoseByRoadSlope
16. CanonicalizedLaneletPose.getConsiderPoseByRoadSlope
17. CanonicalizedLaneletPose.operatorLessEqual
18. CanonicalizedLaneletPose.operatorLess
19. CanonicalizedLaneletPose.operatorGreaterEqual
20. CanonicalizedLaneletPose.operatorGreater
21. CanonicalizedLaneletPose.isSameLaneletId_withPose_same
22. CanonicalizedLaneletPose.isSameLaneletId_withPose_different
23. CanonicalizedLaneletPose.isSameLaneletId_withLanelet_same
24. CanonicalizedLaneletPose.isSameLaneletId_withLanelet_different

References

Jira ticket: internal link

Destructive Changes

There are no destructive changes.

Related Issues

4.2.0

Description

Abstract

Added forwarding of scenario_test_runner launch arguments prefixed with autoware. to Autoware.

Background

Previously, scenario_test_runner had no mechanism to pass arbitrary launch arguments to Autoware that were not directly supported by scenario_test_runner. This was not due to scenario_test_runner design or technical reasons, but simply because such functionality was not implemented. Therefore, a mechanism was implemented to forward arbitrary launch arguments from scenario_test_runner to Autoware.

Details

All launch arguments given to scenario_test_runner with names starting with autoware. are collected together as a list of strings consisting of the prefix-stripped argument names and their values.
The collected arguments are passed to openscenario_interpreter and simple_sensor_simulator as a new ROS 2 parameter named autoware.. Finally, openscenario_interpreter passes the elements of the ROS 2 parameter autoware. together with other existing parameters to the launch argument of Autoware.

References

• tier4/sim_evaluation_tools#334

Destructive Changes

None.
Some existing launch arguments should be able to be replaced with those of the autoware. prefix, but for backward compatibility, we will not modify the existing arguments.

Known Limitations

None.

Related Issues

4.1.1

Description

Abstract

use_sim_time parameter is passed to the concealer's launch arguments based on the parameter passed to the scenario test runner launch command. It is False by default.

Background

Jira: RJD-822, RJD-1273
Document with stages 1,2,3: doc

Details

Usage of use_sim_time in Autoware and SS2 simulations:

• Stage 1: merged #1150
• Stage 2: merged #746 but reverted - because former way of propagating use_sim_time param to Autoware made it impossible to use the parameter outside of the simulation other solution was necessary - it is included in this PR
• Stage 3: omitted due to multiple regressions after setting use_sim_time to True as default

Multiple situations were tested:

1. SS2 with Autoware

• use_sim_time:=True passed using command line
  • Both Autoware and SS2 are launched with use_sim_time=true.
  • Time published on /clock is the simulation time (starting from 0).
  • Time published on /clock can be controlled by RViz plugin.
  • Simulation time can be controlled by RViz plugin.
• use_sim_time:=False passed using command line (default value)
  • Both Autoware and SS2 are launched with use_sim_time=false.
  • Time published on /clock is the walltime.
  • Time published on /clock cannot be controlled by RViz plugin.
  • Simulation time can be controlled by RViz plugin.

2. SS2 with Autoware and AWSIM (tested on awsim-ss2-stable)

• use_sim_time:=True passed using command line
  • Both Autoware and SS2 are launched with use_sim_time=true.
  • Time published on /clock is the simulation time (starting from 0).
  • Although the speed of time published on /clock can be controlled by RViz plugin it only affects the Autoware.
  • AWSIM behaves as if the speed of time was not changed which leads to invalid behavior.
  • It is possible to use the global_real_time_factor launch parameter if the StepExecution is turned on in ScenarioSimulatorConnector before AWSIM launch.
• use_sim_time:=False passed using command line (default value)
  • SS2 is launched with use_sim_time=false but Autoware is launched with use_sim_time=true.
  • Time published on /clock is raw time.
  • Time cannot be controlled by RViz plugin.
  • It is also not possible to control the speed of the simulation using the RViz plugin.

Destructive Changes

• Now the value of the use_sim_time parameter is passed to the Autoware launchr.

Related Issues

4.1.0

Abstract

This PR contains combined fixes for issues #1343 and #1344.

Details

Additionally:

1. This PR introduces 4 additional const-fields for LineSegment class, namely length, length_2d, vector and vector_2d. These constants are frequently used and can be easily calculated during construction.
2. Function getIntersection2DSValue has been renamed to get2DIntersectionSValue. In my opinion, in previous version it was unclear if 2D refers to Intersection or SValue.
3. Both isIntersect2D and getIntersection2D had a duplicate. This was simplified.
4. Function getSlope has been renamed to get2DVectorSlope, now it throws an error if division by 0 occurs.

Background

Please see #1343 and #1344 for detailed explanations of the bugs.

References

Regression tests summary

Related Issues

#1344 #1343

4.0.4

Description

Abstract

This PR contains unit tests for:

1. LidarSensor and LidarSensorBase
2. Primitive

Details

1. update_noEgo
2. update_correct
3. update_goBackInTime
4. getDetectedObjects
5. addToScene_sample
6. addToScene_zeros
7. getTriangles
8. getVertex
9. get2DConvexHull_normal
10. get2DConvexHull_withTransform
11. getMin
12. getMin_withTransform
13. getMin_empty
14. getMax
15. getMax_withTransform
16. getMax_empty

References

Jira ticket: link

Destructive Changes

There are no destructive changes

Related Issues

4.0.3

Description

This PR is based on temporary PR - for which regression tests have been run, and no regression has been evidenced (see here and here).

Abstract

This pull request introduces the change to contain the information of the fact that the NPC logic is started on only one place.
The information after the change is stored only in EntityManager. Other modules may access the information by calling the function EntityManager::isNpcLogicStarted.

Background

This pull request is one of many that aim to modularize the scenario_simulator_v2.

Details

In this pull request, the information of whether the NPC logic has been started is stored only in one class: EntityManager. The information may be accessed by modules using EntityManager with the function:
https://github.com/tier4/scenario_simulator_v2/blob/5abf55121f42759fe5fd2ee55e004e1f6fefc897/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L500
Like here:
https://github.com/tier4/scenario_simulator_v2/blob/5abf55121f42759fe5fd2ee55e004e1f6fefc897/simulation/traffic_simulator/src/api/api.cpp#L294

On the other hand, modules managed by EntityManager that used to need the information to perform some checks have been decoupled from this information. After the change, most of the checks have been removed from these modules and moved to the EntityManager. This way, the responsibility of managing the "NPC logic starting" has been moved fully to the EntityManager.
For example, instead of checking whether the NPC logic has started in every entity type in the member function onUpdate (see VehicleEntity, EgoEntity, PedestrianEntity, MiscObjectEntity) this check is performed in EntityManager before calling the onUpdate function on all entities:
https://github.com/tier4/scenario_simulator_v2/blob/5abf55121f42759fe5fd2ee55e004e1f6fefc897/simulation/traffic_simulator/src/entity/entity_manager.cpp#L360-L364

Similarly, getCurrentAction has been changed in all entities (see VehicleEntity, PedestrianEntity, MiscObjectEntity) and the check has been moved to EntityManager::getCurrentAction:
https://github.com/tier4/scenario_simulator_v2/blob/5abf55121f42759fe5fd2ee55e004e1f6fefc897/simulation/traffic_simulator/src/entity/entity_manager.cpp#L324-L335

This change greatly reduces the complexity and susceptibility for some errors when developing new features. After the change, it is clear where the responsibility for managing "NPC logic started". It can be easily managed and there is no possibility for data synchronization problems.

References

INTERNAL LINK

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

4.0.2

Description

This PR is based on temporary PR - for which regression tests have been run, and no regression has been evidenced (see here and here).

Abstract

This pull request introduces changes to the EntityManager. Data members current_time and step_time have been removed for simplicity and in order to eliminate the risk of synchronization problems.

Background

This pull request is one of many that aim to modularize the scenario_simulator_v2.

Details

The EntityManager data members current_time_ and step_time_:
https://github.com/tier4/scenario_simulator_v2/blob/f5d91cc43b555f39647c8a19a64c6fd60fc314be/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L88-L90
have been deleted and the signature of EntityManager::updateNpcLogic has been modified to take the up-to-date time data as arguments:
https://github.com/tier4/scenario_simulator_v2/blob/54e55f815f1d529c7f8aaffb6b6a509425d184ef/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L308-L309
This change reduces the complexity and minimizes the chance of some synchronization error.

After these changes, the time is completely managed by API, no other components store this data and if it is needed, they receive it on function calls as arguments.
For example, in the function EntityManager::spawnEntity the current_time argument has been added (here), because this data is needed for entity spawning. The time is passed from API on every call here, here and here.

There have been some changes introduced that are connected with passing step_time and current_time as arguments. Mainly functions have been converted to trailing return type - which is a style change - and arguments had a const specifier added, because there is no reason for them not to be const - they are never modified.

References

INTERNAL LINK

Destructive Changes

Known Limitations

Related Issues

4.0.1

Description

Abstract

Fixed bugs found in traffic_simulator during the development of rosbag_to_scenario.

Background

During the process of developing new features, analysis of the output results confirmed that multiple issues remained in the traffic_simulator package.
This Pull Request aims to address and fix these issues.

Details

• Fixed an issue where there was always a one-frame discrepancy between the timestamps attached to entity_status for those with trajectories and those without.
• Fixed an error in the handling of time within the FollowTrajectory process inside the do_nothing_plugin.

References

tier4/sim_evaluation_tools#332

Destructive Changes

N/A

Known Limitations

Ideally, the EntityStatus type should be reviewed again to remove the duplicate definitions of values with the same meaning. However, modifying the EntityStatus type would have significant impacts in various places and should be done cautiously.
Therefore, this Pull Request does not include that refactoring.

Related Issues

4.0.0

Description

This PR is based on TMP_PR2 - for which regression tests have been run and no regression has been evidenced.

Jira ticket: link

Regressions: link

Abstract

This PR is intended to remove the EntityStatus canonicalization process from BehaviorTree. From now on, during an update, for each Entity the canonicalization is performed only once and takes place only in EntityBase::onUpdate().

In addition, many unnecessary EntityStatus canonicalizations have been removed in the traffic_simulator itself. Now the CanonicalizedEntityStatus object is created when the entity is spawned, then the setting of the status is done via EntityBase::setStatus() where the EntityStatus is passed, then the CanonicalizedEntityStatus::set() method is called - where the desired canonicalization takes place.

Note: This PR is a continuation of the refactoring of the canonicalization process, which was initiated by the previous PR.

Background

At present, there are many calls of the CanonicalizedEntityStatus constructor in the code. The canonicalization process takes place in many places, which can be simplified - in fact, it is required that the status set in the update result is canonicalized - this is guaranteed by this PR.

Details

Canonicalization of EntityStatus in TrafficSimulator

• removed CanonicalizedEntityStatus constructors that accept EntityStatus,
• removed overload of oparator= in CanonicalizedEntityStatus,
• set() method added to CanonicalizedEntityStatus (it is important to set lanelet_pose_valid = true/false in passed EntityStatus, this determines whether the canonicalization is performed using LaneletPose itself or msg::Pose is used.)
• EntityStatus canonicalization process moved to API::setEntityStatus->EntityBase::setStatus()->CanonicalizedEntityStatus::set()

https://github.com/tier4/scenario_simulator_v2/blob/bbe65a1611b1c50a3c54f0058c102068add5471f/simulation/traffic_simulator/src/data_type/entity_status.cpp#L66-L84

EntityBase improvements

• changed the accepted EntityBase::setStatus() argument to EntityStatus and added EntityStatus::setCanonicalizedStatus() with CanonicalizedEntityStatus argument for cases where CanonicalizedLaneletPose is passed from openscenario_interpreter

https://github.com/tier4/scenario_simulator_v2/blob/bbe65a1611b1c50a3c54f0058c102068add5471f/simulation/traffic_simulator/src/entity/entity_base.cpp#L529-L537

• the setters in EntityBase have improved, now setters from CanonicalizedEntityStatus are used directly, there is no unnecessary process of taking EntityStatus and canonicalizing it again.

https://github.com/tier4/scenario_simulator_v2/blob/bbe65a1611b1c50a3c54f0058c102068add5471f/simulation/traffic_simulator/src/entity/entity_base.cpp#L555-L567

• getEntityType() method added to EntityBase
• grouped and ordered methods in CanonicalizedEntityStatus

https://github.com/tier4/scenario_simulator_v2/blob/bbe65a1611b1c50a3c54f0058c102068add5471f/simulation/traffic_simulator/include/traffic_simulator/data_type/entity_status.hpp#L40-L71

• added EgoEntity::setStatus() with lanelet::Ids as second argument, since it is the only Entity that uses lanelet_id not from EntityStatus but got from Autoware

https://github.com/tier4/scenario_simulator_v2/blob/bbe65a1611b1c50a3c54f0058c102068add5471f/simulation/traffic_simulator/src/entity/ego_entity.cpp#L299-L318

• It is ensured that EntityManager::getEntityStatus() simply returns a constant reference to the map object

https://github.com/tier4/scenario_simulator_v2/blob/bbe65a1611b1c50a3c54f0058c102068add5471f/simulation/traffic_simulator/src/entity/entity_manager.cpp#L178-L186

Canonicalization of EntityStatus in BehaviorTree

• Changed "updated_status" port type in BehaviorTree from CanonicalizedEntityStatus to EntityStatus, port name now is "non_canonicalized_updated_status".

https://github.com/tier4/scenario_simulator_v2/blob/bbe65a1611b1c50a3c54f0058c102068add5471f/simulation/traffic_simulator/include/traffic_simulator/behavior/behavior_plugin_base.hpp#L75

• Now ActionNode::calculateUpdatedEntityStatus and ActionNode::calculateUpdatedEntityStatusInWorldFrame return EntityStatus
• removed fill_lanelet_data_and_adjust_orientation from FollowTajetoryAction, now every CanonicalizedEntityStatus has a fitted position to the lanelet
• It is ensured that ActionNode::getEntityStatus() simply returns a constant reference to the map object

Destructive Changes

BehaviorTree

• Changed "updated_status" port type in BehaviorTree from CanonicalizedEntityStatus to EntityStatus, port name now is "non_canonicalized_updated_status".

https://github.com/tier4/scenario_simulator_v2/blob/bbe65a1611b1c50a3c54f0058c102068add5471f/simulation/traffic_simulator/include/traffic_simulator/behavior/behavior_plugin_base.hpp#L75

Before

https://github.com/tier4/scenario_simulator_v2/blob/140ada513a9b78fc9bffffb76e142f55ed1c4b75/simulation/behavior_tree_plugin/src/vehicle/follow_lane_sequence/yield_action.cpp#L124-L126

After

https://github.com/tier4/scenario_simulator_v2/blob/bbe65a1611b1c50a3c54f0058c102068add5471f/simulation/behavior_tree_plugin/src/vehicle/follow_lane_sequence/yield_action.cpp#L124-L126

Related Issues