Autoware Map WG: HD Map functional requirements

Autoware
1

I would like to discuss developing the initial Use Cases for HD Maps scenarios the AW Map WG proposed, and the requirements based cases from last meeting, into a functional description of the use cases - starting to define what functions a map API would need in order to realise the use cases.

As part of defining requirements for an HD map API it is also useful to think about the minimal performance levels we assume from other AD modules. The purpose of an HD maps is support the perception, decision making and motion planning of AVs and although we would like to define a best case HD map, it must be made with respect to a minimal level of performance of an AV and its AD modules.

So I propose for each use case scenario list 1) any assumptions we are making about the AD systems , and 2) the functional requirements.

First off, focusing on Valet Parking, and in extension to the general AD challenge.

The general use cases/requirements of HD map were determined to be (please add any):

Valet Parking: Use cases

  • Driving according to traffic light
  • General traffic signs perception and use for regulation
  • Stop lines and required behavior, links to other elements
  • Detection of pedestrians in crosswalk regions
  • Definition of drivable areas, their regulations, associated regulatory elements
  • Planning (route, lane, local)
  • Parking in a given parking location
  • Localisation

To start:

Requirements for traffic light use case:

  1. Assumes
  • camera based traffic light detection module requiring image region of interest of traffic lights linked to a given lane
  1. Functional Requirements
  • Given poses along current path (range?) return lane/lanes which will be travelled
  • Given a lane return any associated traffic lights
  • Get 3D geometry of traffic lights (point,polygon)
  • Project 3D geometry into 2D camera plane (map function? support query?)
  • For a specific traffic light, return stop line.
  • For a stop line, return related traffic lights if any?

Any thoughts on this (it’s just a starting point for discussion), or on any of the use cases, or on the requirements process in general?

For Reference:

past work on defining use cases:

and their requirements:

3 Likes
2

Thank you for your suggestion. (I’m sorry for my late reaction.)
I believe considering what functions we will need is so important for defining an efficient map model.

So I considered some use cases.
Let’s continue this work and make things more concrete!

Note:
At this stage, I don’t want to make things so strict, so please ignore little things.
Also, the purpose of this post is NOT to list up all functions but to list up major ones and to utilize it for considering the map model for Autoware.Auto.

Use case: Map Matching

Description

The vehicle should recognize where(which lane) it is driving on the route, based on the localized pose.

Required functions

- Lane findNearestLane(pose);
- Lane findNearestLane(route, pose); // When we have the route
- vector<Lane> findNearLanes(pose, range);

Use case: Traffic Light Detection

Description

The vehicle should detect traffic lights associated with the current route. (not only the nearest one but also the next one in some cases)

Required functions

- Path(vector<Lane>?) getForwardPath(lane, distance);
- vector<TrafficLight> getTrafficLights(lane); // Assuming to iterate path

Similarly, we would need functions for finding other features from a Lane.

- vector<Crosswalk> getCrosswalks(lane);
- vector<StopLine> getStopLInes(lane);

If we just want to use features for localization, finding near features can be useful.
(It’s hard to use features that were found by distance for planning.)

- vector<TrafficLight> findNearTrafficLights(pose, range);
- vector<Crosswalk> findNearCrosswalks(pose, range);
- vector<StopLine> findNearStopLines(pose, range);
- vector<TrafficSign> findNearTrafficSigns(pose, range);

Use case: Stop Position Decision

Description

The vehicle should decide where to stop according to stop lines.
If it stops due to red traffic lights or crosswalks, it should know which is the associated stop line.

Sometimes crosswalks don’t have the stop lines, so it has to calculate where to stop from the shape of crosswalks.
However, I think it’s an application-level matter, not a map level one.

Required functions

- StopLine getStopLine(traffic_light);
- StopLine getStopLine(crosswalk);

I think it’s good for us to take these next actions:

  1. List up more functions using more use cases.

  2. Classify each function

    • can be efficiently/inefficiently implemented with Lanelet2
    • can be efficiently/inefficiently implemented with Lanelet2 if we extend it
    • cannot be implemented with Lanelet2

  3. Write pseudo-code for each use case

    • If it’s already implemented in Autoware.AI, evaluate the efficiency
1 Like
3

I have organized the requirements into one document. Please commend if there is anything else to add. Requirements.pdf (50.7 KB)

2019/11/13 update
Requirements20191113.pdf (56.7 KB)

1 Like
4

Also, here are some of the non functional requirements for map library. (discussed with @kenji-miyake)

  • There is quality assurance for map library
  • Map library works in real-time
  • HD map library works with very large maps
  • OSS developers can easily understand map format and map api
5

Regarding the requirement that the map should provide curvature and slope information for the motion planner - I agree it is useful information, but I would like to clarify is there an assumption that the map should provide a smooth reference path for a motion planner to follow? As it stands, one weakness of lanelet2 is that it doesn’t have curvature information - just a piece-wise center line. If fine grained enough curvture can be estimated (much like current autoware waypoint path).

How accurate should the curavture/slope information be?

6

Personally, I don’t think the map-data should provide them, because it will make the digitizing-process much complex.
So I propose that the map-data will provide as much accurate 3D pose as possible, and the map-library(or planner-library) will calculate curvature/slope.
However, when we switch to OpenDRIVE, I think we can support detailed curvature/slope as optional parameters.

How accurate should the curavture/slope information be?

I’m not sure but assume we don’t need so high accuracy.

7

I have updated the document and added columns to briefly indicate which function in Lanelet2 supports each requirement.

I will also share the link to google drive documents in case anyone wants to add comments.

8

Thank you very much for summarizing.

It seems Lanelet2 has enough capability, but sometimes
it gets complex even to accomplish simple features.
I think it’s better if we have a bit higher-level APIs.

Also, if we create an abstraction layer for future backend(Lanelet2) replacement, we need to define general data structures.
The reason is that if we directly depend on Lanelet2 data structures such as TrafficLight/TrafficSign/RightOfWay, it will result in many dependencies: boost and other Lanelet2 specific classes.

However in my intuition, to convert Lanelet2 into general data structures is too hard and it will increase the maintenance cost.
Therefore, I think we should definitely define new-and-simple Autoware-flavored data structures and use only them.
Otherwise, we will probably take a huge technical debt…

9

Yes, thanks Mitsudome-san.

A couple of comments:

  • For Global planner - requirement mentions series of “roads” detailed requirements only takes about “lanes”. Is this loose semantics or does a lane level planner equate to a “road” planner? I guess answer depends on architecture of planning module.
  • One functional requirement that isn’t listed, is the requirement to enable context aware prediction of other road users: given map and traffic rules - which are the possible valid future paths of an observed car/pedestrian etc.