Skip to content

Releases: tier4/scenario_simulator_v2

7.0.4

13 Dec 03:28
Compare
Choose a tag to compare

Description

Abstract

SpeedCondition was updated to comply with OpenSCENARIO XML 1.3.1 in #1469, but this caused a loss of compatibility with previous behavior. This pull request solves this by adding a compatibility mode parameter that allows SpeedCondition to maintain the previous behavior.

Background

None.

Details

Scenario UC-v3-E-04-00101_002_case01_cmn_general fails in master branch, but succeeds in this pull request's branch. And when moving backwards, a negative value is returned from SpeedCondition as before.

References

None.

Destructive Changes

None.

Known Limitations

None.

Related Issues

7.0.3

13 Dec 01:04
Compare
Choose a tag to compare

Description

Please check examples and comment out this sentence. Minimal example is here and detailed example is here

Abstract

I fixed API to make request to enable autoware control when the ego respawns.

Background

Now the autoware control will be disable when the ego respawns. I guess that it not expected behavior.

Details

I confirmed the autoware control was automatically enabled when the ego respawns by using API::respawn.

References

N/A

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

7.0.2

12 Dec 04:11
Compare
Choose a tag to compare

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 this declaration by a structured binding declaration.

This function should be declared "const".

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

7.0.1

11 Dec 09:17
Compare
Choose a tag to compare

Description

Abstract

Adapt optional StartTrigger in Act (OSC 1.3).

Background

From OSC 1.3, StartTrigger in Act become optional. And default behavior is If no trigger is defined, the act starts when the Storyboard enters runningState.

Details

I set default value for StartTrigger.
Also I added always_true constant to Trigger. In some case, we need Trigger that should be evaluated to be true. This constant helps implement such case(e.g. #774).

Known Limitations

openscenario_utility does not use OSC 1.3 schema. Without using it, I cannot use optional StartTrigger because validation by it will fail.
In my local environment, I checked this PR works by modifying openscenario_utility.

Related Issues

7.0.0

10 Dec 10:02
Compare
Choose a tag to compare

Description

Abstract

  • replace autoware_auto_xx_msgs with autoware_xx_msgs
  • use only one source for /autoware/state
  • finish supporting awf/autoware architecture_type ( traffic light for autoware_auto_perception_msgs )
  • use awf/autoware/20240605 as default architecture_type

Background

Details

simple message migrations

  • autoware_auto_vehicle_msgs -> autoware_vehicle_msgs
    • ControlModeReport.msg
    • GearReport.msg
    • SteeringReport.msg
    • TurnIndicatorsReport.msg
    • VelocityReport.msg
    • ControlModeCommand.srv
  • autoware_auto_perception_msgs -> autoware_perception_msgs
    • TrackedObjects.msg
    • TrackedObject.msg
    • DetectedObjects.msg
    • DetectedObject.msg
    • ObjectClassification.msg
    • DetectedObjectKinematics.msg
    • Shape.msg

complicated message migrations

1 vs 1

before after
autoware_auto_control_msgs/AckermannControlCommand autoware_control_msgs/Control
autoware_auto_planning_msgs/PathWithLaneId tier4_planning_msgs/PathWithLaneId
autoware_auto_map_msgs/HADMapBin autoware_map_msgs/LaneletMapBin

others

before after
autoware_system_msgs/AutowareState
autoware_auto_system_msgs/AutowareState
autoware_system_msgs/AutowareState
autoware_auto_perception_msgs/TrafficSignalArray
autoware_perception_msgs/TrafficSignalArray
autoware_perception_msgs/TrafficLightGroupArray
autoware_perception_msgs/TrafficSignalArray
autoware_perception_msgs/TrafficLightGroupArray

References

Destructive Changes

After this pull-request, scenario_simulator_v2 does not support autoware_auto_xx_msgs for interfaces.
To use with autoware_auto_xx_msgs, please use older versions of scenario_simulator_v2.

Known Limitations

None

Related Issues

6.3.1

10 Dec 07:25
Compare
Choose a tag to compare

6.3.0

10 Dec 05:03
Compare
Choose a tag to compare

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 road and road_shoulder into solid(un-lane-changeable) from dashed(lane-changeable)
  • allow lane-changes everywhere in VEHICLE_WITH_ROAD_SHOULDER rouitng 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: false
    • lanelet::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.)

image

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.
image

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).
image

References

Regression Test: OK

Destructive Changes

Please see "routing changes possibility due to this change" in Details section.

Known Limitations

Related Issues

6.2.5

09 Dec 07:22
Compare
Choose a tag to compare

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.

image

References

Regression Test: OK

Destructive Changes

Known Limitations

Related Issues

6.2.4

09 Dec 04:15
Compare
Choose a tag to compare

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

05 Dec 07:33
Compare
Choose a tag to compare

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".

implicit conversion loses floating-point precision: 'double' to 'const float'

Remove this redundant cast.

unused exception parameter 'e'

Destructive Changes

N/A

Known Limitations

N/A

Related Issues