Skip to content

Releases: tier4/scenario_simulator_v2

5.2.2

15 Nov 05:24
@github-actions github-actions
5.2.2
2ddff4d
Compare
Choose a tag to compare
5.2.2 Latest
Latest

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

5.0.1

11 Nov 06:02
@github-actions github-actions
5.0.1
4c75652
Compare
Choose a tag to compare
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

Assets 2
Loading

5.0.0

08 Nov 01:25
@github-actions github-actions
5.0.0
1e75dfc
Compare
Choose a tag to compare
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:

https://github.com/tier4/scenario_simulator_v2/blob/a06f4b4cae4643f7fa4ac8e7a328139ef4411b7b/simulation/traffic_simulator/include/traffic_simulator/traffic_lights/traffic_lights_base.hpp#L60-L73

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:

https://github.com/tier4/scenario_simulator_v2/blob/a06f4b4cae4643f7fa4ac8e7a328139ef4411b7b/simulation/traffic_simulator/include/traffic_simulator/traffic_lights/traffic_lights_base.hpp#L75-L80

Additionally, a dedicated message publisher has been developed for simple_sensor_simulator:

https://github.com/tier4/scenario_simulator_v2/blob/a06f4b4cae4643f7fa4ac8e7a328139ef4411b7b/simulation/simple_sensor_simulator/include/simple_sensor_simulator/sensor_simulation/traffic_lights/traffic_lights_publisher.hpp#L27-L53

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

Assets 2
Loading

4.5.0

07 Nov 11:38
@github-actions github-actions
4.5.0
93b9241
Compare
Choose a tag to compare
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

Regression Test: OK

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

Assets 2
Loading

4.4.1

07 Nov 06:38
@github-actions github-actions
4.4.1
3f8b4d5
Compare
Choose a tag to compare
4.4.1

Abstract

Please refer to this issue.

Details

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

issue
jira ticket

Related Issues

Assets 2
Loading