4.3.18

Description

Abstract

Use Boost.JSON instead of nlohmann-json.
This will make faster openscenario_interpreter by reducing the cost of publishCurrentContext

Background

publishCurrentContext is heavy method and took ~20ms in worst case.
However, this is required to visualize simulation status in our platform.
To achieve simulation with large number of entities, this is a major bottleneck.

Details

In this PR, I will replace JSON serialization library which consume long time in publishCurrentContext.
Boost.JSON is faster library to JSON serialization. Also, it is easy to use and well maintained.

Destructive Changes

This PR will change the way to writing JSON serialization operator <<.
But output should be same as before.

Known Limitations

To faster serialization, we should use move semantics and same allocator to avoid copy of value.

Related Issues

4.3.17

Description

Abstract

Remove some warnings from SonarCloud.

Background

Static analysis results from SonarCloud found non-recommended formats and other issues in the geometry library.

Details

I have fixed some of the areas where warnings were issued.

References

https://sonarcloud.io/issues?issueStatuses=OPEN%2CCONFIRMED

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

4.3.16

Description

This pull request adds checks for negative discriminants before calculating square roots in the longitudinal speed planning logic to prevent invalid operations that could occur when the discriminant is negative.

Abstract

This pull request introduces validation for negative discriminants in the LongitudinalSpeedPlanner to prevent invalid square root calculations during acceleration and deceleration constraint planning.

Background

In the current implementation, the code attempts to compute the square root of a discriminant that can occasionally be negative. This can lead to exceptions and undefined behavior. Adding checks before these calculations ensures stability and prevents such issues.

Details

The changes involve checking if the discriminant is negative before performing a square root operation in both the acceleration and deceleration branches. If the discriminant is negative, a semantic error is thrown to handle the situation appropriately. This fix addresses the problem where the target speed may be too high or too low relative to the acceleration or deceleration rate, leading to negative values in the discriminant.

References

N/A

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

4.3.15

Description

The same issue as RJD 1200 happens, when scenario_simulator_v2 and Autoware are built in RelWithDebInfo.

Abstract

The issue that occurs is related Ego position update - position is not updated correctly and EgoEntitySimulation::getCurrentPose() returns incorrect values.
The issue is most likely related to the optimization performed by the compiler when the -DCMAKE_BUILD_TYPE=RelWithDebInfo is used - more in the details section.

Background

To get rid of the issue, it was necessary to cast the temporary structure Eigen::Procuct<...> to Eigen::Vector3d - otherwise the optimization resulted in different results.

Details

• I’ve added a rotation matrix as a constant attribute of the EgoEntitySimulation (now the matrix is created at the time of initialization).

  • Previously it was created in many places every time it was needed, this gives a computational profit and also some form of safeguard.

https://github.com/tier4/scenario_simulator_v2/blob/dd31892f04fb2410e32952d474528265af555fa4/simulation/simple_sensor_simulator/include/simple_sensor_simulator/vehicle_simulation/ego_entity_simulation.hpp#L56

• I’ve ensured that the temporary Eigen type that can cause issues is cast to Eigen::Vector3d.

  • It is worth to pay extra attention to the commonly used auto in ss2 code and try to avoid it in parts where Eigen structures are used.

https://github.com/tier4/scenario_simulator_v2/blob/dd31892f04fb2410e32952d474528265af555fa4/simulation/simple_sensor_simulator/src/vehicle_simulation/ego_entity_simulation.cpp#L416-L417

• The PR also includes fixes to the random001 scenario that @SzymonParapura developed in RJD-1200 (the PR was not merged but closed - the fixes are required to make the scenario work well)

https://github.com/tier4/scenario_simulator_v2/blob/dd31892f04fb2410e32952d474528265af555fa4/mock/cpp_mock_scenarios/src/random_scenario/random001.cpp#L204-L216

• I’ve conducted tests of the fixed version - everything works fine for -DCMAKE_BUILD_TYPE=RelWithDebInfo - in this jira command I've attached recordings as evidences.
• In this comment I also described more details about the issue itself.

