Fix/interpreter/user defined value condition

[yamacir-kit]

Description

Abstract

The following two issues have been addressed:

• The simulator became extremely slow when a large number of UserDefinedValueConditions were written in a scenario.
• A related issue, when the simulator was running too slow, some topics published by Autoware were not subscribed to by the simulator and were dropped.

Background

The above issues were observed in a scenario where a large number of UserDefinedValueCondition were used.

Details

The causes of each problem were as follows:

The first problem was caused by the implementation of UserDefinedValueCondition, which had one thread and two ROS nodes per instance. Therefore, we changed the implementation to use one common thread and node for this condition, regardless of the number of UserDefinedValueCondition instances.

The second problem was caused by the simulator's ROS 2 topic subscriber dropping messages that were published before the standby when the standby of the simulator's ROS 2 topic subscriber was later than Autoware's publishers could publish the topic. In this case, a large number of UserDefinedValueCondition overloaded the simulator and delayed the standby of the Subscriber. In addition, the dropped message was one of the most important topics for the simulator to set up Autoware, and it was a message that would only be published once. Fortunately, the topic was provided with a publisher set to transient local in quality of service, so we took care of it by upgrading the subscriber's quality of service to transient local.

References

• https://github.com/tier4/sim_evaluation_tools/issues/326

Destructive Changes

None.

Known Limitations

None.

[github-actions]

Checklist for reviewers ☑️

All references to "You" in the following text refer to the code reviewer.

• Is this pull request written in a way that is easy to read from a third-party perspective?
• Is there sufficient information (background, purpose, specification, algorithm description, list of disruptive changes, and migration guide) in the description of this pull request?
• If this pull request contains a destructive change, does this pull request contain the migration guide?
• Labels of this pull request are valid?
• All unit tests/integration tests are included in this pull request? If you think adding test cases is unnecessary, please describe why and cross out this line.
• The documentation for this pull request is enough? If you think adding documents for this pull request is unnecessary, please describe why and cross out this line.