Status Update: 2022-09-28

[haixuanTao]

Status Update 🔥

[haixuanTao]

Dora-Drives

Localisation operators

GPS can sometimes be not accurate in environment with high rise building.

With Bob, we worked on finding alternatives to do localisation and came up with two:

• NDT Localizer from Autoware through a light weight version ndt localizer. It use a 3D map of the environment to find its own localisation through LIDAR.

• IMFNet. Through point cloud registration, it can find the displacement between two point cloud and derive the displacement of the car. This does not need a prior 3D map of the environment, but the computation is more costly. It does point cloud registration through Deep Learning and a RANSAC algorithm.

More info here: https://github.com/haixuanTao/IMFNet

Traffic Sign Recognition

• Traffic sign recognition is very important for our demonstration, but it has been difficult to find good weights to use to do it. Many package are really old and need to be ported to be compatible, using things such as yolov3 in darknet or lua. I chose to retrain weights on top of the latest Object Detection algorithm called yolov7. This gives dora developers a full example of Deep Learning from training to inference on dora.

More info here: https://github.com/haixuanTao/yolov7

Fixing Users frictions

• I have removed some manual command that was necessary to run dora drives to make it easier to use Dora and avoid bugs.
• Refactor python dependency to use conda

Adding a step-by-step tutorial

• I feel like there is many things to understand in dora and the documentation is very detailed but not easy to grasp. I'm writing a step-by-step guide to go from streaming a webcam, to running dora-drives. In which each step add a layer of complexity. It starts with the notion of nodes and operators, and will ends with prob. telemetry etc...

[phil-opp]

Dora Core

Zero-Copy Messaging

Message size can be quite big, so we want avoid copying it if possible. For this reason, we implemented the following changes:

• only serialize the metadata, then append the raw data
  • serialization requires copying the data to right offset, even if the serialization format does not require any processing
• redesign communication layer with an extra "prepare" step (instead of taking a Vec<u8> or &[u8] slice as argument)
  • the prepare function takes the metadata and the data size
  • it allocates a shared memory region of the requested size and copies in the metadata, the rest of the region is zeroed
  • the caller can then write the output data directly into the prepared shared memory region (e.g. from a camera or a disk)
  • after writing the data, the caller can send the message to subscribers
  • subscribers get a reference to the shared memory region -> they can read the data directly without intermediate copying
• limitations
  • Python still requires copying the data
    • zero-copy I/O is difficult to implement across the FFI boundary because of differences in ownership handling
    • performance-critical operators/nodes probably want to use a compiled language anyway, so removing this limitation has lower priority
  • Zero-copy outputs through shared library API require change to iceoryx Rust wrappers (PR at Add a reference-counted version of SampleMut eclipse-iceoryx/iceoryx-rs#61)
  • Zenoh does not support zero-copy operations at all at the moment
    • we plan to use zenoh only for communications over the network, which requires copying the data anyway

Plans for v0.1 Release

• Finish implementation of zero-copy messaging
  • Settle on the API design of the communication layer crate
• Implement a basic command line interface
• Polishing (API docs, book, contribution guidelines)
• Implement automatic release creation on CI