Set up & configure Autoware mapping component

[dylan-gonzalez]

Understand Autoware Mapping and Creating Maps

• [x] can we use Open Street Map (rather than recording a map ourselves)?
• [x] research how to make the relevant map data for Monash Research Way
  • [x] research on how to make a pointcloud map of Monash Research Way
  • [x] research on how to make a lanelet2 map of Monash Research Way
• [ ] create the relevant map data we require
  • [ ] make a lanelet map of the West One carpark
• [ ] set up mapping component as outlined in the [AVP Diagram (https://app.diagrams.net/#G1T9vIuZJyE1f5AhWn4aL91sWi9EbfGOO_) by configuring the autoware mapping launch file so that we have the mapping component running and publishing appropriately
• [ ] [where it makes sense] ensure the planning component adheres to the interface defined in the AVP Diagram and works in general across a series of appropriately designed test cases to be run by the CI/CD pipeline

If you need to test Autoware with a simulator, read here.

[zcdai]

OSM is not suitable for our pointcloud requirements, the data they provide is low-fidelity. This highlights how they have elevation data and vector points to form the surface of an area, which aren't suitable for our 3D use-case.

This tool helps us make lanelet2 files (vector maps), provided with a PCD map as a baseline. More details will have to be looked into via the documentation here

Also the mapping documentation needs LiDAR as a baseline for making PCD files, this should be possible with our current resources.

[AnthonyZhOon]

11-12-23

So, right now our mapping isn't very detailed so it's hard to create a vector map. We need to consider how to record more detailed pointcloud maps

[ZileiChen]

A few screenshots of our pcd map

This one is okay, there might be a few misalignment issues where you can see faint outlines of trees inside the parking lot. Its possible to make a vector map out of this since I am able to see the where the curbs are meant to be.

This one is a lot better, and was the last record we did, similar problems as the one above but the image quality is a lot higher compared to before.

From the 5 rosbags, 1 of them was a recording of the drive to the car park, I noticed that driving once on a road created a pretty decent pcd map. Thus, another way of trying to scan we could try is to just drive back and forth in a straight line (slowly) to minimize misalignments.

Attempting to create vector map now.

[ZileiChen]

woodside_lanelet.zip

Had issues saving the pcd files. Used the Woodside car park scans from last semester to create a lanelet2 vector map instead for now. The left side is hard to map since I cannot tell where exactly the parking spots end + there are people scanned.

[zcdai]

Looking at this tells us that if we want to make lots of parking spots, we need to break the long road into multiple small components.

After fiddling with it I got this:

Despite it looking very innocent, making a parking block involves:

• Creating a point on the center linestring
• Connecting each point to the corners on each parking spot via a linestring
  • You can kind of cheat the curved line by copying the first linestring and then manually modifying the end point ids, this is still tedious however
• Create a new linestring between the corners of the parking spot that intersect with the road
• Create a new linestring between the corners of parking spot that intersect with another parking spot
• Select all 4 linestrings that make a parking spot, and create an area

This tedious process makes scalability look very unlikely unless we learn of some shortcuts in the future.

Some other points: Area subtypes may allow us to customise software logic when handling these zones in the future, for now they have been marked with 'parking'.

Creating many linestrings on top of each other may not be a visible problem to a map designer, but the software may treat it very differently and run into logic errors.

Currently planning to cease work on woodside pcd. Instead, reduce the problem down into a simple 1-way road with only 1 parking spot. Once the single parking spot problem has been solved we can expand back into real-world usage.

Also how did tierIV make such clean curves...

Here's the file if you want to see how it was done:

woodside_lanelet_parking.zip

[dylan-gonzalez]

@zcdai to test parking with Autoware

[zcdai]

Things looked at this week:

• osm simplified to the 1 lane case

• create map dir in the beast, but osm will not load, perhaps something to do with yaml files,

  • noticed osm versions were different compared to sample files, and that no llonglat coordinates were saved, only local x y

• used their sample parking demo to see the features and implementation instead.

Their implementation of parking is very novel, and I'm not entirely sure how it works

This is what it looks like in rviz:

This is what it looks like in the map builder:

This makes scaling up much simpler, we simply have to cover the entire area with a polygon with a parking_lot subtype and insert linestrings with parking_space subtypes. It's unnecessary to create the arduous bends using this method.

Will look into why these implementation returns clean blocks in rviz and transfer this info into woodside parking

[dylan-gonzalez]

How does autoware handle these zones ? Specify parking x-y coords with pose

This week: parking into designated zones (might have to write our own custom node)

[ZileiChen]

https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/678

A previous project was similar to what we had, in terms of mapping we designate each parking spot as an area.

[ZileiChen]

Another strategy used here is to 'narrow' the driving area such that instead of dividing the road up into segments to create parking areas, a second line is used to divide parking spots. This could also just be how the car was designed. There wasn't any turning arcs in these maps for each spot which means we can use autoware to somehow create a way to park into these spots without following the map