Skip to content

step-3-pick-components.md

Latest commit

 

History

History
37 lines (25 loc) · 5.01 KB

step-3-pick-components.md

File metadata and controls

37 lines (25 loc) · 5.01 KB
Raw

Hack Challenge "Driving Score"

Step 3 - Identify the needed components

Vehicle software components usually use middleware to communicate with each other. There are plenty of middleware tools available, depending on the use case, type of data or type of deployment.

You can work with well-known network protocols, such as gRPC, MQTT, HTTPS, or with some more sophisticated automotive protocols, such as Some/IP or DDS.

After identifying the software projects you want to use, identify which protocols they support and how they fit to each other. Read the documentation of the projects, many have good tutorials and example code.

Example List of components

This list of components is based on the example architecture and data flow. If you have a different architecture, you may need other components.

  • Eclipse Kuksa.VAL Data Broker for storing and brokering vehicle data between in-vehicle apps and services
  • Use Eclipse Kuksa.VAL DBC Feeder for simulating vehicle data from pre-recorded or live CAN-Bus
    • Alternatively, you can use this docker container to simulate Vehicle.Speed and Vehicle.Acceleration and this docker container to simulate a very simple human driver (eg Vehicle.Chassis.Accelerator.PedalPosition)
  • Chose a programming language for your "pre-processing" component, which transforms the raw data (eg Vehicle.Speed) into something of lower sampling frequency (eg. acceleration is delta v over delta t and then take the average of the acceleration over a moving-window of the last 5 data points). Push the acceleration into the Kuksa Data Broker as the structured value "Vehicle.Acceleration" with its attribute "long, lat, vertical".
  • Eclipse Velocitas as toolchain and framework for implementing the driving score business logic. Use the template repositories as a quick starting guide. There's also a tutorial.
  • Eclipse Chariott as an Application Programming Model that provides a common interface for enabling application lifecycle management and communication between applications.
  • Use Docker to build, package and deploy your app to a container registry.
  • A container registry, eg GitHub packages, Docker Hub, canister.io or https://ttl.sh/
  • Eclipse Leda quickstart images on the provided SD-Cards during the hackathon for your target devices. If you need to reflash, you can download a snapshot Leda build for Raspberry Pi 4
  • SOAFEE EWAOL provides containerisation and virtualisation capabilities within a light Linux-based distro. Secure isolation of vehicle function domains is crucial - the Xen type-1 hypervisor provides part of this isolation. Try a microSD card with an appropriate image preloaded for the Raspberry Pi 4 at the event. An image of Eclipse Leda has been built which can run under the hypervisor in SOAFEE EWAOL here. You may use ubuntu-xenguest.conf as a reference for creating a suitable Xen guest definition.

Example List of components (ROS)

  • Eclipse Muto Agent & Composer: To manage stacks running on the device etc. Follow the instructions at the Eclipse Muto Documentation, and the Eclipse Muto for the JetRacer here
  • Eclipse Kuksa.VAL Data Feeder for Muto: Shares AckermannDriveMessages in the form of VSS (@sven.erik)
  • Muto YAML based Configuration: To configure vehicle, algorithms and plugins.
  • Muto Stacks: To choose and manage the lifecycle of what runs on the device.
  • ROS Based Drive Score Computation: A python based ROS node that consumes Ackermann Drive Data and computes a drive score and sends it to Digital Twin as a feature. (See ROS python development guides here and examples for the JetRacer)
  • Muto Dashboard Plugins: A user interface to control vehicles and visualize data dashboard by example.

Next: Step 4: Implement the driving score vehicle app