Mapping Technical Document

Mapping Technical Document

---

Lanelet2

Lanelet2 is a library that handles high-definition map data in the context of autonomous driving. It uses the OSM XML format to store data.

Open Street Map

Open Street Map is a free-to-use mapping platform (like Google Maps but opensource). You can export mapped areas of the world and retain features like roads, crossings, and lanes, making it an ideal candidate for getting basic map data.

Building a Lanelet2 Map

Lanelet maps are most often created through the use of JOSM, a GUI OpenStreetMap Editor. JOSM allows for the creation of all geometry expected from Lanelet2 Maps.

Using Lanelet2, maps can define lanes, signal lights, routing points, traffic rules, and more.

Localization using the Lanelet2 Map

Even though the Lanelet2 map predefines many features of the diving environment,

Lanelet2 Map Provider

To provide the data from the Lanelet2 map to other ROS nodes, the lanelet2_map_provider exists in Autoware. If an outside node requires epcific information (for example, a LaneKeep node needing lane information, or a route planning node needing traffic light information), it needs to make a request to the map provider node for the data.

• The request will contain the geometric area for which data is requested and the specific contents needed.

We won't have to build a Lanelet2 provider from scratch because Autoware provides this for us, but it's hard to find exact documentation.

Useful Links

How to build correct Lanelet2 map for Autoware.Auto ? - ROS Answers: Open Source Q&A Forum

Launch File Example for map provider

Basic Documentation

---

PCD map publisher

Our stack uses a pre-collected PCD (Point Cloud Map), combined with the current "finished" PCD from the lidars to localize and plan future routes.

Use Cases

Localization

The localizer needs data from both the pre-collected PCD map and the "current" PCD map, so it can identify where in the relative world it is. It takes data from the "current" world using the lidars, creates a downsampled PCD file, and compares it against the pre-collected map, so it knows where in the predefined world it is. Then, it can take this information to the Lanelet2 Publisher node and request detailed information about the road features, driving environment, etc.

3. The internal operation of each node, with as much detail as possible

Publishing PCD Map Information

The stack has 2 PCD maps that various nodes need information from - the pre-collected map and the current map.

Inputs

This ROS node takes input from a PCD map file, requires some context attached to the file, like an origin, or "known location", and lastly, the area for which data is being requested.

• These parameters make it possible for the Node to publish data contextual to a certain point in the map, instead of random points.
  • For example, the localizer could request PCD data from a point 20 feet from the last known location, to localize itself as it drives further down a road, but to get accurate data, it needs the context of last known location

Outputs

The Node should output the requested area (in the case of the pre-collected map), or the area the vehicle is currently in (if requesting current data), in a form the localizer can read.

Node Internals

For the node to work, it needs to process a given PCD file or point cloud and return a subset of the cloud for another node to use, either from the predefined map or from the data being collected via lidar.

To get from the PCD file to the cloud being returned, the node needs to find a "center" or "origin" for the area being returned (if Lidar, the car is the center, otherwise, the request should specify). Once the origin is known, the area being returned can be found with simple calculations.

• The point clouds from the lidar or defined map are well-formed and points are defined in terms of meters, so simple math can find the relevant points and return them as needed.

---

Map Stitching

Problem

When collecting map data for our route on campus, it cannot be done in one recording or session - traffic, road features, etc will always limit our ability to accurately collect lidar data over the route.

Solution

Instead of mapping the entire route at once, we can split the route into multiple sections, map them individually, and then "connect" them together to create a "final" map, containing all the data needed.

To do this, the individual maps' start and finish need to be "linked" or aligned with each other. To do this accurately, you cannot just put them next to each other - they need to be aligned to account for slight inconsistencies that will appear during "breaks" when mapping.

• This will also allow us to update sections of the map when changes are made to roads, instead of having to remap all of campus every time construction happens somewhere