2.0.1

Description

Abstract

Modified openscenario_validator so that it can be used as a header-only library.

Background

N/A

Details

N/A

References

regression test: tier4/sim_evaluation_tools#282

Destructive Changes

OpenSCENARIOValidator class users will be affected by this change.
(But, the class is not included in the interfaces that should be maintained, the version increment is at the patch level.)

Known Limitations

N/A

Related Issues

2.0.0

Description

Jira ticket: link

Regressions: link

Abstract

This PR is intended to separate methods related to distance calculation from API/EntityManager/EntityBase modules.

Methods that have been completely separated in this PR:

• getLateralDistance()
• getLongitudinalDistance()
• getBoundingBoxDistance()
• getBoundingBoxLaneLateralDistance()
• getBoundingBoxLaneLongitudinalDistance()
• getDistanceToLaneBound()
• getDistanceToLeftLaneBound()
• getDistanceToRightLaneBound()
• getDistanceToStopLine()
• getDistanceToCrosswalk()

The result is a collection of functions in namespace traffic_simulator::distance.

Methods that have been separated because they use traffic_simulator::distance (they are called by DistanceCondition etc.) and their separation was already advantageous for "approach validity". Separation of more methods related to "Pose" will be introduced in the next PR (RJD-1053):

• getRelativePose()
• getBoundingBoxRelativePose()
• makeNativeRelativeWorldPosition()
• makeNativeBoundingBoxRelativeWorldPosition()
• makeNativeRelativeLanePosition()
• makeNativeBoundingBoxRelativeLanePosition()

The result is a collection of functions in namespace traffic_simulator::pose.

Note: I realize that I've hurried to separate this pose-related functions in this PR, if you feel that it makes the PR too big - I will try to split it. However, I took into account here that if I don't do it now then in the next PR I will have to modify the same code basically. Moreover, considering how many files will be changed in PR (RJD-1053) (separating toLaneletPose(), canonicalize(), toMapPose() etc. - they are very commonly used), making this change now can be useful for reducing the size and complexity of the next PR RJD-1053.

Background

Now the algorithms used for distance calculations are implemented directly in EntityManager and EntityBase. This makes it necessary to call forwarded methods to perform any distance calculations in SimulatorCore. The new approach assumes that SimulatorCore will have access to each Entity (EntityBase) and lanelet2 (HdmapUtils) and will perform calculations using an independent library. This ensures that the algorithms for the calculations are separated and their testing will be much more efficient. Moreover, it definitely reduces the complexity of EntityManager and EntityBase.

The separation of methods for distance calculations assumes that the arguments passed to them are msg::Pose, CanonicalizedLaneletPose, BoundingBox.

When writing this sentence, I've realized that the code is still not perfect - so I added an improvement - here is the commit that contains it, which was not tested in the current regression tests. I will run the tests again after receiving reviews and making requested changes.

Details

Necessary changes to simplify the API

To allow access to Entity, forwarded method was added:

• getEntity()

Note: This method returns nullptr, due to the fact that the interpretation of the scenario operates in such a way that checking a condition, e.g. DistanceCondition, is called also for Entities that have not yet been spawned. For example, if for DistanceCondition any getEntity() returns nullptr, the condition returns a distance equal to NaN. For this reason, throwing an exception through getEntity() is not recommended.

Distance to bound

The following functions have been separated from EntityBase, and they are no longer forwarded API->EntityManager->EntityBase:

• getDistanceToLaneBound()
• getDistanceToLeftLaneBound()
• getDistanceToRightLaneBound()

In addition, the core of the get2DPolygon() function has been moved to bounding_box.

Lateral and longitudinal distance - also using BoundingBox

The following functions have been separated from EntityManager, and they are no longer forwarded API->EntityManager:

• getLateralDistance()
• getLongitudinalDistance()
• getBoundingBoxDistance()
• getBoundingBoxLaneLateralDistance()
• getBoundingBoxLaneLongitudinalDistance()

It caused the need to develop additional helper lambda functions.

Note: It is worth to consider creating a collection of "helper" functions for cpp_mock_scenarios or simply moving it to current traffic_simulator::helper.

Distance to objects

The following functions have been separated from EntityManager:

• getDistanceToStopLine()
• getDistanceToCrosswalk()

Note: They are not actually used anywhere, but they were moved because they calculate distance.

SimulatorCore adaptation (sometimes here traffic_simulator::distance is used indirectly)

