Releases: tier4/scenario_simulator_v2
7.4.1
Description
Abstract
catch common::SemanticError inside traffic_simulator::pose::canonicalize function.
Background
In #1266 the CanonicalizedLaneletPose::canonicalize function is now used in the constructor of the CanonicalizedLaneletPose class.
CanonicalizedLaneletPose class is used inside traffic_simulator::pose::canonicalize function.
The traffic_simulator::pose::canonicalize function has a return value of type std::optional and must return std::nullopt if it is used for lane coordinate system calculation, but CanonicalizedLaneletPose ::canonicalize function throws common::SemanticError in case of failure of lane coordinate system calculation, so if std::nullopt is expected as a return value, an exception is raised and the simulation stops.
Details
catch common::SemanticError inside traffic_simulator::pose::canonicalize function.
Unit tests run on the source code of this commit hash will output the following error and fail.
- test_pose
<<< failure message
-- run_test.py: invoking following command in '/home/user/workspace/pilot-auto.x2/build/traffic_simulator/test/src/utils':
- /home/user/workspace/pilot-auto.x2/build/traffic_simulator/test/src/utils/test_pose --gtest_output=xml:/home/user/workspace/pilot-auto.x2/build/traffic_simulator/test_results/traffic_simulator/test_pose.gtest.xml
[==========] Running 44 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 6 tests from pose
[ RUN ] pose.quietNaNPose
[ OK ] pose.quietNaNPose (0 ms)
[ RUN ] pose.quietNaNLaneletPose
[ OK ] pose.quietNaNLaneletPose (0 ms)
[ RUN ] pose.transformRelativePoseToGlobal
[ OK ] pose.transformRelativePoseToGlobal (0 ms)
[ RUN ] pose.relativePose_poses_zero
[ OK ] pose.relativePose_poses_zero (0 ms)
[ RUN ] pose.relativePose_poses_zeros
[ OK ] pose.relativePose_poses_zeros (0 ms)
[ RUN ] pose.relativePose_poses_complex
[ OK ] pose.relativePose_poses_complex (0 ms)
[----------] 6 tests from pose (0 ms total)
[----------] 38 tests from PoseTest
[ RUN ] PoseTest.canonicalize_default
[ OK ] PoseTest.canonicalize_default (8 ms)
[ RUN ] PoseTest.canonicalize_invalid
unknown file: Failure
C++ exception with description "/home/user/workspace/pilot-auto.x2/src/simulator/scenario_simulator/simulation/traffic_simulator/src/data_type/lanelet_pose.cpp:81: Lanelet pose (id=203,s=1000,offset=0,rpy.x=0,rpy.y=0,rpy.z=0) is invalid, please check lanelet length and connection." thrown in the test body.
[ FAILED ] PoseTest.canonicalize_invalid (7 ms)
[ RUN ] PoseTest.canonicalize_valid
[ OK ] PoseTest.canonicalize_valid (7 ms)
[ RUN ] PoseTest.toMapPose_CanonicalizedLaneletPose
[ OK ] PoseTest.toMapPose_CanonicalizedLaneletPose (6 ms)
[ RUN ] PoseTest.toMapPose_LaneletPose
[ OK ] PoseTest.toMapPose_LaneletPose (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_noBoundingBox_noRoute_valid
[ OK ] PoseTest.toCanonicalizedLaneletPose_noBoundingBox_noRoute_valid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_noBoundingBox_noRoute_invalid
[ OK ] PoseTest.toCanonicalizedLaneletPose_noBoundingBox_noRoute_invalid (6 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_noRoute_valid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_noRoute_valid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_noRoute_invalid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_noRoute_invalid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_emptyInvalid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_emptyInvalid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_emptyValid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_emptyValid (6 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_nonEmptyInvalid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_nonEmptyInvalid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_nonEmptyValid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_nonEmptyValid (7 ms)
[ RUN ] PoseTest.relativePose_canonicalized_end_position
[ OK ] PoseTest.relativePose_canonicalized_end_position (6 ms)
[ RUN ] PoseTest.relativePose_canonicalized_start_position
[ OK ] PoseTest.relativePose_canonicalized_start_position (7 ms)
[ RUN ] PoseTest.boundingBoxRelativePose_disjoint
[ OK ] PoseTest.boundingBoxRelativePose_disjoint (6 ms)
[ RUN ] PoseTest.boundingBoxRelativePose_commonEdge
[ OK ] PoseTest.boundingBoxRelativePose_commonEdge (7 ms)
[ RUN ] PoseTest.boundingBoxRelativePose_intersect
[ OK ] PoseTest.boundingBoxRelativePose_intersect (7 ms)
[ RUN ] PoseTest.relativeLaneletPose_s_invalid
[ OK ] PoseTest.relativeLaneletPose_s_invalid (7 ms)
[ RUN ] PoseTest.relativeLaneletPose_s_valid
[ OK ] PoseTest.relativeLaneletPose_s_valid (7 ms)
[ RUN ] PoseTest.relativeLaneletPose_offset_invalid
[ OK ] PoseTest.relativeLaneletPose_offset_invalid (6 ms)
[ RUN ] PoseTest.relativeLaneletPose_offset_valid
[ OK ] PoseTest.relativeLaneletPose_offset_valid (7 ms)
[ RUN ] PoseTest.boundingBoxRelativeLaneletPose_s_invalid
[ OK ] PoseTest.boundingBoxRelativeLaneletPose_s_invalid (7 ms)
[ RUN ] PoseTest.boundingBoxRelativeLaneletPose_s_valid
[ OK ] PoseTest.boundingBoxRelativeLaneletPose_s_valid (7 ms)
[ RUN ] PoseTest.boundingBoxRelativeLaneletPose_offset_invalid
[ OK ] PoseTest.boundingBoxRelativeLaneletPose_offset_invalid (7 ms)
[ RUN ] PoseTest.boundingBoxRelativeLaneletPose_offset_valid
[ OK ] PoseTest.boundingBoxRelativeLaneletPose_offset_valid (6 ms)
[ RUN ] PoseTest.isInLanelet_inside
[ OK ] PoseTest.isInLanelet_inside (8 ms)
[ RUN ] PoseTest.isInLanelet_outsideFrontFar
[ OK ] PoseTest.isInLanelet_outsideFrontFar (7 ms)
[ RUN ] PoseTest.isInLanelet_outsideFrontClose
[ OK ] PoseTest.isInLanelet_outsideFrontClose (6 ms)
[ RUN ] PoseTest.isInLanelet_outsideBackFar
[ OK ] PoseTest.isInLanelet_outsideBackFar (8 ms)
[ RUN ] PoseTest.isInLanelet_outsideBackClose
[ OK ] PoseTest.isInLanelet_outsideBackClose (7 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_noFollowing_within
[ OK ] PoseTest.isAtEndOfLanelets_noFollowing_within (7 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_singleFollowing_within
[ OK ] PoseTest.isAtEndOfLanelets_singleFollowing_within (6 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_singleFollowing_outside
[ OK ] PoseTest.isAtEndOfLanelets_singleFollowing_outside (7 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_multipleFollowing_within
[ OK ] PoseTest.isAtEndOfLanelets_multipleFollowing_within (7 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_multipleFollowing_outside
[ OK ] PoseTest.isAtEndOfLanelets_multipleFollowing_outside (7 ms)
[ RUN ] PoseTest.laneletLength_invalid
[ OK ] PoseTest.laneletLength_invalid (7 ms)
[ RUN ] PoseTest.laneletLength_valid
[ OK ] PoseTest.laneletLength_valid (7 ms)
[----------] 38 tests from PoseTest (260 ms total)
[----------] Global test environment tear-down
[==========] 44 tests from 2 test suites ran. (260 ms total)
[ PASSED ] 43 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] PoseTest.canonicalize_invalid
References
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
7.4.0
Abstract
This PR contains the continuation of #1443
Details
- There is no longer
lanelet::Idpassed into TrafficSink, but anoptional<lanelet::Id>. It is still used solely for the purpose of visualization, wherenulloptmeans that the sink was placed too far from the lane. Resigning from passinglanelet::Idaltogether turned out to be problematic, because ends of multiple lanelets overlap and the corresponding lanelet could not be determined. - Additionally I would like to propose an alternative approach to the
set sinkable_entity_typesvariable. - I have removed the special case
if sinkable_entity_types is empty, then all entities should sink. In my opinion it could be misleading (someone could pass emptysinkable_entity_typesand expect that no sinking behavior will occur). Now if we want to sink all entities, we need to provide the full setsinkable_entity_types. - I have removed the
bool auto_sinkvariable, which could be equivalent tosinkable_entity_types.empty()with this approach. - The default behavior is
sinkable_entity_types = {}, that is no auto sinks are generated.
References
Related Issues
7.3.5
Description
Abstract
The package concealer code was refactored.
Background
The code of the package concealer has been modified without any refactoring since its creation until today. This is not due to technical reasons, but simply because there was no opportunity. However, now that the merge of #1454 has been completed, I thought it was a good opportunity to refactor it.
Details
As the title suggests, I plan to refactor concealer in several stages. The purpose of this pull request is to first make the code more compact without making any functional changes.
Base Class Autoware
When I designed concealer, I was struggling with the need to support three different Autoware flavors in scenario_simulator_v2: Autoware.AI, Autoware.T4B, and AutowareArchitectureProposal. The structure of the base class Autoware and its derived class AutowareUniverse is based on the assumption that Autoware with an architecture different from Autoware.Universe will appear. However, in reality, no such different type of Autoware has appeared since the emergence of Autoware.Universe. This could be interpreted as just a coincidence that it has not appeared until now, but it is also true that the code is bulky due to this structure, so for the time being, I deleted the base class and simplified the code.
Reducing Member Functions
Member functions that are only used by certain member functions have been changed to function local functions. Making them private member functions was also an option, but we decided not to do so. Based on our experience in maintenance over the past few years, the cost of understanding where a certain member function is being called from is a burden both in terms of code modification and code review. This is just a matter of preference. I don't mind changing function-local functions to private member functions at some point, so I'm doing it this way for now to make refactoring following this pull request easier.
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
7.3.4
Description
Abstract
Add auto HdMapUtils::isInIntersection(const lanelet::Id lanelet_id) const -> bool function.
Background
In the current master branch implementation, there was no function to determine if a lanelet is a lanelet at an intersection.
Details
Since it was found that lanelets included in an intersection have an attribute called turn_direction, it was decided to make a judgment based on this attribute.
The use of intersection_area polygon was also suggested, but the condition is that intersection in lanelet2 means turn_direction, and polygon(intersection_area) is the polygon that is responsible for setting the area. Therefore, we decided to use the presence or absence of turn_direction` as a condition for judgment.
Lanelet outside intersection.
Lanelet inside intersection.
References
Internal link.
Document about lanelet2(Japanese)
Document about lanelet2(English)
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
7.3.3
Description
Abstract
Merge SpellCheckAll and SpellCheck workflow.
Background
SpellCheckAll and SpellCheck do almost same thing.
Details
Merge SpellCheckAll and SpellCheck workflow.
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
7.3.2
Description
Arm64 CI was broken, so remove it temporarily.
Abstract
Remove ARM64 CI.
Background
Arm64 CI was broken, so remove it temporarily.
Details
Remove arm64 CI from matrix.
strategy:
matrix:
rosdistro: [humble]
# arch: [amd64, arm64]
arch: [amd64]
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
7.3.1
7.3.0
Description
Abstract
This pull request introduces support for multi-level lanelets (e.g., bridges over roads) by improving lanelet matching and collision solving mechanisms. Previously, lanelet matching relied on 2D position checks, which could lead to incorrect detections and false-positive collisions when entities were on different altitudes.
Background
In multi-level environments – such as maps featuring bridges over roads or tunnels beneath roads – the previous lanelet matching and collision detection algorithms relied solely on 2D proximity checks. This approach considered only the X and Y coordinates of entities, ignoring their altitude (Z-axis).
As a result, entities located on different levels (e.g., a vehicle on a bridge and another vehicle on the road below) could be incorrectly matched to the same lanelet. This caused:
- False-positive detections: Entities were mistakenly identified as obstacles, even though they were on different levels.
- Unnecessary slowing or stopping: The Ego vehicle would slow down or stop due to these incorrect detections, reducing driving efficiency and simulation realism.
To resolve these issues, 3D lanelet matching and collision-solving mechanisms have been introduced.
Details
Enhancements to Lanelet Matching
3D Matching Support
- The toLaneletPose method has been updated to incorporate the altitude (Z-axis) of entities when performing lanelet matching. This helps ensure that entities are correctly matched to lanelets on the appropriate level.
New altitude_threshold Parameter
- Added a parameter altitude_threshold to define the maximum altitude difference allowed when matching an entity to a lanelet.
Improvements to Collision Solving
BehaviorTree Updates
- The BehaviorTree logic now considers the altitude of potential obstacles. This allows NPCs to ignore entities that are on a different vertical level. Link to introduced changes.
Ego Plane Determination
- A mechanism for determining the Ego plane was introduced. Entities that fall below this plane (e.g., vehicles under a bridge) are excluded from detection. Link to introduced changes.
Geometry Enhancements
- Introduced a
Planestructure and methods to calculate offsets relative to this plane. Link to introduced changes. - Updated quaternion operations for more efficient altitude calculations. Link to introduced changes #1 and Link to introduced changes #2
Fix traffic_source class
- The
TrafficSource::makeRandomPosemethod does not account for the Z-axis when generating random positions. As a result, the generated position may be incorrect and an entity may not match to the lanelet. To fix this issue, the Z-coordinate is now assigned based on the altitude of the first nearby lanelet found. Link to introduced changes
Fix Unit tests
- Adjusted unit tests to reflect recent changes related to 3D matching and collision solving. Link to introduced changes #1 and Link to introduced changes #2 and Link to introduced changes #3
References
Internal link 1
Internal link 2
Destructive Changes
--
Known Limitations
--
Related Issues
7.2.0
Description
Abstract
Added the option simulate_localization:=<boolean> to simulate the option localization_sim_mode:=<api | pose_twist_estimator> of simple_planning_simulator.
Background
Previously, scenario_simulator_v2 also simulated Autoware's localization module, but in order to test the localization module, an option was needed to leave this to Autoware rather than doing it on the scenario_simulator_v2 side.
Feature request thread (internal link)
Details
The default is simulate_localization:=true, which performs the same operation as localization_sim_mode:=api. This is compatible with the previous scenario_simulator_v2. On the other hand, when simulate_localization:=false, it performs the same operation as localization_sim_mode:=pose_twist_estimator.
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
7.1.0
Description
Abstract
Added partial support for OpenSCENARIO XML 1.3.1 TimeToCollisionCondition.
Background
None.
Details
None.
References
Destructive Changes
None.
Known Limitations
Since TimeToCollisionCondition is implemented using DistanceCondition, RelativeDistanceCondition, SpeedCondition, and RelativeSpeedCondition, if a combination of properties that is not supported by those Conditions is given to TimeToCollisionCondition, an error will be thrown.