1.15.7

Description

Abstract

Replace non-efficient implementation in EntityBase::setOtherStatus function

Background

scenario_simulator_v2 was too slow, so we have to speed up for supporting a lot of entities.

In previous version, EntityBase::setOtherStatus function was this.

void EntityBase::setOtherStatus(
  const std::unordered_map<std::string, CanonicalizedEntityStatus> & status)
{
  other_status_.clear(); // clear previous status
  for (const auto & [other_name, other_status] : status) {
    if (other_name != name) {
      other_status_.emplace(other_name, other_status); // emplace status if the status comes from another entity.
    }
  }
}

It was not efficient.

Details

So, I replace it as

void EntityBase::setOtherStatus(
  const std::unordered_map<std::string, CanonicalizedEntityStatus> & status) {
  other_status_ = status;
  other_status_.erase(name);
}

This PR is depends on #1237 and #1238

References

#1237
#1238

performance

before

This process took up 2.2% of the total processing time.

after

This process now takes 1.5% of the total processing time.

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

1.15.6

Description

Abstract

When I checking performance of scenario_simulator_v2, I found that it takes a lot of time for broadcasting frames for each entity.

Background

When spawning a lot of entity (About 10), it takes a lot of times to broadcasting frames.
It causes frame drop, so we have to fix it.

Details

Broadcast entities frame, which is based on the average position of all Entities.
This PR is depends on #1237

References

#1237
tier4/sim_evaluation_tools#274

Destructive Changes

In previous version, all of the entity has tf frame and it was used in visualization, but it is removed in this pull request.

Known Limitations

N/A

Related Issues

1.15.5

Bumps jinja2 from 3.1.3 to 3.1.4.

Release notes

Sourced from jinja2's releases.

3.1.4

This is the Jinja 3.1.4 security release, which fixes security issues and bugs but does not otherwise change behavior and should not result in breaking changes.

PyPI: https://pypi.org/project/Jinja2/3.1.4/ Changes: https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-4

• The xmlattr filter does not allow keys with / solidus, > greater-than sign, or = equals sign, in addition to disallowing spaces. Regardless of any validation done by Jinja, user input should never be used as keys to this filter, or must be separately validated first. GHSA-h75v-3vvj-5mfj

Changelog

Sourced from jinja2's changelog.

Version 3.1.4

Released 2024-05-05

• The xmlattr filter does not allow keys with / solidus, > greater-than sign, or = equals sign, in addition to disallowing spaces. Regardless of any validation done by Jinja, user input should never be used as keys to this filter, or must be separately validated first. :ghsa:h75v-3vvj-5mfj

Commits

