Releases: tier4/scenario_simulator_v2
6.3.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
This function should be declared "const".
- https://sonarcloud.io/project/issues?open=AZLnNBxcQCmhgSgDjNx2&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZLnNBxcQCmhgSgDjNx3&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZLnNBxcQCmhgSgDjNx4&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZLnNBxcQCmhgSgDjNx5&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZLnNBxcQCmhgSgDjNx6&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZLnNBxcQCmhgSgDjNx7&id=tier4_scenario_simulator_v2
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
6.3.0
Description
Abstract
allow lane-changes everywhere in VEHICLE_WITH_ROAD_SHOULDER rouitng graph
Background
Basically, the lanelet2 lane change permission/disallowance setting is intended for Autoware and was not designed with the behavior of entities running in the traffic_simulator in mind.
Also, when an entity is commanded to change lanes in a scenario, it is considered appropriate to change lanes, even if that command ignores the Road Traffic Act and lane change settings.
Details
- make the linestrings between
roadandroad_shoulderintosolid(un-lane-changeable) fromdashed(lane-changeable) - allow lane-changes everywhere in
VEHICLE_WITH_ROAD_SHOULDERrouitng graph
details of getLeftLaneletIds / getRightLaneletIds changes
In this pull-request, I changed lanelet2 function mapping switched by include_oppsite_direction flag.
previous mappping
include_oppsite_direction: true(The de facto default)lanelet::routing::RoutingGraph::adjacentRights/adjacentLefts
include_oppsite_direction: falselanelet::routing::RoutingGraph::rights/lefts
incoming mappping
include_oppsite_direction: true- no mapping (throw an exception)
include_oppsite_direction: false(The de facto default)lanelet::routing::RoutingGraph::rights/lefts
Important
lanelet::routing::RoutingGraph::adjacentRights/adjacentLefts do not have the ability to acquire adjacent lanes,
including the opposite lane.
The only difference between rights and adjacentRights is whether the adjacent lanelet they acquire is routable or not.
(Both do not have the ability to acquire the opposite lanes.)
routing changes possibility due to this change
In this pull-request allows lane-changes everywhere.
This change will result in some changes to routing, as exemplified by the tests below.
Routing will always prioritize smaller cost (in this case, shorter distance), so longitudinal distance measurements may be smaller than before.
Before this pull-request
The routing graph and adjacent lane search options only allow you to get this route.
After this pull-request
By expanding the range of the RoutingGraph, we can compare more candidates and select a route with a shorter distance (in this case, the route is shorter if it goes on the inside of the curve).
References
Destructive Changes
Please see "routing changes possibility due to this change" in Details section.
Known Limitations
Related Issues
6.2.5
Description
Abstract
fix caluculation for the gravity by slope in ego entity simulation
Background
This bug was introduced in #1447
Details
- use pitch-filled map pose for ego pitch calculation
- fix sign in caluculation of
accelerlation_by_slope - fix pitch caluculation in tests
The accelerlation_by_slope caluculation is was done as shown in the figure below and reflected in the code.
References
Destructive Changes
Known Limitations
Related Issues
6.2.4
Description
Abstract
Added a static member function version of SpeedCondition::evaluate.
Background
The static version of SpeedCondition::evaluate is useful for implementing TimeToCollisionCondition, so we implemented it.
Details
None.
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
6.2.3
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
This PR has been split and submitted to avoid the issues that occurred in the following PR.
Replace the redundant type with "auto".
- https://sonarcloud.io/project/issues?open=AZINWTKTjvEq9OQMnMEp&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTKTjvEq9OQMnMEq&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZINWTKTjvEq9OQMnMEr&id=tier4_scenario_simulator_v2
implicit conversion loses floating-point precision: 'double' to 'const float'
- https://sonarcloud.io/project/issues?open=AZJS0wsGtJsnZH2iyX-F&id=tier4_scenario_simulator_v2
- https://sonarcloud.io/project/issues?open=AZJS0wsGtJsnZH2iyX-G&id=tier4_scenario_simulator_v2
Remove this redundant cast.
unused exception parameter 'e'
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
6.2.2
Description
Abstract
Added a static member function version of DistanceCondition::evaluate.
Background
The static version of DistanceCondition::evaluate is useful for implementing TimeToCollisionCondition, so we implemented it.
Details
None.
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
6.2.1
Description
Abstract
Added a static member function version of RelativeDistanceCondition::evaluate.
Background
The static version of RelativeDistanceCondition::evaluate is useful for implementing TimeToCollisionCondition, so we implemented it.
Details
None.
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
6.2.0
Description
Abstract
This pull request adds support for OpenSCENARIO XML 1.3.1 RelativeSpeedCondition.
Background
RelativeSpeedCondition is required internally to implement TimeToCollisionCondition.
Details
None.
References
Destructive Changes
None.
Known Limitations
None.
Related Issues
6.1.3
Description
Abstract
This pull request is a continuation of #1406.
It adds tests for the new implementation of the traffic lights.
After changes requested review in #1406 and other:
In order to make it possible to test the correctness of the generation the messages:
autoware_auto_perception_msgs::msg::TrafficSignalArrayautoware_perception_msgs::msg::TrafficSignalArrayautoware_perception_msgs::msg::TrafficLightGroupArraytraffic_simulator_msgs::msg::TrafficLightArrayV1
from simulation_api_schema::UpdateTrafficLightsRequest, new static method has been extracted:
In traffic_light_publisher.cpp can be found definitions of methods used in tests.
Background
This pull request is one of many that aim to modularize the scenario_simulator_v2.
Details
In the previous pull request, a new implementation of traffic lights has been added and tests developed for the previous implementation have been deleted.
This pull request introduces tests for the new implementation of traffic lights. These changes have been split into two PRs, because of the amount of changes. If these changes (this PR and the previous one) were introduced in one PR, it would have been very large (>2000 additions).
References
Destructive Changes
Known Limitations
Related Issues
6.1.2
Description
Abstract
The following minor changes were made to the interpreter code:
- The implementation of the file-local function
hypot, which switches dimensions depending on the parameterconsidier_pose_by_road_slope(the same function was copied to multiple files), was made into a single free function. - Old descriptions that remained in the documentation for the syntax
Entitieswere deleted.
Background
None.
Details
None.
References
None.
Destructive Changes
None.
Known Limitations
None.