• checkRoutingAlgorithm() has been added to avoid repeats
• The following functions have been simplified and now fully uses traffic_simulator::pose (i.e. indirectly traffic_simulator::distance) - now the only dependencies with the API is getEntity() and getHdMapUtils().
  • makeNativeRelativeWorldPosition()
  • makeNativeBoundingBoxRelativeWorldPosition()
  • makeNativeRelativeLanePosition()
  • makeNativeBoundingBoxRelativeLanePosition()
  • evaluateRelativeHeading()
  • evaluateBoundingBoxEuclideanDistance()
• makeNativeLanePosition() has been removed, and its core has been moved directly to operator() for LanePosition
• makeNativeWorldPosition() has been removed, and its core has been moved directly to operator() for WorldPosition.
• canonicalize and convert have been adapted for traffic_simulator::pose - I admit that this could have been done in RJD-1053 PR, sorry about that.
• The following functions have been simplified and now fully uses directly traffic_simulator::distance - now the only dependencies with the API is getEntity() and getHdMapUtils().

Note: I try to avoid multiple nested "if" statements, but in the adaptation of SimulatorCore I used many of them. Unfortunately, I didn't figure out anything more readable and brief... being honest I don't like this solution. If you have another concept please let me know.

https://github.com/tier4/scenario_simulator_v2/blob/318f0478f4b11d156105148d3545b6d5dfef5e56/openscenario/openscenario_interpreter/include/openscenario_interpreter/simulator_core.hpp#L204-L220

API adaptation

