Open AD Kit WG Meeting 2022/06/17

[ghost]

Administrative

• Previous meeting minutes
• Open AD Kit project board
• Open AD Kit 2.0 schedule

Attendees

Chaired by David

• Armağan Arslan (Leodrive)
• CJ (AWF)
• Daisuke Hashimoto (T4)
• David W (A3VG)
• Eiji Sekiya (T4)
• Esteve Fernandez (T4)
• Fatih (AWF)
• Fumihito Ito (T4)
• Hiroshi Igata (T4)
• Karmen Lu (ISEE)
• Kasper Ornstein Mecklenburg (ARM)
• Lalith Vipulananthan (T4)
• Naoyori Tanzawa (T4)
• Ryohsuke Mitsudome (T4)
• Samet Kütük (Leodrive)
• Stephen Li (Autocore)

Agenda

• Introduction of new members
• Announcements
• Review of backlog actions
• Discussion topics
  • Resourcing constraints around microservices PoC
  • MIH demo plan (CJ)

Introduction of new attendees/members

• No new attendees.

Announcements

• No announcements.

Review of backlog actions / open issues

• Integrate Autoware Universe with Open AD Kit and review the results
  • Verify that Autoware Universe can be run with Open AD Kit 1.0 autoware-projects#32
• Document Autoware Universe ROS nodes
  • https://github.com/autowarefoundation/autoware.universe/issues/827
• Update Open AD Kit wiki to explain the benefits of a microservices architecture
  • Update Open AD Kit wiki to explain the benefits of a microservices architecture autoware-documentation#102
  • The wiki has been updated as per the issue and so the issue has been closed
• Create an autoware.org meeting invitation group for the Open AD Kit WG and add it to each meeting as an invitee
  • Requested creation of an Open AD Kit WG meeting invitation group in the AWF organization, and waiting for the group to be set up

Discussion topics

Resourcing constraints around microservices PoC

• Still no takers for Update Contact of documents #353 at this time.

Setting up CI/CD for multi-stage (multi-container) builds

• Update Contact of documents #353
• Issue has been open for a month now with no volunteers/takers for the work

Containerization of Perception stack

• It has been suggested that it may be easier to containerize vision-based perception, rather than include the entire stack.
• David asked if there was anyone available who could talk about this suggestion, but no one was available.

MIH demo plan

• David noted that both of the points above (containerization and CI/CD for multi-stage builds) are on the critical path for the MIH demo plan, and that microservices specifically is a priority for MIH. He asked if Fatih is available to work on the microservices issues (discussed in a separate meeting earlier this week)? If not, does this need to flagged to the TSC as a high priority, assuming these things are important for the demo?
• CJ laid out potential demo plans for MIH:
  • Demo plan 1: Three containers (eSync, most of Autoware, the remaining parts [eg: Perception] in the third container). This is the ideal case.
  • Demo plan 2: Two containers (eSync, Autoware as a monolithic container), thne using eSync to update the entire monolithic container. It's a fallback plan and the minimum level we should aim for.
  • Open to other suggestions, but if there are none then we need to make a decision on which plan we are going with.
• In terms of availability of the AVA platform that is being targeted for the demo: T4 and ARM have one each, and Daniel Shih at the University of Taiwan has one as well and will be testing the demo.
• Fatih said that we should work on a bottom-up approach for the demo.
  • Detail the final goal that we want to achieve, and make it something we can achieve in time, then work on the tasks needed to achieve that goal and give that the highest priority.
  • Demo is in October so everything must be ready by September, and we need to have decided on what we will be doing/showcasing by the end of June.
  • To avoid copying around large volumes of data by splitting Perception from Localization (for a 128-laser LiDAR or multiple 32-laser LiDARs, processed point cloud data would be 5MB messages at 10Hz), Fatih suggested putting drivers, sensing, perception and localization into a single container, then put planning and control in another container.
    • Planning doesn't necessarily require taking in a lot of data: tracked objects, localization output, and point cloud data, but that point cloud data can be downsampled.
    • Separating Autoware into these containers should be much easier than trying to separate perception. However, he needs to know which sensors will be used in the demo, so he can confirm if ROS 2 drivers are available or if the driver is optimised for LiDAR (and the same for any camera that will be used)
    • First stage would be to separate the nodes into two parts then build using "colcon build --packages-up-to", then separate the launch files into two parts - all manually. If launch files need to be split according to which container they will be running in, then we need to automate the action of creating the launch files as well but that will be a lower priority.
    • Each container will contain the entire Autoware repository (all source files) then both will compile different parts of the system. There will be some duplicate compilation for any nodes required by both containers, but this shouldn't be a big a problem.
  • Ideally, we would have a proper working simulation with one computer has both containers controlling another computer running on a working demo vehicle. First, we can get the rosbag running and then if we have a Lanelet2 map we can show that the Planning component is planning even if that plan is not reflected by the actual vehicle.
• Since discussion has shifted to the idea of Planning and Control being containerized, CJ had some thoughts on a different kind of demo but one that would involve more work. MIH wanted the AWF to demonstrate some of the APIs, so if we're doing planning and control then maybe we demonstrate the DBW interface with a F1TENTH vehicle?
  • Fatih commented that using small-scale vehicles to showcase Autoware's DBW output is not a good idea. Getting an L6/L7 vehicle chassis that was elevated from the ground, and demonstrating that Autoware can rotate the wheels of this large-scaled vehicle and turn those wheels would be a much better demonstration/advertisement for Autoware.
  • CJ noted that what MIH wants to demonstrate is the capabilities that are being developed by the consortium and workshop.
    • Work has started on a sensor API (focused on a Foxconn Lidar) that supports the MIH API running on an AVA platform, so a demo could be focused on sensing, localizing and perception workloads working with that LiDAR.
    • Or do planning and control workloads demonstrating vehicle control with the DBW interface and simulation of scenarios.
    • Something along those lines are compelling demonstrations of a software defined vehicle framework with a microservices architecture supporting the MIH APIs.
    • He also noted that the CoE did a demo with a go-kart.
  • David commented that F1tenth is running with ESC or more of a RC setup, but it may be possible to find a larger scale chassis bigger than F1tenth that communicates with its motor and steering through a CAN bus, which is more in line with a full-size vehicle.
• Armağan asked about who would be running the actual demo and wanted to hear their thoughts, since ultimately they are responsible for the demo working successfully and so should have input into this decision.
  • CJ said that Daniel Shih at the University of Taiwan would be testing the demo in his lab at National Taiwan University and running it at the actual event. He should be kept in the loop and invited to the next Open AD Kit meeting.
• Tanzawa-san commented that what we can do is limited by the timeline. MIH does not have so much in the way of specific requirements, so we need to propose to them what we can achieve in the given timeline. Hashimoto-san is working to update ConOps/OpsCon based on the current understanding so that we can align, and will present in next week's meeting.

Actions

• Ask Daniel Shih to join next week's Open AD Kit WG meeting
• Fatih to begin work on the microservices PoC, based on his recommendation above, and report his progress in next week's meeting
  • Runtime Manager, changed wx.Color to wx.Colour for wxPython3 #434