Releases: tier4/scenario_simulator_v2
10.2.0
Description
Abstract
This pull-request adds record_storage_id launch file argument.
It is passed to argument -s (--storage) of ros2 bag record command.
Background
We want to use mcap format for rosbag.
But, it is not default format in ROS 2 Humble.
Details
If you don't specify record_storage_id argument, the default format in ros2 bag record command is used. ( same behavior to previous version )
In ROS 2 Humble, sqlite3 is used, and mcap in ROS 2 Jazzy
References
Destructive Changes
None
Known Limitations
None
Related Issues
10.1.2
Description
Abstract
This is the partial PR of the HdMapUtils refactor (PR 2/6) ( #1478 )
Background
Details
It has been noticed that in some files the copyright date is wrong (other than 2015), and the date has been fixed in those files where the incorrect copyright date was noticed.
References
Destructive Changes
None.
Known Limitations
None.
Related Issues
10.1.1
Description
Abstract
Added comments on scenarios that have been excluded from the test.
Background
The respawn_ego scenario cannot be executed with GitHub Actions as it requires EgoEntity for execution.
Details
Add a comment about it to the CMakeLists.txt.
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
10.1.0
Description
- enable
respawn_egomock test. - fix launch option.
Abstract
Missing necessary parameter simulate_localization for mock_test.launch.py. As a result, mock test executed without localization simulation.
Background
When I tryied adding and improving respawn_ego test, I met wierd behavior (please see following movie). I found scenario_simulator_v2 didn't simulate localization even the autoware didn't launch any localization module.
Related PR: #1484
movie-2024-12-23_08.39.48.mp4
Details
This PR has two contents.
- Enabled
respawn_egomock test so that we can find regression of respawn functionality. Additionally, I improved test scenario. The ego spawns at lane id34621and moves to34606during first 10 sec. After that, the ego will respawns at lane id34576and moves to34564. If the ego can reach goal lane by within 60 sec, the scenario will be success. (please see following movie.) - Added launch option to simulate localization to
mock_test.launch.py.
movie-2024-12-23_08.16.06.mp4
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
10.0.0
Description
Abstract
This PR introduces a simple change where EntityManager's and API's member functions obtaining entities have been modified to return a reference to the object, rather than a pointer.
The change mentioned above is interface breaking and thus many cpp mock scenarios as well as openscenario interpreter and random test runner had to be adjusted to accommodate these changes.
Background
This change has been suggested in the discussion under the previous refactoring PR (3/5) in this comment.
Tip
For the bigger picture, please see the whole thread started by the comment linked above.
Details
This PR changes several EntityManager member function signatures and subsequently all corresponding member functions of API as they are forwarded using a FORWARD_TO_ENTITY_MANAGER macro.
Listed below are all changes made to the EntityManager function signatures.
Obtaining EntityBase with error throwing
Before
https://github.com/tier4/scenario_simulator_v2/blob/59b5887b179293fea3ad5eb993c15520e76b58af/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L177-L178
After
https://github.com/tier4/scenario_simulator_v2/blob/f0d702d725bd339bdb7c1e1e3660aa213b970d04/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L177-L179
Obtaining EntityBase without error throwing
Before
https://github.com/tier4/scenario_simulator_v2/blob/59b5887b179293fea3ad5eb993c15520e76b58af/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L174-L175
After
https://github.com/tier4/scenario_simulator_v2/blob/f0d702d725bd339bdb7c1e1e3660aa213b970d04/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L174-L175
Obtaining EgoEntity (only with error throwing)
Before
https://github.com/tier4/scenario_simulator_v2/blob/59b5887b179293fea3ad5eb993c15520e76b58af/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L180-L183
After
https://github.com/tier4/scenario_simulator_v2/blob/f0d702d725bd339bdb7c1e1e3660aa213b970d04/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L181-L183
Important
After these changes the function that "gets the Ego without providing the name argument" has been replaced with the combination of using getFirstEgoName and the function that does require a name argument.
Obtaining Ego name
Before
https://github.com/tier4/scenario_simulator_v2/blob/59b5887b179293fea3ad5eb993c15520e76b58af/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L224
After
https://github.com/tier4/scenario_simulator_v2/blob/f0d702d725bd339bdb7c1e1e3660aa213b970d04/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L224
References
Destructive Changes
The return value of the getEntity function has been changed from a shared pointer to a reference.
Therefore, any place where the getEntity function is called is subject to a destructive change.
Known Limitations
--
Related Issues
9.4.0
Description
Abstract
Support message type autoware_internal_planning_msgs::msg::PathWithLaneId.
Background
From Pilot.Auto 0.41.0, autoware_internal_planning_msgs has been added. Due to the addition of this message type, tier4_planning_msgs::msg::PathWithLaneId will be replaced by autoware_internal_planning_msgs::msg::PathWithLaneId from Pilot.Auto 0.41.1 onwards. In other words, Pilot.Auto 0.41.0 is a version to give time for the message type change, and while tier4_planning_msgs::msg::PathWithLaneId and autoware_internal_planning_msgs::msg::PathWithLaneId coexist, tier4_planning_msgs::msg::PathWithLaneId is the one that is used.
To accommodate this change, scenario_simulator_v2 needs to support both message types and be able to switch which one to use. This pull request does this.
Details
The current default architecture_type is awf/unvierse/20240605 and this pull request does not change it. (We need to consider how to manage the default architecture_type in the future.)
- If
architecture_typeisawf/universe/20250130or later,autoware_internal_planning_msgs::msg::PathWithLaneIdsubscribers are instantiated. - Otherwise,
tier4_planning_msgs::msg::PathWithLaneIdsubscribers are instantiated.
To achieve the above switch, the class template Subscriber has been updated, and some auxiliary class templates have been added for it.
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
9.3.1
Description
Abstract
This pull-request is deleting unnecessary target branch filter in workflow trigger
Background
When adding new features or refactorings that require multiple pull requests, the target branch is often set to something other than master.
There is no reason to exclude such cases from CI.
Details
This pull-request does not change any code.
So, no regression tests are executed.
The workflows below are not fixed because it makes sense to narrow down the target branch to master.
- .github/workflows/CheckBranchUpToDate.yaml
- .github/workflows/CheckLabel.yaml
- .github/workflows/Release.yaml
References
None
Destructive Changes
None
Known Limitations
None
Related Issues
9.3.0
Description
Abstract
Add docker image for traffic_simulator.
Background
The Docker Image of scenario_simulator_v2 is currently 13.6 GB following the humble-9.1.0 version.
Therefore, the size of the Docker Image was very large when trying to develop an application using scenario_simulator_v2.
Details
Additional Docker Image including only traffic_simulator and its dependent packages.
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
9.2.0
Description
Abstract
This pull request introduces a fix for lanelet slope inaccuracies in the FollowTrajectoryAction and WalkStraightAction.
Details
In the case of FollowTrajectoryAction and WalkStraightAction, an issue arises in the algorithm responsible for determining the entity's position. During each simulation step, displacement is calculated based on the velocity vector and step_time. When the entity moves along a sloped lanelet (e.g., driving uphill), the calculated displacement can sometimes exceed the remaining distance to the end of the lanelet.
To address transitions between lanelets, the method CanonicalizedLaneletPose::adjustOrientationAndOzPosition adjusts the entity's orientation to match the lanelet's pitch angle and sets the entity's height to the lanelet's elevation. As a result, the cumulative displacement computed by the makeUpdatedStatus function may not always reflect the actual distance traveled.
The proposed solution involves checking the remaining distance to the end of the current lanelet. If the calculated displacement exceeds this distance, the entity's position is updated to the next lanelet in a controlled manner. This ensures accurate positioning and smooth transitions between lanelets.
Code Changes
Pose
- The
updatePositionForLaneletTransitionfunction accounts for cases where the entity reaches the end of the current lanelet and needs to transition to the next lanelet. Link
Follow Trajectory Action
- The
makeUpdatedStatusmethod has been updated to fix issues. Link
Walk Straight Action
- The method
ActionNode::calculateUpdatedEntityStatusInWorldFramehas been modified to fix the issue withWalkStraightAction. It updates the position and orientation of the entity, ensuring precise movement along the lanelet and accurate handling of transitions between lanelets. Link.
New Vector and Quaternion Operations
-
Added function to calculate the norm of a quaternion. Link
-
Added function to normalize a quaternion. Link
-
An operator overload for the + operator was added to facilitate vector addition. This allows combining custom vector types with Eigen::Vector3d seamlessly. Link
References
Internal link 1
Internal link 2
Destructive Changes
--
Known Limitations
--
Related Issues
9.1.0
Description
NPC should detect another Entity with see_around even when the Entity does not overlap the center line of the lane which the NPC is on. This change allows to detect another NPC which overlap path of this NPC.
Abstract
This PR changes detection function of front entity in ActionNode.
Details
I've changed getDistanceToTargetEntityPolygon to use boundingBoxRelativeLaneletPose. It calculates relative pose between current NPC and another one. If absolute value of offset is less than half of NPC width it means that it intersects with current NPC path. If so distance to front entity is s of the pose enlarged by half of the length of NPC, as we need distance from the center.
Destructive Changes
--
Known Limitations
--