References

RJD-1296 Jira ticket

Destructive Changes

--

Known Limitations

--

Related Issues

4.3.14

Abstract

This pull request removes unused functions related to stand-still duration updates across multiple entities to optimize the codebase.

Background

The stand-still duration feature is being deprecated, so the related code is being removed to streamline maintenance and improve performance.

Details

• Removed updateStandStillDuration function from EgoEntity, MiscObjectEntity, PedestrianEntity, and VehicleEntity classes.
• Removed test cases related to the stand-still duration logic.
• Updated job list registration in EntityBase to handle stand-still duration calculation within a job.

References

N/A

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

4.3.13

Description

Abstract

Changed back to using /autoware/state to get state of autoware(Includes support for the latest autoware_xx_msgs )

Background

Somehow autoware state API for has downgraded to old one in #1060.
Due to this change, the old spec, which mixed Autoware and Emergency states, are started to use, so emergency state which occurred immediately after engagement caused a time out.

Details

Regression risk analysis

Under autoware_auto_xx_msgs environment, we have used /autoware/state topic before #1060 and worked well.
and /autoware/state topic has maintained from after #1060 merged to today.
Starting from v0.29.0 in tier4/autoware.universe, /autoware/state uses autoware_system_msgs, which is being maintained and will continue to be supported in the future.

https://autowarefoundation.github.io/autoware.universe/main/system/autoware_default_adapi/document/autoware-state/

So, it is safe to use /autoware/state from the past to the future.

References

Regression test: OK (Note: X2 regression is expected)

Destructive Changes

None

Known Limitations

None

Related Issues

4.3.12

Description

Allow coverage and CI static analysis to be uploaded to Sonar Cloud

Abstract

Allow coverage and CI static analysis to be uploaded to Sonar Cloud

Background

As a part of unit test improvements, We would like to add coverage to Sonar Cloud

Details

Allow coverage and CI static analysis to be uploaded to Sonar Cloud.

References

https://sonarcloud.io/project/overview?id=tier4_scenario_simulator_v2

Destructive Changes

N/A

Known Limitations

.hpp files are still currently not being scanned, and their coverage is not being uploaded. Further investigation and testing is required.

Related Issues

4.3.11

Description

Abstract

This pull request removes the updateTraveledDistance function from several entity classes. The function has been integrated into the job list management system for better cleaner code.

Background

The updateTraveledDistance function was previously implemented in multiple entity classes. However, a more efficient and centralized method to track traveled distance through the job list system was introduced. This refactor eliminates redundant code and ensures consistency across different entity types.

Details

The following changes were made:

• Removed the updateTraveledDistance function from EntityBase, EgoEntity, PedestrianEntity, and VehicleEntity.
• The traveled distance is now updated through the job list system in EntityBase using a new job that calculates the traveled distance based on linear velocity.
• Updated unit tests by removing tests specifically for updateTraveledDistance as the functionality is now handled by the job system.

References

N/A

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

4.3.10

Description

Abstract

Fixed problems in Dockerfile which was detected by SonarCloud.

Background

By using Sonorcloud analystics, I found some problems about docker.

Details

Fix some problems about docker with high severity

References

• https://sonarcloud.io/project/issues?open=AZINWTKtjvEq9OQMnMFH&id=tier4_scenario_simulator_v2
• https://sonarcloud.io/project/issues?open=AZINWTKqjvEq9OQMnME6&id=tier4_scenario_simulator_v2
• https://sonarcloud.io/project/issues?open=AZINWTKqjvEq9OQMnME_&id=tier4_scenario_simulator_v2

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

4.3.9

Description

Abstract

Add Unit/Integration test for RelWithDebInfo build type.

Background

In #1402, I found that some of functions does not works valid in RelWithDebInfo build type.

Details

• Add Unit/Integration test for RelWithDebInfo build type.
• Use concurrency in GitHub Actions and specify cancel-in-progress = true

References

#1402

Destructive Changes

N/A

Known Limitations

Something wrong when you build with Debug build type.

Related Issues