16.3.8

Description

Abstract

Fix wrong format in push tag in Docker.yaml.

Background

Docker images for traffic_simulator does not exist on GitHub container registry.

Details

In, #1535.
Push tags in Docker.yaml was wrong.

wrong

      - name: Build and push
        if: github.event_name == 'workflow_dispatch'
        uses: docker/bake-action@v6.3.0
        with:
          files: |
            ./docker-bake.hcl
          workdir: .
          set: |
            *.cache-to=type=gha,mode=max
            *.cache-from=type=gha
            *.tags=ghcr.io/tier4/scenario_simulator_v2:traffic_simulator_${{ matrix.rosdistro }}-${{ github.event.inputs.version }}
            *.tags=ghcr.io/tier4/scenario_simulator_v2:traffic_simulator-latest
            push: true
          targets: |
            traffic_simulator_${{ matrix.rosdistro }}

right

      - name: Build and push
        if: github.event_name == 'workflow_dispatch'
        uses: docker/bake-action@v6.3.0
        with:
          files: |
            ./docker-bake.hcl
          workdir: .
          set: |
            *.cache-to=type=gha,mode=max
            *.cache-from=type=gha
            *.tags=ghcr.io/tier4/scenario_simulator_v2:traffic_simulator_${{ matrix.rosdistro }}-${{ github.event.inputs.version }}
            *.tags=ghcr.io/tier4/scenario_simulator_v2:traffic_simulator-latest
          push: true
          targets: |
            traffic_simulator_${{ matrix.rosdistro }}

References

#1535

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

16.3.7

Description

This fix resolves the following issue:

• MiscObject NPC is not spawning in AWSIM ss2

Abstract

Resolves the issue where the MicsObject NPC is not spawning in AWSIM ss2

Background

None

Details

In the latest master ( commit 8f2c212 from May 2025), there is 1 common spawn API for

• vehicle, pedestrian and miscObject (takes 5 arguments) → code link

For that reason when the API is called in applyAddEntityAction() with 4 arguments for MiscObject (code link), the model3d is passed as the 4th behavior argument , and the 5th model3d argument is taken the default one, so it is the empty string "".

Finally, the ss2 sends the request to AWSIM to spawn the entity with model3d which is "".

References

https://tier4.atlassian.net/browse/RJD-1774

Destructive Changes

None

Known Limitations

None

Related Issues

16.3.6

Description

Abstract

This PR will enable ARM64 CI buildtest support.

Background

Linux arm64 hosted runners now available for free in public repositories

Details

Add build test for ARM64 runner.

References

#1426

Destructive Changes

N/A

Known Limitations

• Multiple test scenarios, unit tests fail in ARM CPU environment, so test case build and execution is turned off in ARM64 environment
• Sending coverage to SonarCloud is also not done in ARM64
• Docker building is currently not modified

Related Issues

16.3.5

Description

This PR resolves the following issues:

• Fixes the missing RViz config file.
• Addresses duplicated node errors for the Random Test Runner.
• Resolves the issue with duplicate /simulation/getParameter node.
• Fixes NPC logic not starting when the ego is already engaged.

Abstract

Fixes node duplication issues and adds the missing RViz config file.
Also adds IMU sensor configuration to the Random Test Runner to eliminate related warnings.
Resolves an issue where NPC logic would not start if the ego entity was already engaged.

Details

• Adds the missing RViz config file path in the launch file.
• Adds the IMU sensor to the Random Test Runner to resolve warnings about missing IMU topic link.
• Resolves issues related to duplicated nodes.
  • In the case of Random Test Runner, node names were removed from the launch file to avoid duplication file
  • For the /simulation/getParameter node, previously, a node was created for each parameter type. The new approach limits the number of created nodes and prevents duplicate nodes across different executables link
• Fixes NPC logic not starting link:
  Previously, the logic checked whether the ego entity was engageable. However, after calling engage() in initialize(), Autoware transitions to the DRIVING state, making the ego entity no longer engageable. This prevented the NPC logic from starting. The condition has been updated to check whether the ego is already engaged, allowing the logic to proceed as expected.

References

• JIRA Ticket: RJD-1755
• JIRA Ticket: RJD-1766
• Github Issue #1441

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

16.3.4

Description

Abstract

To avoid link check errors, reduce max-concurrency, and trigger files