• dd4a8b5 release version 3.1.4
• 0668239 Merge pull request from GHSA-h75v-3vvj-5mfj
• d655030 disallow invalid characters in keys to xmlattr filter
• a7863ba add ghsa links
• b5c98e7 start version 3.1.4
• da3a9f0 update project files (#1968)
• 0ee5eb4 satisfy formatter, linter, and strict mypy
• 20477c6 update project files (#5457)
• e491223 update pyyaml dev dependency
• 36f9885 fix pr link
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

Related Issues

1.15.4

Description

Abstract

Add launch prefix and option for perf performance measurement tool.

Background

In order to speed up scenario_simulator_v2, performance measurement is very important.
But, it was not easily used with scenario_simulator_v2.

Details

Add launch prefix for perf to the openscenario_interpretor_node.

References

https://perf.wiki.kernel.org/index.php/Main_Page

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

1.15.3

Description

Abstract

Added standstill duration update for MiscObjects. It is necessary to support scenarios that are testing the standstill duration for those objects.

Background

Standstill duration of the misc object was not updated, so it is always 0.
It was a bug.

Details

Update standstill duration of the misc object and fix the bug.

References

tier4/sim_evaluation_tools#214

OpenSCENARIO documentation link.

Destructive Changes

Standstill duration of the MiscObject was always 0.
But after this pull request merged, it become greater than or equal to 0.

Known Limitations

N/A

Related Issues

1.15.2

Description

Abstract

update default value of the architecture_type

Background

architecture_type of the latest version of Autoware should be awf/universe/20230906, but it is still awf/universe

Details

Change default value of the architecture_type to awf/universe/20230906

References

tier4/sim_evaluation_tools#271

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

1.15.1

Description

Abstract

Partial fixes for #1193

Background

OccupancyGridSensor in simple_sensor_simulator takes detected objects from LidarSensor, but never uses it when filter_by_range is true.
This causes occluded objects (objects that were not detected) appeared in OccupancyGrid (explained in #1193).

Details

Filter objects using detected objects in getDetectedObjects method.

Before

After

As you see pictures, occluded object (tom, orange) emitted before this PR.

Reference

tier4/sim_evaluation_tools#270

Destructive Changes

OccupancyGridSensor behavior was changed.
It emits only LiDAR detected (non occluded) objects instead of all objects in sensor range.

Known Limitations

As LiDAR origin passed to Raycaster is too low (Ego bottom), detected objects from LidarSensor contain some objects that should be occluded.
This can be observed in DetectionSensor output in #1193

Related Issues

1.14.1

Bumps idna from 3.4 to 3.7.

Release notes

Sourced from idna's releases.

v3.7

What's Changed

• Fix issue where specially crafted inputs to encode() could take exceptionally long amount of time to process. [CVE-2024-3651]

Thanks to Guido Vranken for reporting the issue.

Full Changelog: kjd/idna@v3.6...v3.7

Changelog

Sourced from idna's changelog.

3.7 (2024-04-11) ++++++++++++++++

• Fix issue where specially crafted inputs to encode() could take exceptionally long amount of time to process. [CVE-2024-3651]

Thanks to Guido Vranken for reporting the issue.

3.6 (2023-11-25) ++++++++++++++++

• Fix regression to include tests in source distribution.

3.5 (2023-11-24) ++++++++++++++++

• Update to Unicode 15.1.0
• String codec name is now "idna2008" as overriding the system codec "idna" was not working.
• Fix typing error for codec encoding
• "setup.cfg" has been added for this release due to some downstream lack of adherence to PEP 517. Should be removed in a future release so please prepare accordingly.
• Removed reliance on a symlink for the "idna-data" tool to comport with PEP 517 and the Python Packaging User Guide for sdist archives.
• Added security reporting protocol for project

Thanks Jon Ribbens, Diogo Teles Sant'Anna, Wu Tingfeng for contributions to this release.

Commits

• 1d365e1 Release v3.7
• c1b3154 Merge pull request #172 from kjd/optimize-contextj
• 0394ec7 Merge branch 'master' into optimize-contextj
• cd58a23 Merge pull request #152 from elliotwutingfeng/dev
• 5beb28b More efficient resolution of joiner contexts
• 1b12148 Update ossf/scorecard-action to v2.3.1
• d516b87 Update Github actions/checkout to v4
• c095c75 Merge branch 'master' into dev
• 60a0a4c Fix typo in GitHub Actions workflow key
• 5918a0e Merge branch 'master' into dev
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

Related Issues

1.14.0

Description

Abstract

Start supporting API::requestFollowTrajectory function in do nothing plugin.

Background

The behavior of the API::requestFollowTrajectory function when using the behavior tree plugin is useful in that it can take into account various constraints, but it is difficult to use in rosbag_to_scenario where complete observation information is not available due to the high failure rate.

Details

We implemented FollowTrajectoryAction, whose function is limited to do_nothing_plugin, which ignores the laws of physics.
PolylineTrajectory specifies the pose and timestamp, and computes the pose at the timestamp at which the simulation is performed by performing pose interpolation with reference to the current time.

Position interpolation is linear interpolation, and orientation completion is internalized using spherical linear completion.

References

OpenSCENARIO document.
Regression test result

Destructive Changes

N/A

Known Limitations

• dynamic_constraints_ignorable = true (in OpenSCENARIO, followingMode = follow) does not supported.
• closed trajectory is not supported.
• initial_distance_offset should be 0.

Related Issues

1.13.0

Description

Abstract

In this pull-request, I implemented a lane change enabled routing algorithm, as shortest of OpenSCENARIO RoutingAlgorithm for DistanceCondition / RelativeDistanceCondition.

Background

To resolve the difference of two lane positions, the shortestPath of lanelt2 with a no lane change option is used as a routing algorithm in current implementation of DistanceCondition and RelativeDistanceCondition.

Although this implementation has been used in many scenarios, it returns distances that are not intuitive or cannot be evaluated in some use cases.
One of the typical use cases is shown in the figure below.
When measuring the distance from a red car to a blue car, intuitively we assume that the distance will be measured along the red arrow, but in reality the distance will be measured along the blue arrow.

Details

Behavior in the specific situation

RoutingAlgorithm: undefined

undefined does not change lanes, so the distances will have to go around B and C to get there.
Since undefined does not change lanes, the route for distance measurement goes around 100,101,102 and 11,12 to reach the blue car.
In the case of this figure, distances would be evaluated as follows

• longitudinal distance: 73
• lateral distance: -2

Note: The value of lateral distance has a negative value, which is known to be a violation of the OpenSCENARIO standard. (shortest's implementation fixes it.)

RoutingAlgorithm: shortest

By changing lanes, shortest takes the most intuitive route in this figure, connecting 2 and 12 directly.

In the case of this figure, distances would be evaluated as follows

• longitudinal distance: 4
• lateral distance: 6

Tests

In ByEntityCondition.EntityCondition.DistanceCondition.Shortest.yaml, I set up 24(3 * 2 * 2 * 2) tests.

• 3 situations
  • NPC1: routable without any lane changes by looping, but there is shorter route with a lane change
  • NPC2: in adjacent lane (for edge case)
  • NPC3: in in adjacent lane and behind ego (for edge case)
• 2 Conditions
  • DistanceCondition
  • RelativeDistanceCondition
• 2 freespace options for distance evaluation
  • true
  • false
• 2 axes in lane coodinate system
  • lateral
  • longitudinal

References

OpenSCENARIO XML 1.3 RoutingAlgorithm

regression test result: OK

Destructive Changes

If nothing is specified for RoutingAlgorithm in the scenario, undefined will be used, as defined in OpenSCENAIRO standard.

Algorithm for path selection/calculation between two positions across roads. Only relevant, if CoordinateSystem is "road"/"lane". Default value if omitted: "undefined".
https://publications.pages.asam.net/standards/ASAM_OpenSCENARIO/ASAM_OpenSCENARIO_XML/latest/generated/content/DistanceCondition.html

The legacy implementation is used as this "undefined" behavior, so there are no breaking changes to existing scenarios.

Known Limitations

N/A

Related Issues