OpenSimulationInterface
Logical Traffic Rules and Speed Limit
Introduce a message for traffic rule information for logical lanes. The message is intended to be used by traffic participants to easily get information in traffic rules without having to process traffic signs or other additional information.
While this contains an implementation for a speed limit traffic rule the message is designes so that it can be extended with additional traffic rule types in the future.
Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:
- [x] My suggestion follows the style and contributors guidelines.
- [x] I have taken care about the message documentation and the fields and enums documentation.
- [x] I have done the DCO signoff.
- [ ] My changes generate no errors when passing CI tests.
- [x] I have successfully implemented and tested my fix/feature locally.
- [ ] Appropriate reviewer(s) are assigned.
@lemmer-fzi The enums (other than the fields numbers) should start with 0. You changed the one that was already correct to be wrong now as well ;)
CCB 2024-03-25: Ready for merge from CCB point, will be merged after final review form @tbleher.
The first (maybe minor) comment: I currently see no way to explicitly define "no speedlimit" (for German highways). So I guess "no speedlimit" is modelled as the absence of a TrafficRule. This makes it impossible for a model, however, to know whether the simulation environment has provided traffic rules or not. I suggest explicitly modelling "no speedlimit".
As discussed in today's CCB meeting, this is not considered a specific problem for the traffic rules, as this is a general problem for OSI (detection whether the absence of a field/entry is due to lack of support or no content), hence should be handled at a different level. Especially for the traffic rules, there is only a single instance where no speed limit exists, i.e. on motorways for certain vehicle types, hence there will always be a rule in place somewhere that makes this detection possible.
The second comment might be a bigger issue: how are variable speed limits handled (e.g. from variable message boards, see type vmsBoard in OpenDRIVE 1.8)? Typically the logical lanes would be part of
GroundTruthInitand would be static. But speed limits can be dynamic. So it should (I think) at least be clarified what should happen if a speed limit changes (see OpenSimulationInterface/osi-sensor-model-packaging#108 (comment) for a few problems in that area).
As discussed in today's CCB meeting, this is already an existing problem, as traffic signs are usually also considered static but can change dynamically (see traffic sign variability), and in consequence certain lane properties are likely to change (e.g. lane type from TYPE_STOP to TYPE_NORMAL for signs turning the hard shoulder into an extra normal lane).
So this whole topic will have to be handled as part of the work of determining dynamic/static parts and the handling of updates. We always knew that GroundTruthInit was a partial solution that needs more definition going forward, and dynamic signs (which already are a part of OSI) just make this more pressing.
So I think the interaction between
TrafficRule,vmsBoardandGroundTruthInitshould be clarified before merge (note: as far as I am awarevmsBoardis not part of OSI yet, but I would expect a simulation environment which encounters avmsBoardwith an active speed limit on it to insert a speed limit sign into theSensorView).
As stated above, dynamic traffic signs have been a part of OSI for a long time, how to handle them in the face of GroundTruthInit has been unspecified for as long.
@thempen I have added the discussed text and made some spelling/formatting fixes. Please approve if this matches your expectations.
I am actually a bit indecisive if I really like this feature... we replicate information that is part of the trafficSign assigned_lane_id.
The answer to be comment will be "we already have a lot of redundant information anyway"... I think I want to eventually switch to a work model where suggesting new features is somehow supported by showing a useful implementation along with it.
Reviewed v3.7.0