• API::getTimeHeadway() has been modified - now getRelativePose() can return std::nullopt - previously an exception was thrown (what wasn't handled)

Destructive Changes

Some of the API:: methods have been removed, free functions should be used instead.

Previously, these were forwarded functions to the entity manager, which used the object of the specific entity. Now it is necessary to get the ...

1.18.0

Description

Abstract

This PR adds a TrafficSource class for the OpenSCENARIO TrafficSourceAction and an API function defineTrafficSource that creates a TrafficSource.

Background

Scenario simulator does not fully support OpenSCENARIO specification, meaning not all features of OpenSCENARIO are implemented.
In order to increase the support for OpenSCENARIO new features have to be implemented. One such feature is the TrafficSourceAction.
Changes made in this PR enable adding a TrafficSource in the API of traffic simulator by calling the function API::defineTrafficSource.
For a full support of TrafficSourceAction, changes in the openscenario interpreter are also needed.

Details

These changes enable adding the TrafficSource from API of traffic simulator.
The TrafficSource can operate in several configurations.
These configurations specify how the entities are spawned. User defining a TrafficSource can choose to

• Spawn only Pedenstrians
• Spawn only Vehicles
• Spawn both Pedestrians and Vehicles
  • In all these modes, Pedestrians are spawned on road and crosswalk and Vehicles are spawned only on road lanelets.
• Require to spawn entities on lane (note: currently traffic simulator allows spawning vehicles only on lane, so turning this off is advisable only for TrafficSource spawning only Pedestrians) - if this is enabled, then the orientation will be aligned to the lane on which the entity is spawned.
• Require to fit entity footprint inside the lane polygon (Note: enabling this adds computational cost, mainly when defining the TrafficSource. This should not make much of a difference, except for very large radiuses.)
• Enable random orientation to be used for spawning - otherwise the TrafficSource.position orientation is used, and this orientation is used in all subsequent stages performed, including lane matching, which is orientation dependent.
  Please note, that turning this off will result in using the same orientation for all entities spawned. The orientation of requested spawn pose is - in the current implementation of traffic simulator - used for lanelet matching using a horizontal bar method (for more details, see here). This means that preserving the TrafficSource.position orientation will bias the spawning of entities to the lanes that have similar orientation as the TrafficSource.position. In some situations this may be a desired behavior, but for most use cases, when a random and uniform distribution is required this option should be enabled.

Spawned entities are randomly chosen from a list of provided "blueprints" with all required parameters and corresponding random distribution weights. User can define for example a TrafficSource that will spawn 2 Vehicles:

• a bicycle with a random distribution weight of 1 and
• a car with a random distribution weight of 3.

Such a TrafficSource will - on average - spawn 1 entity according to the bicycle "blueprint" every 3 entities spawned according to the car "blueprint".

Entities are spawned only when their whole footprint fits inside the TrafficSource circle.

The pose selection can be described with a diagram below:

All entities spawned by one TrafficSource have the same initial speed set.

The TrafficSource can have a spawn rate greater than the rate at which execute function is called.

TrafficSource only calls one of the spawn functions that it is provided, so if API::spawn allows spawning one entity in place where some other entity already exists (which is true at the time of this writing) then if such random position is selected, the entity will be spawned there.

As part of implementing TrafficSource, several cpp mock scenarios have been created.

References

INTERNAL LINK.

Destructive Changes

There are no destructive changes. The PR adds new feature. The only code that needed to be changed was that TrafficController::execute passes time information to traffic modules, which was necessary to enable spawning at a given rate.

Known Limitations

If TrafficSource is required to fit an entity bounding box into a lane polygon, then additional calculations of the lanelet polygon need to be performed. For a TrafficSource that has a lot of lanelets inside its spawning area, this can take some time. For this purpose, an example define_traffic_source_large scenario has been created, where the radius is set to 200m, and it takes approx 1.5s to initially calculate the lanelet polygons.
Please note that this calculation is performed only once for each TrafficSource and after that each spawn position selection is fast.

Related Issues

1.17.2

Bumps requests from 2.31.0 to 2.32.0.

Release notes

Sourced from requests's releases.

v2.32.0

2.32.0 (2024-05-20)

🐍 PYCON US 2024 EDITION 🐍

Security

• Fixed an issue where setting verify=False on the first request from a Session will cause subsequent requests to the same origin to also ignore cert verification, regardless of the value of verify. (GHSA-9wx4-h78v-vm56)

Improvements

• verify=True now reuses a global SSLContext which should improve request time variance between first and subsequent requests. It should also minimize certificate load time on Windows systems when using a Python version built with OpenSSL 3.x. (#6667)
• Requests now supports optional use of character detection (chardet or charset_normalizer) when repackaged or vendored. This enables pip and other projects to minimize their vendoring surface area. The Response.text() and apparent_encoding APIs will default to utf-8 if neither library is present. (#6702)

Bugfixes

• Fixed bug in length detection where emoji length was incorrectly calculated in the request content-length. (#6589)
• Fixed deserialization bug in JSONDecodeError. (#6629)
• Fixed bug where an extra leading / (path separator) could lead urllib3 to unnecessarily reparse the request URI. (#6644)

Deprecations

• Requests has officially added support for CPython 3.12 (#6503)
• Requests has officially added support for PyPy 3.9 and 3.10 (#6641)
• Requests has officially dropped support for CPython 3.7 (#6642)
• Requests has officially dropped support for PyPy 3.7 and 3.8 (#6641)

Documentation

• Various typo fixes and doc improvements.

Packaging

• Requests has started adopting some modern packaging practices. The source files for the projects (formerly requests) is now located in src/requests in the Requests sdist. (#6506)
• Starting in Requests 2.33.0, Requests will migrate to a PEP 517 build system using hatchling. This should not impact the average user, but extremely old versions of packaging utilities may have issues with the new packaging format.

New Contributors

• @​matthewarmand made their first contribution in psf/requests#6258
• @​cpzt made their first contribution in psf/requests#6456

... (truncated)

Changelog

Sourced from requests's changelog.

2.32.0 (2024-05-20)

Security

• Fixed an issue where setting verify=False on the first request from a Session will cause subsequent requests to the same origin to also ignore cert verification, regardless of the value of verify. (GHSA-9wx4-h78v-vm56)

Improvements

• verify=True now reuses a global SSLContext which should improve request time variance between first and subsequent requests. It should also minimize certificate load time on Windows systems when using a Python version built with OpenSSL 3.x. (#6667)
• Requests now supports optional use of character detection (chardet or charset_normalizer) when repackaged or vendored. This enables pip and other projects to minimize their vendoring surface area. The Response.text() and apparent_encoding APIs will default to utf-8 if neither library is present. (#6702)

Bugfixes

• Fixed bug in length detection where emoji length was incorrectly calculated in the request content-length. (#6589)
• Fixed deserialization bug in JSONDecodeError. (#6629)
• Fixed bug where an extra leading / (path separator) could lead urllib3 to unnecessarily reparse the request URI. (#6644)

Deprecations

• Requests has officially added support for CPython 3.12 (#6503)
• Requests has officially added support for PyPy 3.9 and 3.10 (#6641)
• Requests has officially dropped support for CPython 3.7 (#6642)
• Requests has officially dropped support for PyPy 3.7 and 3.8 (#6641)

Documentation

• Various typo fixes and doc improvements.

Packaging

• Requests has started adopting some modern packaging practices. The source files for the projects (formerly requests) is now located in src/requests in the Requests sdist. (#6506)
• Starting in Requests 2.33.0, Requests will migrate to a PEP 517 build system using hatchling. This should not impact the average user, but extremely old versions of packaging utilities may have issues with the new packaging format.

Commits

• d6ebc4a v2.32.0
• 9a40d12 Avoid reloading root certificates to improve concurrent performance (#6667)
• 0c030f7 Merge pull request #6702 from nateprewitt/no_char_detection
• 555b870 Allow character detection dependencies to be optional in post-packaging steps
• d6dded3 Merge pull request #6700 from franekmagiera/update-redirect-to-invalid-uri-test
• bf24b7d Use an invalid URI that will not cause httpbin to throw 500
• 2d5f547 Pin 3.8 and 3.9 runners back to macos-13 (#6688)
• f1bb07d Merge pull request #6687 from psf/dependabot/github_actions/github/codeql-act...
• 60047ad Bump github/codeql-action from 3.24.0 to 3.25.0
• 31ebb81 Merge pull request #6682 from frenzymadness/pytest8
• Additional commits viewable in compare view

[](https://docs.github.co...

1.17.1

Description

Abstract

In #1238, the ID of the visualization frame was changed to speed up the processing. At that time, there was an error in the implementation of coordinate conversion, and markers were not drawn correctly on the rviz.

Background

Execute the following command on the current master branch.

ros2 launch cpp_mock_scenarios mock_test.launch.py launch_rviz:=true timeout:=60.0 scenario:=acquire_position_in_world_frame

The following is displayed in rviz.

Screencast.from.05-21-2024.12.10.04.PM.webm

Details

The coordinate system of the various markers was modified to produce the following output.

Screencast.from.05-20-2024.04.47.35.PM.webm

References

#1238

Destructive Changes

Fix bug of geometry_msgs::msg::Point operator*(const geometry_msgs::msg::Point & point, const double value) function.

Known Limitations

#1256 This problem still remains, but if I fix this problem in this pull request, the diff will be to large so even if this PR is merged, the problem of double implementation remains.

Related Issues

1.17.0

Description

Abstract

Add openscenario_validator package to validate xosc scenarios with xsd schema.
This package is implemented in C++ with Xerces library.

Background

Sometimes, you may want to perform XSD validation without adding additional dependencies such as Python.
This package is an alternative non-Python implementation of the validation functionality of openscenario_utility.

Details

use openscenario_validator as a C++ library

You can use OpenSCENARIOValidator class in your C++ code by...

• including openscenario_validator/validator.hpp
• linking to openscenario_validator static library

use openscenario_validator as a command

ros2 run openscenario_validator validator <path/to/scenario.xosc>

The command returns 0 if the validation is succeeded.
If there are some errors, the command returns 1 with output like below

/home/autoware/example.xosc:11:88: error: attribute 'valuew' is not declared for element 'ParameterAssignment'
[ros2run]: Process exited with failure 1

References

Resgression Test: OK

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

1.16.4

Description

Abstract

Remove unused value entity_type_dict in behavior plugin.

Background

In scenario_simulator_v2, unused value entity_type_dict was passed into behavior plugin.
But it was not used, and will not be used.
So, I decided to remove this value.

Details

In the process of executing the processing acceleration task, we found that there is a variable entity_type_list that is not completely necessary.
We will remove it to speed up processing and simplify the code.

References

N/A

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

1.16.3

Description

Abstract

CONTRIBUTING.md was modified accordingly as the contributor's name is no longer recorded in the release notes.

Background

Since version 1.0.0, release notes have been generated automatically and contributor names are no longer recorded.

Details

The description was corrected to conform to the facts.
If the contributor's name is recorded in the future, it will be necessary to revise the description again.

References

#1246

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

1.16.2

Description

Abstract

Fix url of release note.

Background

URL of the release note was changed in #1244 , so we have to fix url in documentation.

Details

Fix url of release note from https://tier4.github.io/scenario_simulator_v2-docs/ReleaseNotes to https://tier4.github.io/scenario_simulator_v2-docs/release/ReleaseNotes

References

#1244

Destructive Changes

N/A

Known Limitations

N/A

Related Issues

1.16.1

Abstract

Adding the awesome-pages plugin to the documentation build enhances the development experience.

Background

Writing the entire configuration of pages in mkdocs.yaml requires writing cumbersome paths when adding files, and it becomes unreadable when consolidated into one file.

Details

Added the awesome-pages plugin and added a .pages file in the doc subdirectory. This allows specifying a distributed document structure. Added a dependency to the pyproject to use the awesome-pages plugin.

References

This plugin is used in the Autoware documentation, and I referenced its usage.

https://github.com/autowarefoundation/autoware-documentation

Destructive Changes

N/A

Known Limitations

N/A

Related Issues