ZeroPilot CAN

Description

The purpose of this task is to integrate existing drivers and peripherals to ZeroPilot. This project involves the following components:

Setting up DroneCAN (CAN 2.0) on the L5 boards.
- At the moment, the L5 boards run CAN FD. DroneCAN is better as it is used in existing peripherals
Create the architecture for this component.
- How peripherals will be added to communicate with the master node
Setting up the master node
- How peripherals will be initialized
  - Unique identifier
- Communication with specific peripherals

Background

CAN is a communication protocol that allows communication between multiple devices. You can find a super cool overview of using CAN with STM32 here.

Here’s a diagram to better show how the CAN bus will communicate with the sensors.

Architecture

This project can be thought of as the intermediary between peripherals and ZeroPilot. Note that CANBUS is abstracted away, so ZeroPilot itself does not know about CAN. When ZeroPilot asks for data from the sensors, that request is actually being sent to CANBUS, which then calls the hardware drivers for the sensor. A diagram has been attached below.

Do note that we do not have to worry about the peripheral boards as they have already been interfaced. We need to interface the CAN driver that ZP will use. With that, we will need to develop a component (that exists on the ZP board) that can complete the “master node” tasks. Although CAN is supposed to be decentralized, there exists a “central” component that monitors peripherals. This will be the master node. Note this is a consequence of using DroneCAN. CAN is definitely multi-master, but since DroneCAN is meant for a drone to interact with peripherals, it ends up having a node that performs more master-like functions that the other nodes. This is what we mean by “master node.”

Dynamic Node Allocation

https://dronecan.github.io/Specification/6._Application_level_functions/

Definitions

Allocator = Master

Allocatee = Peripheral Sensor

Rules of Co-existence of Static and Dynamic Nodes

While it is not recommended to mix both static nodes (nodes that aren’t dynamically allocated) and dynamic nodes, if it is required the following rules sounds be considered for the co-existence of static and dynamic nodes

It is safe to connect dynamic nodes to the bus at any time.
A static node can be connected to the bus if the allocator (allocators) is (are) already aware of them, i.e. these static nodes are already in the allocation table.
A new static node (i.e. a node that does not meet the above condition) can be connected to the bus only if:
1. New dynamic allocations are not happening at the moment.
2. The allocators are capable of serving new allocations.