ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Autoware.Auto Autonomous Valet Parking hackathon and demonstration - April, 2020

The Autoware Foundation is planning a significant hackathon for Autoware.Auto in April, 2020. This post contains the details.

This post will be amended as more information becomes available.

Goals

The goal of the hackathon is to polish off the Autonomous Valet Parking use case functionality and finalise getting it working on a real vehicle.

Because it is not feasible to be implementing self-driving functionality within four days, the intention is to have the necessary functionality in Autoware.Auto completed before the hackathon starts. A simulation of the demonstration location in the LGSVL simulator will be used for testing and development by most developers prior to the hackathon.

Schedule and location

The hackathon will take place over five days in April, 2020. The first four days will be dedicated to finalising the demonstration and fixing any remaining issues in Autoware.Auto. The final day will be the demonstration itself.

The hackathon will be held at Apex.AI’s office in Palo Alto, California. The demonstration itself being held at the AutonomouStuff parking lot, which is about ten minutes’ (manual) drive away.

Planned software

  • The Velodyne driver will be the one developed originally for Autoware.Auto by Apex.AI and being pushed to the ros-drivers repository for ROS 2.
  • Localisation will be performed using the deterministic NDT implementation currently being proposed for Autoware.Auto by Apex.AI.
  • Obstacle detection will be based on the euclidean clustering implementation present in Autoware.Auto.
  • Planning will use a new behaviour-tree-based planning architecture provided by Tier IV.
  • Motion control will use a deterministic implementation of MPC provided by Christopher Ho and Apex.AI.
  • The vehicle interface will be provided by AutonomouStuff, who have just recently completed a ROS 2 version of their PACMod driver and considering a port of their Speed and Steering Control software stack.
  • The map format used will be OpenDrive.
  • Safety will be achieved via an emergency stop, due to the low speed.

Hardware platform

The hackathon and demonstration will be performed using Apex.AI’s Lexus. This SUV has two Velodyne 16s mounted front and back for localisation and obstacle detection, an advanced GPS/IMU sensor, and a Nuvo computer.

3 Likes

Please vote for the week of April, 2020 you prefer the hackathon to happen in. The dates for the hackathon will be chosen based on which week is most popular, weighted by attendence of key people.

  1. April 6 to April 10
  2. April 13 to April 17
  3. April 20 to April 24
  4. April 27 to May 1

This poll will close on the 20th of November. Please vote before then.

  • April 6 to April 10
  • April 13 to April 17
  • April 20 to April 24
  • April 27 to May 1

0 voters

Just a clarification from AutonomouStuff: we have just completed the ROS2 port of our PACMod driver but SSC (the Speed and Steering Control) software stack has yet to be ported. We are currently discussing this effort internally.

1 Like

Thanks for the clarification. I’ve updated the post.

Just to clarify a few things:

Is there a registration link?
Are there P R I Z E S?
Are there any needs for coordination ahead of time?

There is no registration link (yet?) because we’ve only just started organising it.

There might be beer if we actually get the demo to work? Perhaps Dejan’s people will give a BBQ again! But in general we haven’t thought about prizes and I’m not sure what we could offer them for. Open to ideas! :slight_smile:

I’m not sure what kind of coordination you are talking about, but in terms of organising things, @esteve and myself are on that. If the OSRF wants to contribute, we are very happy to have the help!

I’m not sure what deployment tooling there already is but I might be up for building an USB ISO installer for the hackathon.

@LucidOne thx. However we are talking here about the ROS 2 project. I see that ROS Installer Tooling is about ROS 1.

For the Autoware.Auto we currently use:

  1. ubuntu/debian installer with the preseed file
  2. ansible role to install additional packages and scripts
  3. ade-cli with the associated volume versioning file to install the right version of Autoware.Auto

If you think that you can simplify above and are willing to be in charge of the whole computer installation during the hackathon - you are more than welcome to join us.

@gbiggs et al, couple of updates on above:

  1. We talked to the main players for the hackathon and got commitment for the above “Planned software” section.
    1. The change is that the Global Motion planner can also be done by Embotech instead of Tier IV. In the next TSC meeting we should get a confirmation if Tier IV will contribute something to this hackathon or not.
    2. LG is committed to provide the LGSVL simulator support
    3. AutonomouStuff full commitment to ROS 2 version of Speed and Steering Control software stack is still pending but it is also likely yes. They already have ROS 2 version of the PACMod driver, Kvaser interface and msgs
    4. Map WG is also super active https://gitlab.com/autowarefoundation/autoware-foundation/wikis/autoware-working-group, they have AutonomouStuff car park map but we were not yet able to talk to them yet
    5. We still need more people to provide
      1. tooling (rosbag record scripts, rosbag hosting, rviz config files, debugging, GUI)
      2. integrations (launch files, automated and manual testing, …)
      3. NDT Pose and Odom fusion to obtain a vehicle state
  2. Chris and I provided a high level architecture diagram. We plan to refine that in the next week or two and present it in either Autoware or Maps WG meeting: https://docs.google.com/presentation/d/1grOelGw1b2Lx3xaTlUpdlBi0Hn45SvWabEx8iYcYNAk/edit?usp=sharing:
  3. Several people approached me with the question “What exactly do we plan to do/show?”. I would like to see the following in order of preference:
    1. Lexus starts on point A (in the lane somewhere in a car park). Operator (back seat) gives it a target point B (in a parking stall somewhere in a car park):
      1. Lexus drives the whole path with dynamic obstacles (other cars, pedestrians, cyclists)
      2. Lexus drives the whole path with other static cars (parked on the lanes and in the parking stalls)
      3. Lexus drives the whole path on an empty parking lot

LMK if there are more questions.

I would like to follow our original 5-step plan up to the point where it stops making sense for the demo. This is:

  1. Waypoint following
  2. Parking the car (single-level, empty)
  3. Parking the car (single-level, occupied)
  4. Parking the car (single-level, with pedestrians)
  5. Parking the car (multi-level, with pedestrians)

Obviously #5 doesn’t make much sense for the hackathon’s goals because we don’t have access to a multi-level carpark. However I think trying for 1-4 in order, planning to achieve at an absolute minimum #2 and aiming to achieve #4, makes the most sense.

I think we should try to knock each of these off in the simulator and then bring the one with the highest chance of success to the hackathon.

Personally I won’t be satisfied unless we can achieve #4, and I think it is possible.

1 Like

That’s a good high-level block diagram, but it needs a lot of work before we can use it as an architecture diagram. We need to identify specific interactions (such that we can design the interfaces: data flows, service calls and actions); we need to understand data rates; we need to identify execution timings; we need to identify the safety architecture; we need to understand which nodes we can colocate and which should be in separate processes; etc.

@gbiggs I agree with above. Sorry that I forgot that we defined this already before.