Design

Introduction

Purpose

This document describes SOW Phase 2 project (Autoware stack over zenoh-flow) related technical architecture, product demo methods and work schedule.

Scope

The SOW Phase 2 project goal is to build an autonomous driving environment based on zenoh-flow and Autoware. zenoh-flow provides basic operation framework and data flow transmission, Autoware provides algorithm library.

The project should include:

• Fully open-sourced code baseline.
• One-click environment setup and demo mode.
• The planning and control functions based on Autoware.Auto in zenoh-flow framework.
• Autoware.Auto based API interface and message data structs.
• Modify ROS pub/sub message types to use zenoh-flow data flow transmission.
• Modify ROS launch to use zenoh-flow scheduling rules.
• Modify ROS param system to use zenoh-flow graph config file.
• Visualization module based on ROS2 Rviz2. The project should not include:
• Any black box third-party core library.
• The localization and perception functions in Autoware.Auto in zenoh-flow framework.
• Modify ROS visualization message types and Rviz2.
• Modify ROS tf2 message types and tf2 system.
• Modify ROS service message types and service system.

Definitions, Acronyms, and Abbreviations

References

Eclipse Zenoh-Flow

Zenoh-Flow allow users to declare a dataflow graph, via a YAML file, and use tags to express location affinity and requirements for the operators that makeup the graph. When deploying the dataflow graph, Zenoh-Flow automatically deals with distribution by linking remote operators through zenoh.

A dataflow is composed of set of nodes: sources — producing data, operators — computing over the data, and sinks — consuming the resulting data. These nodes are dynamically loaded at runtime.

Remote source, operators, and sinks leverage zenoh to communicate in a transparent manner. In other terms, the dataflow graph retails location transparency and could be deployed in different ways depending on specific needs.

Zenoh-Flow developed with Rust.

Autoware.Auto

Autoware is the world’s first “all-in-one” open-source software for self-driving vehicles hosted under the Autoware Foundation. The Autoware.Auto project, based on ROS 2, is the next generation successor of the Autoware.AI project, based on ROS 1. The major differentiators of Autoware.Auto compared to Autoware.AI are:

1. Modern software engineering best practices including code reviews, continuous integration testing, thorough documentation, thorough test coverage, style and development guides
2. Improved system architecture and module interface design (including messages and APIs)
3. An emphasis on reproducibility and determinism at the library, node, and system levels

CXX

CXX library provides a safe mechanism for calling C++ code from Rust and Rust code from C++, not subject to the many ways that things can go wrong when using bindgen or cbindgen to generate unsafe C-style bindings.

Architectural Goals and Constraints

• Make full use of the Zenoh-Flow functions
• Avoid large-scale modification of AutowareAuto and ROS code
• Demo should be simple and reliable

Architectural

C++/Rust Hybrid Programming

Zenoh-Flow framework code is implemented by Rust, and the Autoware algorithm is inside ROS framework and implemented by C++. How to get an executable file containing both side code logic. There are two ways here:

• Use Rust cargo compilation system to link in the libraries generated by the C++ code.
• Use the ROS build tool colcon to link the library generated by Rust.

Finally, we chased the second, which is the purpose of the previous architecture goals: Avoid large-scale modification of AutowareAuto and ROS code, prevent the original ROS launch from unavailable. And the first option will handle very complex ROS include paths problem.

In the original ROS framework, a message is bound to a callback function when subscribing to a topic, and this project needs to be passed into the message callback function from Zenoh-Flow.

Send data directly using publish method under the original ROS framework and needs return to Zenoh-Flow side in this project.

How to connect the methods between C++ and Rust language and transfer data types? We use CXX to generate binding codes between C++ and Rust：

• Operator framework writes in Rust, calls extern functions defined Rust code FFI mod.
• Build operator framework to static library.
• Use CXX generate C++ code from Rust FFI mod.
• Write C++ operator functions called by operator framework, matching FFI interfaces.
• Build C++ operator code to dynamic lib and link the previous static library.

