Skip to content

Releases: tier4/scenario_simulator_v2

5.3.2

18 Nov 09:57
@github-actions github-actions
5.3.2
62fb007
Compare
Choose a tag to compare
5.3.2 Latest
Latest

Description

Abstract

Fixed an issue where AssignRouteAction could not be applied multiple times to a Vehicle entity controlled by Autoware.

Background

#1369 introduced a feature that allows AcquirePositionAction to be applied multiple times to Vehicle entities controlled by Autoware. At that time, an equivalent feature should have been introduced for AssignRouteAction as well as AcquirePositionAction, but this was overlooked. This pull request fixes that.

Details

Note that FollowTrajectoryAction belongs to RoutingAction, just like AcquirePositionAction and AssignRouteAction, but there is no need to introduce an equivalent feature. This is because FollowTrajectoryAction for Vehicle entities controlled by Autoware is a special operation that means overriding the control of the vehicle by a controller that is not Autoware (mainly a human).

References

None.

Destructive Changes

None.

Known Limitations

None.

Related Issues

Assets 2
Loading

5.3.1

18 Nov 09:35
@github-actions github-actions
5.3.1
4b32049
Compare
Choose a tag to compare
5.3.1

Description

Abstract

  • add RoutingGraphType enum class to specity types of routing graph
  • add RoutingGraphs class to manage routing graph and paired traffic rule class
  • replace EntityType with RoutingGraphType to specify types of routing graph

Background

The current HDMapUtils class uses the vehicle routing graph by default (even for pedestrians).
As the first step to bettter management of routing graph, this pull-request adds RoutingGraphs class.

In addition, the handling of shoulder lanes varies depending on the function, and there is no consistency.
In the future, I plan to develop a unified handling of shoulder lanes by adding a routing graph that includes road shoulders to the better routing graph management added in this pull request.

Details

  • HDMapUtils::getNextLaneletIds
    • add type argument to switch routing graph(default: VEHICLE for backward compatibility)
    • two overload has not type argument yet, because it treats road shoulder lanelet.
  • HDMapUtils::getPriviousLaneletIds
    • add type argument to switch routing graph(default: VEHICLE for backward compatibility)
      • one overload has not type argument yet, because it treats road shoulder lanelet and has a bug.
  • HDMapUtils::getRightLaneletIds
    • replace EntityType with RoutingGraphType in argument
  • HDMapUtils::getLeftLaneletIds
    • replace EntityType with RoutingGraphType in argument
  • HDMapUtils::getRoute
    • move inplementation into HDMapUtils::RoutingGraphs::getRoute
    • add type argument to switch routing graph(default: VEHICLE for backward compatibility)

References

Regression Test(OK)

Destructive Changes

Although there have been some additions to function arguments, all of this has been carefully implemented to ensure backward compatibility.

Known Limitations

Related Issues

Assets 2
Loading

5.3.0

18 Nov 06:47
@github-actions github-actions
5.3.0
a7047f2
Compare
Choose a tag to compare
5.3.0

Description

Abstract

Improve simulated manual override with FollowTrajectoryAction

Background

In previous version of scenario_simulator_v2, the control mode during the override is still AUTONOMOUS.
This could not be accurately simulated for manual overrides , so this pull request was created.

relationship with #1280

In #1280, I fixed a bug in TaskQueue that caused a major regression when Autoware went into EMERGENCY state immediately after starting a scenario.
The root cause of the regression was fixed in #1378, so I created this new pull request.

Details

Note

This section is copied from ManualOverrideWithFollowTrajectoryAction.md in this pull-request.

scenario_simulator_v2 simulates the manual override of Autoware, with FollowTrajectoryAction.
During the executing FollowTrajectoryAction, the control of the ego entity is taken over from Autoware to the FollowTrajectoryAction.

3 types of override for Autoware

There are 3 types of override for Autoware.

  • Local: Manually control the vehicle from nearby with some device such as a joystick.
    • This is one of operation modes.
  • Remote: Manually control the vehicle from a web application on the cloud.
    • This is one of operation modes.
  • Direct: Manually control the vehicle from handle, brake and/or accel directly.
    • Please note that this is not a operation mode but a control mode of vehicle interface.

override simulation in scenario_simulator_v2

vehicle interface simulation is a part of the ego vehicle simulation feature in scenario_simulator_v2.
scenario_simulator_v2 simulates a Direct override triggered by safety operators when a scenario commands overriding the ego vehicle by FollowTrajectoryAction.

3 steps scenario_simulator_v2 takes to simulate the overrides

1. triggering the override

In real vehicle, the override detected in vehicle internally and communicated to vehicle interface node such as pacmod_interface node.

In scenario_simulator_v2, openscenario_interpreter send an override flag via zmq interface between traffic_simulator and simple_sensor_simulator when FollowTrajectoryAction is started.

simple_sensor_simulator receives it and set the control mode to MANUAL like vehicle interface do when hardware override triggers detected.

2. during the override

traffic_simulator send ego status calculated to follow described in the scenario and simple_sensor_simulator overrides Autoware control with overwriting ego status by the received ego status.

3. finishing the override

When FollowTrajectoryAction is finished, traffic_simulator call service to enable autoware control and stop sending the override flag to simple_sensor_simulator via zmq communication.

This mimics the steps safety operators do in real vehicle via some human interfaces, in API level.

References

Destructive Changes

None

Known Limitations

scenario_simulator_v2 does not support a remote override for now.

Related Issues

Assets 2
Loading

5.2.3

18 Nov 01:27
@github-actions github-actions
5.2.3
b46a7b5
Compare
Choose a tag to compare
5.2.3

Description

Replace buggy custom gcov script with gcovr

Abstract

Current gcov coverage uploaded to sonar cloud excludes coverage where it was covered, this PR fixes it.

Background

Details

Some of the gcov settings, etc. were not covered due to improper settings.
Fixed to collect gcov records using gcovr.

References

https://star4.slack.com/archives/C04TZBEABDM/p1730968513939279?thread_ts=1727660826.478009&cid=C04TZBEABDM

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

Assets 2
Loading

5.2.2

15 Nov 05:24
@github-actions github-actions
5.2.2
2ddff4d
Compare
Choose a tag to compare
5.2.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

declaration shadows a local variable

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

Assets 2
Loading

5.2.1

14 Nov 08:53
@github-actions github-actions
5.2.1
017b10e
Compare
Choose a tag to compare
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

Assets 2
Loading

5.2.0

14 Nov 06:59
@github-actions github-actions
5.2.0
f9c5a8e
Compare
Choose a tag to compare
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

Assets 2
Loading

5.1.1

13 Nov 09:18
@github-actions github-actions
5.1.1
df8f7d2
Compare
Choose a tag to compare
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

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

Assets 2
Loading

5.1.0

12 Nov 08:42
@github-actions github-actions
5.1.0
85fec17
Compare
Choose a tag to compare
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/universe
    • autoware_auto_perception_msgs/TrafficSignalArray for traffic lights
  • awf/universe/20230906
    • autoware_perception_msgs/TrafficSignalArray for traffic lights

In this PR, I added awf/universe/20240605 as below.

  • awf/universe/20240605
    • autoware_perception_msgs/TrafficLightGroupArray for 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

Assets 2
Loading

5.0.2

11 Nov 07:51
@github-actions github-actions
5.0.2
0a46d1d
Compare
Choose a tag to compare
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

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

Assets 2
Loading