Releases: tier4/scenario_simulator_v2
10.3.3
Description
Abstract
Refactored the function to add noise to messages published by DetectionSensor in simple_sensor_simulator.
Background
DetectionSensor currently provides a simple noise application. The feature can be configured in the items listed in LINK whose names begin with detectedObject.
However, since this feature is only a simple noise application, a more practical noise model will be designed by Autoware's planner development team. The classes DefaultNoiseApplicator and CustomNoiseApplicator have been prepared as a testing ground for the planner development team to test and validate the model.
Details
The two refactorings we have done this time are as follows:
Delete DefaultNoiseApplicator and CustomNoiseApplicator and replace them with closure
These two classes were provided for ease and simplicity of test implementation.
In reality, however, these classes served neither purpose. As evidenced by the fact that DefaultNoiseApplicator's class members are raw references, this class is effectively no different than a closure that reference-captures the required object.
Although the member function DetectionSensor<>::update has the disadvantage of being larger in definition, I thought it would be more beneficial to reduce the total amount of code, so I removed those classes and replaced them with closures that do the equivalent work.
Change the argument type of the noise application function
Previously, the noise application function (CustomNoiseApplicator::operator ()) was passed the DetectedObjects type, which is the message type that will eventually be published.
However, each object stored in the DetectedObjects type does not have an identifier that can be used to identify the individual object, which makes it difficult to implement a specific noise model.
Therefore, the data type given to the noise application function was changed to traffic_simulator_msgs::EntityStatus, which holds the name of each entity.
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
10.3.2
Description
Abstract
This pull-request removes double applied orientation for visualization entity triangle marker
Background
Previously, there was a triangle marker in front of the entity, like the screenshot in document site.
https://tier4.github.io/scenario_simulator_v2-docs/user_guide/ScenarioTips/#lane-change
But, at some point, this triangle stopped appearing in the correct place.
Details
Before (no triangle)
After (triangle in front of entity)
References
Maybe, #1238 introduced this bug.
Destructive Changes
None
Known Limitations
None
Related Issues
10.3.1
Description
Abstract
use AS instead of as in Dockerfiles
Background
The lower-case as is pointed out by GitHub in every pull-request.
Details
None
References
None
Destructive Changes
None
Known Limitations
None
Related Issues
10.3.0
Description
Abstract
This pull request adds the ability to randomize the value of any field in messages published by the concealer publisher.
Additionally, a launch argument parameter_file_path has been added to scenario_test_runner that accepts the path to the ROS 2 parameter file to specify the parameters to be given to the randomizer.
Background
Previously, scenario_simulator_v2 could randomize some of the perception-related messages it published to Autoware (which is the responsibility of simple_sensor_simulator), but not the localization-related ones (which is the responsibility of concealer).
Recently, the Autoware development team requested the ability to randomize odometry out of localization, so we have implemented this and added a comprehensive parameter file to specify the parameters to be given to such a functionality.
Details
In this pull request, the randomizer is only enabled for those related to odometry.
The Localization topic randomizer can be configured from the ROS 2 parameter file given to the launch argument parameter_file_path of scenario_test_runner. The default value of parameter_file_path is the path to the sample parameter file.
The parameter file was designed with the intention that in the future it will comprehensively handle the parameters given to the simple_sensor_simulator and the concealer handling publishers and subscribers. This includes parameters related to perception, which are currently specified by Properties in the OpenSCENARIO XML scenario file. Therefore, the parameter file includes information such as architecture_type values, message type names, topic type names, and other information that may be needed in the future (some of which is not used in this pull request).
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
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.