Handling invalid / out of ODD areas

[ahmeddesokyebrahim]

Abstract

Motivation

The motivation behind this idea came from a specific situation in Bus ODD project in Gebze map. The idea came out of part of Gebza campus is under-pass a bridge of railway. The development team would like the bus will not drive autonomously in this under-pass area and the human driver would fully take over the driving task responsibility and may engage autonomy mode again after passing it. The bus will not drive in this area being marked/annotated as invalid or out of ODD that the bus must not operate autonomously herein.

The following screenshots shows the problem of the mentioned situation in Gebze map :

Generalization

This situation can be expanded to lots of examples based on business needs, different requirements, technical limitations, ... etc that may mark some areas as out of ODD that vehicle must not drive in autonomous mode within these areas.

Proposed Solution

HD Map side

• We would like to propose adding a new type for lanelets that allows us to mark the start and end of these areas as invalid or out of ODD with virtual stop lines.
  • It is a stop line because we would like the vehicle to stop before entering this area
  • And it is virtual because it is not a line in reality, but it only exists in the map.

Planning side

• We would like to propose adding a new module in behavior_velocity_planner that handles the situations for invalid / out of ODD and provides a path to let the vehicle stop before this virtual stop line (with margin). In the following, we would like to present some of the high line borders for this idea realization :

  • During our investigation for this idea, we noticed in Autoware architecture that there is a module inside behavior_velocity_planner named virtual_stop_line :
    
  • This module does not exist in current Autoware codebase and not implemented.
  • Our idea that virtual_stop_line shall be realized for the purpose of handling the situations for invalid / out of ODD.

Inputs

• The virtual_stop_line module shall consume the lanelet input (similar to stop_line for example)
• However, it shall handle the newly annotated type for virtual stop line from the HD map

Output

• The virtual_stop_line module shall provide behavior_planning/path with zero velocity at this virtual stop line (with margin)
• The virtual_stop_line shall provide needed signal for the human driver to take over the driving task.

Advanced

• The vehicle shall get re-engaged in autonomous mode after totally going out of this invalid / out of ODD area. In case the human driver re-engaged the autonomous mode within this area, the vehicle shall be able to reject this request until being in a valid ODD.

Next Steps

• I would like to present this idea in our next ASWG meeting. Till this time I would appreciate any inputs around that topic.
• After we agree on these border lines, I can work on further implementation diagrams / details for this idea.

Conclusion

• I would like to present a solution of handling invalid / out of ODD scenarios by adding a new lanelet type for virtual stop line (to be used by HD map annotation) and realizing virtual_stop_line module in behavior_velocity_planner

[xmfcx]

Hi @ahmeddesokyebrahim ,

Thank you for your proposal on how to handle disabled areas for a Lanelet2 map for the planning stack. I appreciate your creativity and effort in finding a solution for this challenge.

Your idea of generating artificial stop lines at the boundaries of the ODD-excluded areas is interesting and could potentially prevent vehicles from entering those areas. However, If the vehicle is already inside a disabled area, it might not see the virtual stop lines and could move.

In order to prevent this scenario, we could add a new "odd_excluded" tag to the Lanelet2 map and a new scene_module for the behavior_velocity_planner package that would stop the vehicle in the areas marked with this tag and create an RTC(request to cooperate) for the driver to take over.
The new module could be named "odd_excluded" too.

cc. @TakaHoribe @mitsudome-r @mehmetdogru @taikitanaka3

[ahmeddesokyebrahim]

Following up the discussion ...

• I have created an issue to implement this idea
• Till now, there are several PRs in different repos:
  • autoware_universe
  • autoware_launch
  • autoware_adapi_msgs
  • tier4/tier4_autoware_msgs

Next Steps ...

• Implement RTC(request to cooperate) for the driver to take over.
• Annotating the mentioned part of Gebza map and mark it as invalid lanelet.
• Test the implementation as mentioned in autoware_universe --> Test performed

[TakaHoribe]

Hi @ahmeddesokyebrahim, thank you for your nice work for out of ODD handling. And sorry to comment on the discussion posted a month ago, but please let me post this as a memo.

I agree with the concept of stopping at the virtual stop line when deviating from ODD. And as @xmfcx suggested in the comment above, the tag "virtual_stop_line" alone may not clearly show what it means. It would be better to add more explicit information indicating that it is outside ODD.

Alternatively, it could be a good idea to use something like a geofence, which is frequently used in drone applications. In the HDMap, define a geofence area (or a prohibited area) and when crossing it, stop at the corresponding (or automatically generated) stop line and notify the driver. It may be easier for developers to design by enclosing drivable or non-drivable areas with polygons, rather than tagging all lanelets. Moreover, this approach can be used when autonomous vehicle drives in areas where lanes are not defined in the future. This is an advanced option, so I would appreciate if we can continue discussing this.

[ahmeddesokyebrahim]

The following PRs in these mentioned repos will be intended for review after today's ASWG 21st March meeting :

• autoware_documentation [no code change - just diagram]
• autoware_common - part I [no code change - just documentation]
• autoware_common - part II [no code change - just documentation refactoring]

❗ Merge sequence must follow this order ❗

• tier4/tier4_autoware_msgs - part I
• tier4/tier4_autoware_msgs - part II
• autoware_adapi_msgs
• autoware_launch
• autoware_universe - part I
• autoware_universe - part II [refactoring updates]
• tier4/tier4_ad_api_adaptor

[mitsudome-r]

@ahmeddesokyebrahim Could you also add updates to documentation in autoware_common?
I would like to collect information about Autoware's custom tags in lanelet2_extension package.
https://github.com/autowarefoundation/autoware_common/blob/main/tmp/lanelet2_extension/docs/lanelet2_format_extension.md#optional-taggings

[ahmeddesokyebrahim]

Thanks @mitsudome-r san for your comment.
I have updated autoware_common lanelet2_format_extention documentation with the new optional invalid lanelet tag.

[ahmeddesokyebrahim]

The following videos show the current progress with invalid lanelet :

• Approaching and stopping before invalid lanelet with RTC :
  • https://www.youtube.com/watch?v=Mf5VHlo8UBU
• Started inside invalid lanelet and not moving with RTC
  • https://www.youtube.com/watch?v=lWZgFIjI7Hk

[ahmeddesokyebrahim]

This file includes lanelets with invalid tag added with value 'yes'.
It can be used for testing : https://drive.google.com/file/d/1OwrIjSwxcvhes2ngDKhe2iL5s3TWPzUz/view?usp=sharing

[ahmeddesokyebrahim]

The following video shows a working demo after changing the module name from invalid_lanelet to no_drivable_lane based on the review comment suggested by @yukkysaito san.

https://youtu.be/XKDQn2bcMPQ

As well, the following map file can be used for testing after changing the tag name.

https://drive.google.com/file/d/1oH9Q0Sk9pm-ttF34Vx-bceQCx9Ja-xmS/view?usp=share_link