Background

Recently, link checks are failed due to rate limit of github

https://github.com/tier4/scenario_simulator_v2/actions/workflows/DocumentationLinkCheck.yaml

References

To test this pull-request, I added a test commit that changes markdown file.
The commit triggers the link check action and has no errors.
https://github.com/tier4/scenario_simulator_v2/actions/runs/14924888377/job/41927399418?pr=1591

Destructive Changes

None

Known Limitations

Due to this change, link check takes long time.

Related Issues

16.3.3

Description

This PR implements optimization of calculating actual distance in ActionNode::getDistanceToTargetEntity only for nearest NPCs.
This PR is blocked by #1567 and base merge will be changed after blocking PR is merged.

Abstract

ActionNode::getDistanceToTargetEntity should calculate boundingBoxLaneLongitudinalDistance only for nearest NPC. This is done based on EuclideanDistancesMap containg euclidean distance between mapPose of NPCs.

Details

1. Euclidean distance between all NPCs is calculated only once for each update in EntityManager.
2. sharred_ptr of this map is passed to behavior_tree and used ActionNode::getDistanceToTargetEntity.
3. Nearest NPCs are NPCs in distance of maximum value from NPC spline length and NPC stop distance.

Destructive Changes

--

Known Limitations

--

References

RJD-1509

Related Issues

16.3.2

Description

In ActionNode used methods distance::boundingBoxLaneLongitudinalDistance and CatmullRomSpline::getCollisionPointIn2D can be optimized.

Abstract

In ActionNode::getDistanceToTargetEntity needs boundingBoxLaneLongitudinalDistance and longitudinalDistance, both are calculated with boundingBoxLaneLongitudinalDistance, but only one is returned.

In ActionNode::getDistanceToTargetEntity CatmullRomSpline::getCollisionPointIn2D check all length of spline for collision points, knowing longitudinalDistance to conflicting entity we can check only small part of it.

Details

In ActionNode::getDistanceToTargetEntity:

• use newly defined traffic_simulator::distance::boundingBoxLaneLongitudinalDistance, which gets longitudinalDistance as parameter
• use changed CatmullRomSpline::getCollisionPointIn2D with defined part of spline to check for collision

Destructive Changes

--

Known Limitations

--

References

RJD-1509

tier4/sim_evaluation_tools#497 (comment)

Related Issues

16.3.1

Description

Abstract

This pull request fixes some bugs in Autoware state control in scenario_simulator_v2.

Background

None.

Details

• FieldOperatorApplication::initialize, plan, and engage now wait if the current Autoware state is earlier than expected. This allows Autoware to transition states appropriately even if it takes a long time to process a service request after accepting it.
• The member function FieldOperatorApplication::waitForAutowareStateToBe now takes not only the target state but also the state at the time of the call. This allows state waiting to be performed for that range of states, and also allows the wait to be properly terminated if the state is ahead of the target state (which occurs when the member function is called and the Autoware state changes at the same time).
• The default retry interval for service requests has been extended from 1 second to 3 seconds. This means that requests are rarely resent endlessly when Autoware takes more than 1 second to respond to a service. However, there are no specifications for how long Autoware requires for a service response, and it is also affected by machine specifications, so it is not possible to set an appropriate value based on technical grounds. Therefore, 3 seconds is also just an arbitrary number that has been experimentally verified to not cause any major problems at present.

References

None.

Destructive Changes

None.

Known Limitations

None.

Related Issues

16.3.0

Description

Abstract

This PR introduces the possibility of using agnocast in scenario_simulator_v2.
At this time, the possibility to use agnocast has been introduced only for topic /perception/obstacle_segmentation/pointcloud.

Regression tests were run - 0 negative scenarios resulted, detailed report here.

Background

There is a need for optional agnocast communication on selected topics. This is because not all autoware support agnocast.

Details

• New package agnocast_wrapper has been developed which provides a wrapper to easily switch communication between “agnocast” and “ros2”.

  • It includes subscribing, publishing and creating messages.
  • The basic code of the wrapper can be found here.
  • This works in a similar way to the integration with Autoware described here.

• To be more precise, to add optional communication for e.g. a publisher, it is enough to change its type and constructor call to agnocast_wrapper.

• I would also add that part of the communication in ss2 is already wrapped up in a different way, so some additional integration will certainly be necessary, but I do not imagine significant difficulties here.

