EFS Servo CAN Adopter

Owned by Hardy Yu
Last updated: 2024-11-08
3 min read

Background

This is an EFS & EE collaboration project, EE makes the board, and EFS writes the firmware for it. The final application of this Servo CAN adopter board is to control the flap wings, elevators, and rudders on a fixed-wing aircraft. To make that happen, EFS needs to work on firmware that converts the CAN servo control command transmitted from the flight controller to the PWM signal that servo motors understand.

ย 

The development of this project takes place on three different platforms:

  1. STM32 L5 Nucleo board - https://os.mbed.com/platforms/ST-Nucleo-L552ZE-Q/

  2. Single Servo Module - Single Servo Driver

  3. 6s Servo Module - 6S Servo Module Rev 1

The single servo module has the same CAN circuit and the same STM chip installed as the ones on the 6s Servo Module. So there will be a large overlap on the firmware of the two. 6s Servo Module has additional facilities for voltage sensing and more Neopixel LEDs.

Nucleo L5 was mainly used for the project prototype before the PCB boards were ready. This is also the first platform that we got fully working firmware logic. The big difference between the STM32 L5 and STM32 L4 (the MCU used on the PCBs) is that they support slightly different versions of CAN. STM32 L5 uses CANFD which is a newer CAN protocol allowing a faster rate of CAN message transactions. Whereas, STM32 L4 uses normal CAN that is sufficient for running DroneCAN.

ย 

The branch that has a functioning Servo CAN firmware: GitHub - UWARG/efs-can-servo at cleaner_repo

CAN Transmit Logic on Nucleo L5

X_Hz Frequency Task: This is the task that runs at a certain frequency in our program. This type of task can send the node or servo status. The message you want to send will be added to a TX queue instead of transmitted right away. Due to the nature of the CAN protocol, one node is only allowed to transmit a message when the bus is idle.

Main Loop: We call processCanardTxQueue to attempt a transmission. If the CAN bus is busy, that is fine. We can try again in the next iteration. The message will be sent to the CAN bus when the transmission succeeds.

CAN Receive Logic on Nucleo L5

CAN Filter: This is the identifier filter for the message on the CAN bus. It examines the identifier of every CAN message it receives and rejects the message that violates the configuration. The filter can be configured by changing the fields in FDCAN_FiltertypeDef.

FDCAN NORMAL MODE in STM32

FIFO Callback: This overrides the STM32 HAL callback functions and is triggered when a valid CAN message is captured.

Should Accept & On Reception: These are the functions passed to a Canard instance when it is created. should_accept is another filter for the message on their DroneCAN data type. on_reception takes the custom action to handle the received DroneCAN message.

CAN Circuit

This is how you want to set up the circuit to test your CAN node firmware with a Nucleo board. Using a PCB can be easier because they have the CAN transceiver circuit on board.

Ardupilot Configuration

Ardupilot is the firmware running on the Pixhawk. Ardupilot can be configured using Mission Planner software. Ardupilot allows very specific configurations to the CAN port and flight controller software behaviour. You can follow the steps below to configure the CAN port.

  1. Connect Pixhawk to mission planner: https://ardupilot.org/planner/docs/common-connect-mission-planner-autopilot.html

  2. Go to the Config tab, open Full Parameter List, and search for the CAN-related Parameter you are interested in.

    1. CAN enable, bitrate setting - https://ardupilot.org/copter/docs/common-canbus-setup-advanced.html

    2. Enable Servo control over CAN - https://ardupilot.org/plane/docs/parameters.html#can-d1-uc-srv-bm

  3. Control Servo over Mission Planner - https://ardupilot.org/copter/docs/common-servo.html

Sources:

DroneCAN

libcanard/examples/ESCNode/esc_node.c at master ยท dronecan/libcanard

CAN - Controller Area Network


Ideas for Firmware Improvement

  1. Shorten the ISR time. The time spent in each ISR when processing RX messages is very long. This can hurt our firmware performance as we all know the best practice when designing firmware is to keep the interrupt callback short and sweet. In the future, we might be able to add a rx message queue. The interrupt is only responsible for adding the received message to a queue. And then we process the message in the main loop.

  2. Adding CAN bitrate sensing feature on the firmware. Currently, the bitrate if fixed once the firmware is flashed. If the bitrate on the pixhawk is changed, then our can node wonโ€™t respond to flight controller. It could be a cool feature if our board senses the bitrate on the line so we wonโ€™t need to update the firmware every time when the bitrate is changed on the pixhawk.

ย 

ย