Releases: tier4/scenario_simulator_v2
5.2.1
Description
Abstract
Function getFollowingLanelets has confusing functionality or imprecise naming. Consider the following invocation: getFollowingLanelets(120660, {120660, <random-lanelets>}, 10000, true), then will be added to the returned vector unconditionally.
Function getPreviousLanelets has a mistake. The function is supposed to process one lanelet in every iteration, but every iteration starts from the lanelet passed as the argument. The result will be the lanelet passed as the argument and many copies of the one - previous lanelet. The mistake was introduced in change 3fc8c0a#diff-da44510bdbbba766d1ba47318640cfd8bcff2e350eafe3d77d364bfbf70e25cdL745-L770. The previous implementation seems to have been right.
Details
Function getFollowingLanelets was changed to check if candidates lanelets are actually following each other.
Function getPreviousLanelets was rewritten to match previous implementation.
References
Jira ticket: internal link
Destructive Changes
There are no destructive changes.
Related Issues
5.2.0
Description
Abstract
This pull request support byType element in CollisionCondition.
Background
Currently, there is no implementation for this element.
Details
This PR contains a new class, ByObjectType.
The given type is converted to entity list and a collision check is performed on them.
There is a new scenario titled "collision_condition_by_type." This scenario tests whether collisions with each type of object are accurately detected. It will pass if collisions are detected between vehicles, between a vehicle and a barricade, and between a vehicle and three pedestrians.
References
None
Destructive Changes
None
Known Limitations
None
Related Issues
5.1.1
Description
Abstract
This PR includes modifications based on the results of static analysis performed by SonarCloud. Please refer to the SonarCloud reference for details on the issue fixes.
Background
N/A
Details
N/A
References
- https://sonarcloud.io/project/issues?open=AZJwAZGalcZ2d3dSAT8C&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJwAZGslcZ2d3dSAT8F&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJwAZGLlcZ2d3dSAT8A&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTJNjvEq9OQMnMCh&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTJNjvEq9OQMnMCi&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTJNjvEq9OQMnMCj&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTJUjvEq9OQMnMCy&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJwAZH5lcZ2d3dSAT8M&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJwAZH5lcZ2d3dSAT8N&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJwAZH5lcZ2d3dSAT8O&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJwAZH5lcZ2d3dSAT8P&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJS0wrRtJsnZH2iyX97&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTIMjvEq9OQMnMAh&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTIMjvEq9OQMnMAi&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJS0wrRtJsnZH2iyX98&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTIMjvEq9OQMnMAj&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJS0wqNtJsnZH2iyX9v&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJS0wqNtJsnZH2iyX9w&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJS0wqNtJsnZH2iyX9x&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJS0wqNtJsnZH2iyX9y&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTIfjvEq9OQMnMBP&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTIfjvEq9OQMnMBQ&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTIfjvEq9OQMnMBS&id=tier4_scenario_simulator_v2
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
5.1.0
Description
Abstract
This pull-request supports TrafficLightGroupArrayand add awf/universe/20240605 as architecture_type for it.
Details
supporting TrafficLightGroupArray
Currently, autoware_auto_perception_msgs/TrafficSignalArray and autoware_perception_msgs/TrafficSignalArray are supported for trafffic light in scenario_simulator_v2.
However, I found that this was not enough to keep up with the latest Autoware.
In latest Autoware, autoware_perception_msgs/TrafficSignalArray, the traffic light message supported in scenario_simulator_v2, is not used and autoware_perception_msgs/TrafficLightGroupArray is used instead.
So, this pull-request supports autoware_perception_msgs/TrafficLightGrupArray.
architecture_type design
The architecture_type is designed for switching message type (especially, messages for traffic light) of publishers for various autoware version.
Now, there are 2 architecture_type as below.
awf/universeautoware_auto_perception_msgs/TrafficSignalArrayfor traffic lights
awf/universe/20230906autoware_perception_msgs/TrafficSignalArrayfor traffic lights
In this PR, I added awf/universe/20240605 as below.
awf/universe/20240605autoware_perception_msgs/TrafficLightGroupArrayfor traffic lights
Note
awf/universe will be deleted in near future after dropping support for messages related to Autoware.Auto
References
regression test: OK
Destructive Changes
None
Known Limitations
None
Related Issues
5.0.2
Description
Abstract
This PR includes modifications based on the results of static analysis performed by SonarCloud. Please refer to the SonarCloud reference for details on the issue fixes.
Background
N/A
Details
N/A
References
- https://sonarcloud.io/project/issues?open=AZINWTIMjvEq9OQMnMAi&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJS0wrRtJsnZH2iyX98&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTIMjvEq9OQMnMAj&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTKejvEq9OQMnMEw&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTKTjvEq9OQMnMEs&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJS0wsGtJsnZH2iyX-H&id=tier4_scenario_simulator_v2
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
5.0.1
Description
Refactor curvature sampling loop to avoid using float counter
Abstract
Refactor of the curvature sampling loop in hermite_curve.cpp to avoid using a float counter, improving precision and readability.
Background
This refactor addresses the potential issues with floating-point precision in the curvature sampling loop.
Details
The original loop used a floating-point counter (for (double s = 0; s <= 1; s = s + 0.1)). This has been refactored to an integer-based loop with a fixed sample count of 10, which eliminates the need for floating-point arithmetic in the loop control.
References
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
5.0.0
Description
Abstract
This pull request introduces the change of removing any traffic lights functionality from EntityManager class and encapsulating it inside the new TrafficLights class.
The responsibility of managing traffic lights have been moved to the API.
The change got rid of simulation_api_schema proto messages from traffic_simulator and transitioned to using ROS messages only. Proto messages are now used exclusively in simple_sensor_simulator.
The general goal of this PR is to divide scenario_simulator_v2 into smaller modules with some specific functionality and responsibilities. Apart from module dividing, some code has been refactored to make it cleaner, simpler and easier to read.
Background
This pull request is one of many that aim to modularize the scenario_simulator_v2.
Details
The traffic lights functionality has been aggregated in one master TrafficLights class. This way, all components that make up traffic lights are grouped together and managed by one resource. This master class - along with the responsibility - has been moved to the API. Although the EntityManager does hold a reference to TrafficLights, which is needed by NPCs.
Newly developed classTrafficLights and its components contain some additional functionality that has been spread throughout the whole scenario_simulator_v2 codebase, like the member functionisRequiredStopTrafficLightState or getConventionalTrafficLightsComposedState.
The new traffic lights classes encapsulated by TrafficLights are designed in such a way, that they do not share the underlying TrafficLight object, but act as a middleman modifying the TrafficLight object as needed:
Some additional traffic light message type conversions have been developed in order to get rid of the simulation_api_schema dependency in traffic_simulator and make message managing easier. Also, the traffic lights are now responsible for generating the messages:
Additionally, a dedicated message publisher has been developed for simple_sensor_simulator:
Please note that this PR removes all tests for TrafficLightManager as these tests have no purpose with the new TrafficLights implementation.
New tests have been developed on this branch (here is a diff), but they have not been added to this PR, as this is a large PR by itself as is now.
We are planning to cast a new PR with just the tests. However, if the reviewer would like to have the tests included in this PR as well, we can do that, just please let us know.
Please just note, that then (with tests included) this PR will become very large with over 2000 additions (tests alone have 1000 additions).
Additional note: many of the changes are restructuring, so the code is changed only a little, if at all, but it has been moved to some other places like for example this has been moved here.
Likewise, these type conversions have been moved from publish member functions to appropriate traffic lights functions, which use cast conversions defined here.
References
INTERNAL LINK
PREVIOUS INTERNAL LINK
Regression tests
Regression report
Local tests with deeper regression investigation (no regression confirmed)
Destructive Changes
None
Known Limitations
None
Related Issues
4.5.0
Description
Abstract
This pull-request extends the default matching distance offset for lanelet matching for ego and vehicle entities, from 1.0m to 1.5m.
Background
In some scenarios, ego or vehicle entities during lane change lost matching to lanelet.
This is not a matter at traffic_simulator, but for BehaviorTree actions especially FollowFrontEntityAction.
Normally, if you cut in front of a vehicle entity, it will slow down due to the action of FollowFrontEntityAction.
But it does not slow down when crossing entity losts a lanelet-matching because FollowFrontEntityAction don't recognize lanelet-matching-less entities as front entities.
Important
This lost of lanelet matching mainly comes from a lack of default matching distance.
So, I will extend it in this pull-request.
Details
Before
The red stopline by FollowFrontEntityAction is lost for a moment when ego is cutting in.
shoulder_matching_1m.webm
After
The red stopline by FollowFrontEntityAction is NOT lost for a moment when ego is cutting in.
shoulder_matching_2m.webm
References
Destructive Changes
This pull-request could mean lane matching will now happen in places where it wasn't possible before, which is a good thing.
However, increasing this matching distance caused more failures in internal scenarios, especially since it allowed distance measurements in places where distance measurements in the lane coordinate system were NaN. This is why the increment is only 0.5m.
Known Limitations
Related Issues
4.4.1
Abstract
Please refer to this issue.
Details
- Inversion of order in if statements
if (!continuous && isTargetSpeedReached(target_speed)) --->
if (isTargetSpeedReached(target_speed) && !continuous)
this forces calculation of relative_target_speed, which throws immediately, if invalid.
2. Numerous const qualifiers added.
3. A single cpp_mock_scenario has been modified in order to update other_status variable.
References
Related Issues
4.4.0
Abstract
This pull requests fixes issue described here
Details
- Simplification of
HdMapUtils::getLongitudinalDistancefunction logic, while retaining its functionalify. - Additional matching: previously matching occurred at the starts of the lanelets, now matching is also performed at
0.5 * min(from_lanelet, to_lanelet)to cover the corner case (please see the mentioned issue description). - Additional unit tests for the modified function.
- During development i have decided that using the first instead of the second approach is far superior (refer to this discussion)
- This approach produces cleaner code in general.
- This approach does not require modification of the underlying centerline's
math::geometry::CatmullRomSpline. - The working POC of the first approach is still implemented in the first commit of this PR.
- Docs have been updated accordingly.
- Some recurring scenario conditions have been updated. Currently, majority of these conditions are too precise, this disallows any changes in the calculations.