Releases: tier4/scenario_simulator_v2
1.11.3
Description
Abstract
This pull-request stops using ROS messages as basic types in openscenario_interpreter.
Previously, this ROS message inheritance was introduced to make it easier to output to ROS messages, but now it only adds unnecessary dependencies.
References
Regression Test: OK
Related Issues
1.11.2
Description
Abstract
remove -Wreorder warning from random_test_runner package.
Background
There was a problem with the initialization order of variables, causing a -Wreorder warning.
Details
Fixed initialization order and fixed Wreorder warning inside random_test_runner package.
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
1.11.1
Description
Abstract
Remove wrong comment // headers in STL
Background
As pointed out in this comment, an inappropriate description was left as a comment.
Details
This pull request was created to remove inappropriate descriptions.
References
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
1.11.0
Description
Abstract
- Add build test for arm on qemu.
- Start supporting build scenario_simulator_v2 on arm CPU.
- Update embree version to 4.1.0 for arm support.
Background
embree supports arm CPU, but in ubuntu repository, libembree-dev package only support on x86 CPU.
So, we could not build scenario_simulator_v2 on arm CPU.
Details
- Add embree_vendor package to scenario_simulator_v2 repository.
- Add build tests on github actions.
References
#1094
tier4/sim_evaluation_tools#260
Destructive Changes
N/A
Known Limitations
This pull request only supports successful builds on ARM CPUs, and does not provide full support for execution on ARM CPUs.
Related Issues
1.10.0
Description
Abstract
Added customization point CustomNoiseApplicator for Autoware developers to implement a method for calculating the positional noise that simple_sensor_simulator's DetectionSensor applies to detected_objects.
This pull request also includes the following three bug fixes found in its implementation.
- A bug that makes the actual recognition distance 300 m when DetectionSensor is set to 300 m or more
- A bug that causes invalid (empty)
detected_objectsto be published from the start of the simulation until the number of seconds set for the sensor's recognition delay time has elapsed - A bug that causes invalid (empty) ground truth objects to be published from the start of the simulation until the number of seconds set for the sensor's recognition delay time has elapsed
In addition, the process by which DetectionSensor lists entities that are within the sensor's range was extremely inefficient and was refactored.
Background
The developer of Autoware asked us to try an arbitrary method of applying position noise for planner development, such as "increasing the position noise according to the distance between Autoware and the recognition target". In order to make it easy for them to do this, it became necessary to provide a customization point that would allow them to easily replace the existing default noise application functionality while keeping it in place.
Details
DefaultNoiseApplicator and CustomNoiseApplicator
The DefaultNoiseApplicator implements conventional noise handling and the CustomNoiseApplicator inherits it. DetectionSensor<>::update uses CustomNoiseApplicator, but Custom only inherits from DefaultNoiseApplicator and does not define any member functions, so the actual work is done by DefaultNoiseApplicator.
And (as the comments in the code indicate) the contents of the CustomNoiseApplicator are intended to be implemented by Autoware developers as needed.
Refactoring
The process by which DetectionSensor lists entities that are within range of the sensor originally looked like this:
- List the names of entities that are within 300 m (this is a fixed value, one of the bugs fixed) of the sensor.
- List the names of the entities listed in 1 that are within X m (this is an externally given parameter) of the sensor.
- Copy the data of the entities whose names match the names listed in 2 to a new vector.
The above has been changed by this pull request to "iterate (not copy) on non-Ego entities that are within a distance of X meters".
Related Issues
1.9.1
1.9.0
Description
Abstract
Enable reset behavior plugin of entity.
Background
Previously, no means was provided to reset the behavior plugin, and the state had to be saved and respawned.
This pull request provides functionality to allow plugins to be replaced more easily.
Details
Enable reset behavior plugin of entity.
You can use this feature by function below.
void API::resetBehaviorPlugin(const std::string & name, const std::string & behavior_plugin_name)First argument is the name of the entity you want to reset behavior plugin.
Second argument is the name of the behavior plugin you want to set.
Internally, the following operations are performed
- Save entity state and parameters.
- Despawn and respawn target entity.
- Reset acceleration/twist/behavior parameters to the target entity.
References
Destructive Changes
N/A
Known Limitations
API::resetBehaviorPluginfunction cannot be called on non-spawned EntityAPI::resetBehaviorPluginfunction cannot be called for entities other than vehicle/pedestrian because behavior plugin does not exist for entities other than vehicle/pedestrian.
Related Issues
1.8.0
Description
Abstract
- The maximum speed, maximum acceleration, etc. of the vehicle to be used by the vehicle control algorithm can be specified in ObjectController.
- Fixed a bug that caused the target speed to be treated as an error instead of being corrected if the target speed specification exceeded the speed limit.
- API::setVelocityLimit function was performing an operation that did nothing.
- Fixed a bug that caused scenarios to fail with an exception when 0 was specified for the speed limit, acceleration limit, acceleration rate limit.
Background
About ObjectController in OpenSCENARIO.
Currently, it is not possible to specify in ObjectController the maximum speed, maximum acceleration, etc. of the vehicle to be used by the vehicle control algorithm.
Therefore, the only way to specify these parameters is to use SpeedProfileAction, which specifies the target speed at the same time.
This Pull Request improves this situation and allows the parameters to be set in the ObjectController.
About velocity limit
When the maximum speed of Entity was set using API::setVelocityLimit function and OpenSCENARIO's AssingControllerAction or ObjectController., it was doing "nothing", so the maximum speed was not set.
After this Pull-Request merged, the maximum speed is set.
Details
The reason I want to write limitations in ObjectController this time is because I want to specify the acceleration limit of driver behaviors that will continue to be applied as long as Entity exists in the simulation.
I searched this xsd for "Acceleration" and found that the only two types of acceleration that can be specified for an Entity are DynamicConstraints and Performance.
Among these, "Performance" specifies the "maximum acceleration that the vehicle Entity can physically achieve," so it does not match the purpose of this search.
The remaining "DynamicConstraints" can be used for LateralDistanceAction, LongitudinalDistanceAction, and SpeedProfileAction.
LateralDistanceAction
See also official document.
This Action cannot "specify an acceleration limit for Driver that will continue to be applied as long as the Entity exists in the simulation" and does not fit the purpose of this time.
LongitudinalDistanceAction
See also official document.
It does not fit this purpose for the same reason as LateralDistanceAction.
SpeedProfileAction
It does not fit this purpose for the same reason as LateralDistanceAction.
After conducting the above review work, it was determined that it would be appropriate to allow the ObjectController to write limits such as maximum acceleration.
After this pull request is merged, you will be able to set acceleration limits, etc. in the following format.
See here for samples below.
Entities:
ScenarioObject:
- name: Npc1
Vehicle:
name: ''
vehicleCategory: car
BoundingBox:
Center:
x: 0
y: 0
z: 1.25
Dimensions:
length: 4
width: 1.8
height: 2.5
Performance:
maxSpeed: 50.0
maxAcceleration: INF
maxDeceleration: INF
Axles:
FrontAxle:
maxSteering: 0.5236
wheelDiameter: 0.6
trackWidth: 1.8
positionX: 2
positionZ: 0.3
RearAxle:
maxSteering: 0.5236
wheelDiameter: 0.6
trackWidth: 1.8
positionX: 0
positionZ: 0.3
Properties:
Property: []
ObjectController:
Controller:
name: ''
Properties:
Property:
- name: maxSpeed
value: 2.5
- name: maxAcceleration
value: 1.0
- name: maxAccelerationRate
value: INF
- name: maxDeceleration
value: 1.0
- name: maxDecelerationRate
value: INFReferences
Destructive Changes
Changed behavior of the AssignControllerAction
Although this bug fix is intended to comply with the OpenSCENARIO standard, some existing scenarios were found to have been judged successful by the bug to be fixed.
In the past, in some scenarios, the maximum speed was set to 0 using AssignControllerAction to stop the PedestrianEntity before the pedestrian crossing.
When the maximum speed was specified in AssignControllerAction, it should not have been higher than that, but the function used inside it was behaving as if it was working as intended by the scenario writer because it was "doing nothing".
In this situation, I recommend to use SpeedAction instead of using AssingControllerAction if you want to set target speed of the entity. (e.g A pedestrian is stopped before an intersection.)
Example is below.
Not recommended description method
# Setting `target linear velocity` of the entity.
- LongitudinalAction:
SpeedAction:
SpeedActionDynamics:
dynamicsDimension: time
value: 0
dynamicsShape: step
SpeedActionTarget:
AbsoluteTargetSpeed:
value: 0
# Setting `maximum linear velocity` of the entity.
- ControllerAction:
AssignControllerAction:
Controller:
name: ''
Properties:
Property:
- name: maxSpeed
value: '0'Recommended description method
# Setting `target linear velocity` of the entity.
- LongitudinalAction:
SpeedAction:
SpeedActionDynamics:
dynamicsDimension: time
value: 0
dynamicsShape: step
SpeedActionTarget:
AbsoluteTargetSpeed:
value: 0Known Limitations
N/...
1.7.1
Description
Abstract
When merged pull-request is edited, the release workflow executed wrongly.
It can be avoided in operation, but the possibility of human error remains, so I remove the trigger in this pull-request.
Background
N/A
Details
N/A
References
The releases that published wrongly
- https://github.com/tier4/scenario_simulator_v2/releases/tag/1.7.0
- https://github.com/tier4/scenario_simulator_v2/releases/tag/1.6.0
Destructive Changes
N/A
Known Limitations
N/A
1.7.0
Caution
This release was created by miss operation.
There are no additional changes with this release.
Description
Description
Abstract
- consider z-axis in euclidean distance evaluation
- fit pitch angle of entity poses to HDMap
- add
consider_pose_by_road_slopeflag to switch function - update new scenarios and tests
Note: All the features can be toggled by consider_pose_by_road_slope.
Background
One of the characteristics of scenario_simualtor_v2 is that it is a simple and lightweight simulator.
Therefore, we have mainly dealt with simulations on a 2D plane without considering the Z direction or pitch/roll axes.
However, as the behavior on slopes is now being checked in autoware developing, simulation on a 2D plane alone is no longer able to cover the evaluation of Planning/Control, which is the main evaluation target of scenario_simualtor_v2.
So, we started to support simulation on 3D pose.
Details
Note: I would like to thank @dmoszynski for his great efforts for this pull-request.
Entity pose pitch-fitting to HDMap
As long as lane matching is successful, scenario_simulator_v2 tries to constrain the pose on the HDMap.
Specifically, the situation is as follows.
- spawning entity to position: OpenSCENARIO
AddEntityAction - teleporting entity to position: OpenSCENARIO
TeleportAction - setting goal: OpenSCENARIO
AcquirePositionAction - setting route
- OpenSCENARIO
FollowTrajectoryAction - OpenSCENARIO
AssignRouteAction
- OpenSCENARIO
The z fitting to HDMap was already performed in scenario_simulator_v2 until now.
But the entity pose fitting was not complete until now: pitch and roll angle were not fitted to HDMap.
In this pull-request, pitch-fitting is implemented.
With OpenSCENARIO WorldPosition / RelativeWorldPosition / RelativeObjectPosition, scenario_simulator_v2 will be performing both of z-fitting and pitch-fitting.
With OpenSCENARIO LanePosition, scenario_simulator_v2 will be performing only pitch fitting.
( Other position types are not supported in scenario_simulator_v2 now )
The pitch-fitting is also affected to bounding-box-based distance evaluation(freespace=true), because the orientation of entity bounding-box can be changed by pitch-fitting.
Entity that specified pitch=0 and consider_pose_by_road_slope=False
vokoscreenNG-2023-12-20_19-23-04.mp4
Entity that specified pitch=0 and consider_pose_by_road_slope=True
wolrd_fix.mp4
Distance evaluation
The euclidean distance evaluation in OpenSCENARIO DistanceCondition / RelativeDistanceCondition / ReachPositionCondition is performed in 2D plane previously.
In this pull-request, I implemented 3D euclidean dintance evaluation.
References
Destructive Changes
behavior changes
Some of OpenSCENARIO Actions, Conditions, traffic_simulator::API functions have destructive changes in terms of the behavior.
Please see detail section for a detailed explanation of the behavior changes.
All bahavior changes are caused by sloped or uneven roads on the map.
There should be almost no difference on a flat map, but there are some changes, so you may need to modify the scenario.
However, these changes correct what was wrong in the past, so it is recommended that you accept them.
If you really want to use the old behavior, please use the version before this pull-request or specify consider_pose_by_road_slope=False.
API schema changes
In this pull-request, some of API functions were added a boolean argument to toggle its behavior.
But the changes have backward-compatibility in terms of API interface, because all the additional argument have default value.
Known Limitations
No roll-fitting to HDMap
In this pull-request, orientation fitting is implemented for pitch angle only.
This is because it follows the implementation of simple_planning_simulator in autoware.universe.
No orientation-fitting to HDMap in OccupancyGridSensor
The GridMap output from scenario_simulator_v2 is always horizontal regardless of the road slope.
This is because current implementation of autoware.universe does not consider the roll and pitch axes.
