Releases: tier4/scenario_simulator_v2
12.1.0
Description
Abstract
- Added new noise model
noise_v2to DetectionSensor in simple_sensor_simulator - Renamed the existing noise model from
noisetonoise_v1
Background
The noise models provided in the past were very simple, using a normal distribution and applying random noise to the positions of non-ego entities. However, this was too simple to be useful in the development of Autoware's planner. Therefore, we added a more realistic noise model provided by the planner development team.
Details
Please refer to the document Parameters.md for the specification and configuration method of the newly added noise model noise_v2.
Also, the previous noise model noise_v1 was configured via a scenario file, but now the configuration method has been changed to be configured via a ROS 2 parameter file as well as the new noise model. However, for backward compatibility, the previous configuration method is still supported for noise_v1. You can configure noise_v1 in either the old or the new way, but the old way is basically prioritized (see override_legacy_configuration in the documentation).
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
12.0.2
Description
Abstract
This is a partial pull request of #1334.
Background
std::ostream & operator<< are defined in helper.[ch]pp. However, this filename is not intuitive.
Also, output of these operators are ambiguous.
Details
Quoted from #1334.
Ostream helpers
All existing operatorsstd::ostream & operator<<have been moved from filehelper.[ch]ppto a dedicated fileostream_helper.[ch]pp.
In addition many more operators have been added for the types
- traffic_simulator_msgs::msg::LaneletPose
- traffic_simulator_msgs::msg::EntitySubtype
- traffic_simulator_msgs::msg::Axle
- traffic_simulator_msgs::msg::Axles
- traffic_simulator_msgs::msg::BoundingBox
- traffic_simulator_msgs::msg::Performance
- traffic_simulator_msgs::msg::VehicleParameters
In addition, this PR will update test related to changes.
References
Destructive Changes
Output from operators are changed. We may need to fix programs that use output.
Related Issues
12.0.1
Abstract
This Pull Request updates the GitHub Actions workflow to modify the tagging behavior for Docker images in the scenario_simulator_v2 repository. The changes ensure that the latest version tags are consistently applied to the traffic_simulator and humble images.
Background
Previously, the workflow tagged images with version-specific identifiers but did not consistently apply the latest tag. This omission could lead to confusion when pulling the most up-to-date images. This update adds the latest tag to improve version tracking and deployment consistency.
Details
- Updated the tags section in the GitHub Actions workflow to include:
- ghcr.io/tier4/scenario_simulator_v2:traffic_simulator_latest in the traffic_simulator job.
- ghcr.io/tier4/scenario_simulator_v2:latest in the humble job.
- Ensured that the push: true setting remains active for these changes to take effect.
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
12.0.0
Description
Abstract
This is the partial PR of the HdMapUtils refactor (PR 2/6) ( #1478 )
Details
Replace usage of HdMapUtils::getLeftBound and getRightBound with non-member function lanelet_wrapper::lanelet_map::leftBound, rightBound
References
Destructive Changes
The hdmap_utils_ptr parameter has been removed from the following functions:
traffic_simulator::distance::distanceToLaneBoundtraffic_simulator::distance::distanceToLeftLaneBoundtraffic_simulator::distance::distanceToRightLaneBound
For the rationale behind this change, see #1478.
Migration Guide
Before (Old Signature)
auto distanceToLaneBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
lanelet::Id lanelet_id,
const std::shared_ptr<hdmap_utils::HdMapUtils> & hdmap_utils_ptr) -> double;
auto distanceToLaneBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
const lanelet::Ids & lanelet_ids,
const std::shared_ptr<hdmap_utils::HdMapUtils> & hdmap_utils_ptr) -> double;
auto distanceToLeftBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
lanelet::Id lanelet_id,
const std::shared_ptr<hdmap_utils::HdMapUtils> & hdmap_utils_ptr) -> double;
auto distanceToLeftBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
const lanelet::Ids & lanelet_ids,
const std::shared_ptr<hdmap_utils::HdMapUtils> & hdmap_utils_ptr) -> double;
auto distanceToRightBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
lanelet::Id lanelet_id,
const std::shared_ptr<hdmap_utils::HdMapUtils> & hdmap_utils_ptr) -> double;
auto distanceToRightBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
const lanelet::Ids & lanelet_ids,
const std::shared_ptr<hdmap_utils::HdMapUtils> & hdmap_utils_ptr) -> double;
After (New Signature)
auto distanceToLaneBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
lanelet::Id lanelet_id) -> double;
auto distanceToLaneBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
const lanelet::Ids & lanelet_ids) -> double;
auto distanceToLeftBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
lanelet::Id lanelet_id) -> double;
auto distanceToLeftBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
const lanelet::Ids & lanelet_ids) -> double;
auto distanceToRightBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
lanelet::Id lanelet_id) -> double;
auto distanceToRightBound(
const geometry_msgs::msg::Pose & map_pose,
const traffic_simulator_msgs::msg::BoundingBox & bounding_box,
const lanelet::Ids & lanelet_ids) -> double;
The fourth parameter, const std::shared_ptr<hdmap_utils::HdMapUtils> & hdmap_utils_ptr, has been removed.
Remove the hdmap_utils_ptr argument from call to distanceToLaneBound, distanceToLeftBound, distanceToRightBound.
Known Limitations
None.
Related Issues
11.1.0
Description
Abstract
This pull-request adds computation time metrics for...
- allowing scenarios to evaluate the impact of increased computation time
- allowing us to find out the calculation time and analyze with rosbags
Additionally, this pull-request added test scenario that has execution time conditions.
Background
Previously, scenario_simulator_v2 simply dispaly a log like below if the main loop is timed out:
Your machine is not powerful enough to run the scenario at the specified frame rate
This pull-reuqest has been made to allow for more detailed analysis.
Details
added metrics topics
/simulation/interpreter/execution_time/evaluate- execution time for evaluating scenario
/simulation/interpreter/execution_time/update- execution time for updating
traffic_simulator
- execution time for updating
/simulation/interpreter/execution_time/output- execution time for creating and publishing simulation context
optional scenarios in workflow
This pull-request added execution_time_test.yaml, but the execution time and the scenario result are flaky.
Off cource, greater execution time threshold make the scenarios stable.
But the greater the threshold, the lesshoh value there is in the scenario.
In this pull-request, I prepare optional scenario workflows for effective but flaky scenarios.
The scenario failures don't affect CI result, but report the result and error messages by comment as below.
References
Destructive Changes
None
Known Limitations
None
Related Issues
11.0.0
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.