ROS message types defined in independent files witch Rust side cannot use directly. CXX needs all message types defined in FFI mod and generate corresponding data types different from ROS message types. We provide two ROS package for this message conversion:

• rust_cxx_autoware_auto_msgs: Use python script to scan autoware_auto_msgs IDL files and get the corresponding Rust FFI mod code, then generate C++ FFI message types.
• rust_cxx_autoware_auto_msgs_cov: Conversion between ROS message types and FFI message types.

They are the packages that other nodes rely on.

ROS node and Zenoh-Flow node

Usually, ROS nodes have the following functions:

1. Param mapping from ROS launch.
2. Spin thread or loop workflow.
3. Message pub/sub functions.
4. Service server/client functions
5. Log and timer

And Zenoh-Flow nodes have the similar functions:

1. Config from graph file
2. Callback on data flow

We use ROS node functions as backup and replace ones Zenoh-Flow covered. Service and TF system in ROS are retained.

When Zenoh-Flow operator node startup, an ROS node also awaked, but not send ROS messages in zenoh-flow launch method.

A new node inherited from ROS node can set runtime type between ROS/Zenoh-Flow and so on, and auto switch the pub/sub functions between different runtimes. This mechanism allows the same node codes to be launched by ROS and Zenoh-Flow.

Used AutowareAuto components

For setting up planning and control functions, those main components are used from AutowareAuto.

• Lanelet2 Map Provider: Load lanelet2 map from target path and create a ROS service for other node search map data.
• Lanelet2 Global Planner: Provides a global path planner with the lanelet2 openstreet map (osm) xml. It plans a shortest path/lane from a current location to the final parking spot following traffic rules define in the map. The path is given as an array of the lane id from the starting to the goal position.
• Behavior Planner:
  • Convert the list of Semantic Map primitives provided in global path into sequence of trajectory points by querying relavant trajectory planners.
  • Modify path velocity profile of trajectory so that vehicle stops before detected obstacles.
  • Splitting splitting trajectory at gear change. This is only meant to be temporal function until controller can handle a trajectory with reverse motion.
• Lane Planner: Used to calculate trajectory within lanes. It will use centerline of lanes obtained from HADMap and convert it into trajectory.
• Parking Planner: The purpose of the parking planner is to plan complex maneuvers for moving a vehicle into and out of parking spots, avoiding obstacles along the way.
• Object Collision Estimator: The collision estimator takes a list of objects detected by the perception stack and the local path produced by the local planner as inputs. It then predicts any collisions between the ego vehicle and static obstacles. Finally the local path is modified to avoid any potential collisions.
• Pure Pursuit: Pure pursuit is a basic algorithm for the trajectory following and widely used in autonomous robot applications. Pure pursuit algorithm finds the adequate target point from the trajectory and computes the radius of curvature. The longitudinal acceleration is computed using velocities of the current vehicle and target point.
• Simple Planning Simulator: This node simulates the vehicle motion for a vehicle command in 2D using a simple vehicle model.

This graph shows the data flow of those components in AutowareAuto.

Zenoh flow nodes group

Autoware ROS nodes are seal in Zenoh-Flow operator nodes. When deploying on a single device, both ROS and Zenoh-Flow nodes use shared memory communication. And when deploying on multiple devices, ROS use Cyclone DDS and Zenoh-Flow use Zenoh for network communication.

Tick Source

In ROS nodes there are usually timers callback functions to perform calculations. In Zenoh-Flow we need a similar mechanism.

Tick Source gives operator the update time and perform the data flow.

Lanelet2 Map Provider Source

Map provider source load map configurations from graph yaml file，and launch lanelet2_map_provider node that provider HD map service.

Lanelet2 Global Planner

Lanelet2 Global Planner have no configurations, and process on current pose and goal pose are valid.

Local Planner

Local planner update trajectory and vehicle state command every tick.

Lane Planner

Parking Planner

Obstacle Collision Estimator

Pure Pursuit

Simple Planner Simulator

Deployment and Run

All nodes are packaged as ROS nodes, and installed into system paths. And Zenoh-Flow runtime are installed into user home path. Runtime load graph files in system paths can launch the demo.