Releases: tier4/scenario_simulator_v2
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.
References
Related Issues
4.3.27
Description
Abstract
Add comment for empty functions.
Background
SonarCloud warned me to comment on functions with no operation behavior.
Details
Leave information in comments in terms of historical background and traceability of design information.
References
https://sonarcloud.io/project/issues?open=AZINWTGyjvEq9OQMnL_U&id=tier4_scenario_simulator_v2
https://sonarcloud.io/project/issues?open=AZJwAY5JlcZ2d3dSAT63&id=tier4_scenario_simulator_v2
https://sonarcloud.io/project/issues?open=AZINWTDsjvEq9OQMnL7a&id=tier4_scenario_simulator_v2
https://sonarcloud.io/project/issues?open=AZJwAY5JlcZ2d3dSAT64&id=tier4_scenario_simulator_v2
https://sonarcloud.io/project/issues?open=AZINWTDvjvEq9OQMnL7g&id=tier4_scenario_simulator_v2
https://sonarcloud.io/project/issues?open=AZINWTDvjvEq9OQMnL7h&id=tier4_scenario_simulator_v2
https://sonarcloud.io/project/issues?open=AZINWTDvjvEq9OQMnL7i&id=tier4_scenario_simulator_v2
https://sonarcloud.io/project/issues?open=AZINWTDvjvEq9OQMnL7j&id=tier4_scenario_simulator_v2
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
4.3.26
Abstract
This pull request introduces code optimizations and improvements, including the removal of unused variables, added override qualifiers, standardization of declarations, and adjustments to lambda captures and explicit casts.
Background
To improve code clarity, performance, and maintainability, minor refactors and cleanup were conducted. These changes aim to ensure consistency and efficiency in the codebase.
Details
- Unused Variable Removal: Unused variables were removed to optimize memory usage.
- Inline Directives: Added missing inline directives where needed.
- Virtual Destructor: A virtual destructor was added for polymorphic classes to ensure proper resource management.
- Lambda Capture Adjustments: Unnecessary captures in lambdas were removed for performance.
- Override Qualifiers: Missing override qualifiers were added to functions to improve code clarity.
- Standardizing Declarations: Standardized declaration patterns for better readability and consistency.
- Explicit Casts: Implemented explicit casts to prevent implicit conversion issues.
References
This PR fixes errors or warnings that appeared during Clang builds.
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
4.3.25
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=AZINWTFwjvEq9OQMnL-M&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTFwjvEq9OQMnL-N&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTFsjvEq9OQMnL-I&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTFujvEq9OQMnL-K&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTFujvEq9OQMnL-L&id=tier4_scenario_simulator_v2
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
4.3.24
Abstract
This pull request fixes the logic to remove duplicate topics in the updateTopicCandidates function, improving the behavior by correctly sorting and eliminating duplicates from the topic list.
Background
This change was necessary because the previous implementation did not properly handle the removal of duplicate topics, which could lead to incorrect behavior when selecting topics in the UI.
Details
The fix was made by adding a call to std::sort() followed by std::unique(), ensuring that the topics_ vector is both sorted and has its duplicates removed. The previous implementation only applied std::unique() without sorting, which led to incomplete duplicate removal.
References
Destructive Changes
N/A
Known Limitations
N/A