bicycle_lane and bus_stop_area specification for format_version 2

[soblin]

bicycle_lane

background

We have been treating the bicycle_lane as "subtype = road" lanelet so far, but it causes unintended drivable area expansion like in this image.

T4 side has been temporarily treating bicycle_lane as "road_shoulder" to avoid the drivable area expansion so far, but we should formally define bicycle_lane since it is a common road primitive.

Proposal

• Put a "subtype = bicycle_lane" lanelet adjacent to a "road" lanelet.
  • bicycle_lane must not be connected to/from different subtype of lanelets like "road" and "road_shoulder"
• Pullover to bicycle_lane is prohibited, so to simplify the structure, bicycle_lane should cover shoulder part of the road

Usage

blind_spot module and map_based_prediction uses bicycle_lane to predict/care cyclists on the side of the road

bus_stop_area

background

T4 side has found severe difficulties in using goal_planner for the pullover of bus toward bus stop at narrow/curved lanes.

To obtain a stable modified goal position and feasible trajectory, we tried following tuning in vain:

• place complicated no_parking_area to limit stop position within a certain area
• tune the centerline of lanes so the final stop pose is easy for the bus to start pullout next time
  • goal_planner optimizes modified goal position so that the goal position at baselink is parallel to the centerline of road shoulder. However if the bus stop is curved/narrow while the bus footprint is large comparatively, this policy results in a pose that is difficult to start pullout with safety margin from the road boundary.

Unlike taxi we do not need much flexibility in goal search procedure for buses. Rather we want buses to pullover inside the specified bus_stop_area.

Proposal

• just like "no_parking_area", put a "bus_stop_area" RegulatoryElement to the related road_shoulder/road lanelet.

Usage

For projects using bus type vehicles, set use_bus_stop_area = true in goal_planner (this is not implemented yet). Then

• allow_modification == true
  • goal_planner generates pullout path toward the goal inside bus_stop_area．It tries to reach the specified goal pose strictly, but if it turned out to be infeasible, generates the best path
• allow_modification == false and subtype == road_shoulder
  • goal_planner generates pullout path toward the goal inside bus_stop_area．It tries to reach the specified goal pose strictly, but if it turned out to be infeasible
    • stuck before the bus_stop_area OR
    • generates the best path
• allow_modification == false, subtype == road
  • fixed_goal_planner generates the default path to the specified goal without pullover.

[mehmetdogru]

Thank you for the proposal @soblin. It looks great and going to be very useful !

As we discussed in WG this is what I think can be considered to add as a feature related bicycle_lane:

• Bicycles merging to the bicycle_lane from pavement (sidewalk)

[maxime-clem]

Discussed during the Planning & Control working group of 08/15.

• bicycle_lane.
  • no issue with adding this new lanelet type. The simple case (example picture) is just an adjacent lanelet with the bicycle_lane subtype.
    • the subtype is already defined by the lanelet library (https://github.com/fzi-forschungszentrum-informatik/Lanelet2/blob/master/lanelet2_core/doc/LaneletAndAreaTagging.md).
  • map_based_prediction should take advantage of this new lanelet type to predict the paths of bicycles (similar to pedestrians with crosswalks).
  • concern about bicycle lanes overlapping road lanelets (example picture).
    • we may want to represent the bicycle lane explicitly to allow proper predictions and to allow planning to maybe keep some distance away from the bicycle lane.
    • may cause issue when lanelets are overlapping.
• bus_stop.
  • it is currently difficult to reach the bus stop because the goal_planner tries to be too accurate, but unlike parking we do not need the bus to be precisely parallel to the road. Similarly, the pull out maneuver is often difficult.
  • proposal: add new optional behaviors to the goal_planner.
    • allow the planner to fallback to an inaccurate goal pose if the accurate goal pose cannot be reached.
  • concerns: the actual functionality of loading/offloading passengers is still missing.
    • this is a valid concern but separate from the issue discussed here.
    • let's have some discussion dedicated to missing functionalities in future meetings. The 1st topic for such discussion could be the use case of loading/offloading of passengers.