Collect feedback from MIH and Foxconn about their expectations for Open AD Kit

[ghost]

Checklist

• [X] I've read the contribution guidelines.
• [X] I've searched other issues and no duplicate issues were found.
• [X] I've agreed with the maintainers that I can plan this task.

Description

Collect feedback from Autoware community members about their expectations for Open AD Kit 2.0

Purpose

One of the aims of Open AD Kit is to develop a microservices architecture for Autoware that will allow AWF partners to easily insert their own solutions into the Autoware framework. For example, a company that specialises in perception will be able to replace the existing Autoware perception stack with their own solution.

With that in mind, it would be useful to clarify the expectations of such partners to ensure that future releases of Open AD Kit will meet their needs.

Possible approaches

Collate feedback from MIH and Foxconn

Definition of done

When feedback from the companies mentioned above has been gathered and added to the benefits and use cases for Open AD Kit 2.0.

[ghost]

CJ provided a use case that was a joint proposal from the AWF and MIH/Foxconn (see slide 3 of the attached document).

Open AD Kit 2.0 Proposal.pdf

[ghost]

Demo proposal 1:

• Autoware runs in two or more containers on an edge device, with a LiDAR or camera sensor attached
  • Each container only contains the modules that are running within it
  • For example, a two container setup where one container includes only Perception modules, and the other container includes all other modules
• The eSync OTA service runs in its own container
• A problem is demonstrated with object recognition at the edge, which can be reproduced in simulation on the cloud
• A change is made to the Perception component and verified by cloud simulation
• The Perception container is then updated over-the-air using the eSync OTA service
• The original object detection issue at the edge is shown to be resolved

Note: For the sake of convenience and keeping the demo time short, prebuilt containers will be used for the "fixed" Perception code.

If it is not possible to achieve the proposed demo above, then a backup proposal is as follows:

Demo proposal 2:

• Run monolithic Autoware in one container and the eSync OTA service in a separate container
• Demonstrate the same principles as before (show a problem with Perception, confirm in simulation, fix issue and verify in simulation)
• Update the monolithic Autoware container over-the-air using the eSync OTA service