• The agnocast_wrapper has been used for the publication of topic /perception/obstacle_segmentation/pointcloud in module simple_sensor_simulator - it can be seen here.

• The switching is handled in the build time by setting the ENABLE_AGNOCAST_SIMULATOR environment variable - see Build with agnocast section.

• Note: During tests I noticed a issue with the agnocast communication running in the main version, version v2.0.1 works fine - this one is set in the dependencies.

Build with agnocast

Since agnocast is to be optional for ss2, dependence on it must also be optional.
Therefore a dependency cannot be added to the package.xml of the agnocast_wrapper package.
Because of this, during the build process the dependencies are not resolved correctly and the build order may be incorrect.

Therefore, if you want to use Autoware where the agnocast repository is included, you must first build the agnocast package (step 4, 5) and then the whole repository (step 6). If agnocast is not in autoware, but you want to build ss2 with agnocast, you first need to clone the repository (step 3).

Steps

Open the terminal and go to workspace (e.g. a cloned autoware repository).
In this terminal, call the following commands:

1. export ENABLE_AGNOCAST_SIMULATOR=1
   • (this command ensures that agnocast is used on the ss2 side)
2. export ENABLE_AGNOCAST=1
   • (this command ensures that agnocast is used on the Autoware side)
3. git clone --branch 2.0.1 git@github.com:tier4/agnocast.git ./src/agnocast
   • (this command clones the agnocast repository, skip if workspace already contains agnocast)
4. colcon build --packages-up-to agnocastlib --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release
   • (this command builds agnocast repository first)
5. source install/setup.bash
   • (this command source agnocast built repository to be seen for the next build step
6. colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-w"
   • (this command builds the entire repository)

Example screen

Example log

Logfile

Troubleshooting

1. If agnocast is not in workspace or if it is but was not built first, you will encounter the following problem. To avoid this remember to do steps 3, 4, 5.
   

2. If you want to use agnocast but do not set the environment variable ENABLE_AGNOCAST_SIMULATOR to 1, you will encounter the following problem. Remember to do steps 1,2.
   

Build without agnocast

To build a workspace without using agnocast simply skip steps 1-6 mentioned above.
In other words, build everything the usual way without including agnocast in the build process.

Note: If you have previously defined ENABLE_AGNOCAST_SIMULATOR and ENABLE_AGNOCAST, set them to 0 before the build process:

1. export ENABLE_AGNOCAST_SIMULATOR=0
   • (this command ensures that agnocast is not used on the ss2 side)
2. export ENABLE_AGNOCAST=0
   • (this command ensures that agnocast is not used on the Autoware side)

Example log

Logfile

References

RJD-1681

Destructive Changes

None

Known Limitations

At this time, the possibility to use agnocast has been introduced only for topic /perception/obstacle_segmentation/pointcloud.

This PR introduces an implicit dependency on agnocastlib. The package.xml for the agnocast_wrapper package does not add agnocastlib in order for ss2 to be built without it (when agnocast is not to be used).
In other words, if we want agnocastlib to be added to package.xml rosdep would always require the agnocastlib package to exist in the repository.

Related Issues

16.2.0

Abstract

This pull request enhances pedestrian obstacle detection by adding a maximum detection range, so that only pedestrians within a specified distance from the ego vehicle are considered when evaluating lane obstacles.

Background

The previous implementation only checked whether a pedestrian occupied a lane and was ahead, causing the vehicle to react even to distant pedestrians. This could lead to unnecessary stops or unnatural behavior. Introducing a distance threshold ensures more realistic and efficient obstacle detection.

Details

• Extended the signature of the hasObstacleInPedestrianLanes lambda to accept a new parameter, max_detect_length (maximum detection distance).

• Calculated the Euclidean distance between the ego vehicle and each pedestrian; only if norm < max_detect_length are the pedestrian’s lane IDs collected.

• Updated the call within FollowLaneAction::detectObstacleInLane from:

  hasObstacleInPedestrianLanes(pedestrian_lanes)

  to:

  hasObstacleInPedestrianLanes(pedestrian_lanes, 10)

  where 10.0 m is the default detection range.

Before

before.mov

After

after.mov

References

• tier4/sim_evaluation_tools#507

Destructive Changes

N/A

Known Limitations

N/A

Related Issues