When are planning to do planning from a parking spot to another in Autoware.Auto, the global planner expects to be planned from parking_spot -> parking_access -> lane -> parking_access -> parking_spot.
- parking_spot: The actual space to park, and Autoware.Auto will try to park at the center of this object. It is defined as lanelet2 Area objects(
multipolygon in osm). It should have following tags: subtype=parking_spot, parking_accesses=<list of relevant parking access>. Autoware.Auto also assumes that the parking spot is rectangle shape with 5 points where first and last point overlap.
- Parking Access Areas: This is used to define free space between parking spot and its nearest lane. Parking planner will use the shape of parking_spot, parking_access, and lanelet to calculate trajectory. Parking Access Areas are defined as lanelet2 Area objects(
multipolygon in osm). It should have following tags: subtype=parking_access, ref_lanelet=<id of the nearest lanelet>
- Lanelet: Lane objects to define lanes with right bounds and left bounds. See lanelet2 document for the details.
If you are familiar with c++, looking into the global_planner source code might help you get some idea.
What did I do wrong in the .osm file?
You have to add multipolygon relation to define parking_spots. You also have to define parking_access area as well. Although you don't have any "gaps" between lanelets and your parking spot, Autoware.Auto expects this object to find out the connection between lanelets and parking spots so you can perhaps create one that is overlapping with the parking_spot. Also, it seems like you are trying to drive through lanes, in that case, you might not need to define parking spots at all.
If you still don't see a map in RVIZ, I doubt there is something wrong with configuration of the origin when loading the map.
Originally posted by mitsudome-r with karma: 231 on 2021-04-29
This answer was ACCEPTED on the original site
Post score: 3
Original comments
Comment by congphase on 2021-04-29:
Thank you, Mr. @mitsudome-r, I eventually created a map that trajectories were successfully planned, a day after I asked this question, but I didn't have time to post an update here. Here's my result link
The main reason why I met confusions about figuring out the rules is:
I opened autonomoustuff_parking_lot.osm in JOSM with Imagery, searched for parking_accesse s, parking_slot s by IDs to visually see what they are. But that gives me ununified rules. Sometimes a parking_spot is really a rectangular parking spot, but some times it's like this
Searching by IDs in JOSM shows highlighted "objects" (nodes, ways...) corresponding to that ID. Those objects are not the parts that form the corresponding parking spot. Instead, they contain that ID as sub-string(s) in their tag values. The appropriate way to navigate to an interested object is demonstrated as link. Those who're getting familiar with JOSM can refer.
Comment by Aleksandr Savel'ev on 2021-05-12:
Hello, @congphase . Do you use ssc_interface and vehicle_kinematic_state topic respectively to start lanelet2_global_planner_node ?
Comment by congphase on 2021-05-17:
Hi @Aleksandr Savel'ev. Sorry for the late response. Yes I did. Both of them are used during the lanelet2_global_planner start.
Comment by rugved on 2021-07-07:
What is the "cad_id" and how to find out "ref_lanelet" and "parking_accesses" number to provide it in the relation?
Comment by congphase on 2021-07-07:
@rugved "parking_accesses" is a tag that exists in a relation of type "lanelet" or type "parking_slot", it holds the IDs of the relations of type " parking_access". So you just need to determine the parking accesses (the one multipolygon between a parking slot and the associated lanelet), look for its relation ID, and insert it to the value string of the "parking_accesses" tag in "lanelet" and " parking_slot" relations. This should make the global planner work.
I don't know what cad_id means. cad_id is not quite important for global planner, if I'm not wrong. So you can try skipping it to see if all works.
Comment by rugved on 2021-07-07:
Thanks for the quick response @congphase, really appreciate it. The thing is in the map you provided above, the relation id (-99805, -99807,-99808) has a parking access id as -99786. However, the relation id -99786 is not present in the map. Am I missing any links here?
Comment by congphase on 2021-07-07:
@rugved I don't have a computer now. It's midnight in Vietnam, my country, at the moment. I'll check and reply to you in the next morning.
Comment by rugved on 2021-07-07:
Thank you, appreciate it.Also, what is the center in parking spot relation? How did you provide those values? Were you able get the elevation from JOSM or added manually after?
Comment by congphase on 2021-07-07:
@rugved You're right, it's not in the map. There are 2 parking accesses in my map: -99828 and -99806.
As I remember, JOSM will assign objects with different negative IDs every time you save the .osm map without uploading to OSM server. Only uploading to OSM server makes all object ID positive and permanent. So this must be the reason for the absence of -99786. Understanding this, you'll just have to make sure the .osm text of the objects closely reflect the relationship parking spot <--> parking access <--> lanelet, then it's okay.
For me, maybe the global planner only expects the relationship related to one parking access, i.e -99828 to work well, I skipped to check all the .osm text again.
Comment by congphase on 2021-07-07:
@rugved About the centers in the parking spot relations. I just used the mouse to drag and copied the parking spots of the Autoware.Auto sample map and pasted in my map, to make sure it's perfectly a rectangle. Other than that, I didn't care much. You can take a look at code implementation for how the global planner parses the .osm map to figure things out.
Comment by rugved on 2021-07-08:
@congphase Thank you for the answer, I figured out about the centers, In the JOSM after selecting a center node for Multi-polygon parking then View - > Advance info would give a node id which can be provided in the center id. This is true for parking_accesses and parking_spots relations as well.