Check out the Hardware

Open

Single-servo driver is one variation of the CAN servo project. It is meant to provide the CAN command translation and control to a single servo motor.

You can check out the end user guide to know how to work with this board: Single Servo Driver End User Manual

List of Features to be done

There are the following action items that need to be completed by the time of the start of W25.

Servo Controller Refactor

The servo control used to be implemented inside the main.c. This isn’t very nice since it makes the main.c file bulky and it brings confusion for people to configure it. This refactor is supposed to extract the servo control part of code out from main.c and wrap it into its own class.

The primary work has been done in this branch: GitHub - UWARG/efs-can-servo at cleanup-servo-controller

NeoPixel LED Support

The single servo driver board has three neopixel led on it. Firmware should be implemented to utilize the LED for better status indication. The neopixel led control code could be ported from: GitHub - UWARG/efs-can-lighting: Firmware for WARG custom lighting board, communicate to Arudupilot over CAN bus.

Dynamic Node Allocation

In the CAN protocol, each of the CAN nodes has its own unique identification number. The node ID is used for showing the message source and specifying the destination of a message during communication. Currently, the node ID is hard-coded in the code base, so we have to manually keep track of the node ID to make the no two nodes are using the same ID. This is why we need dynamic node allocation.

There is an example in which used dynamic node allocation: libcanard/examples/ESCNode/esc_node.c at master · dronecan/libcanard

Folder Structure Refactor

The new folder structure for the single servo driver, I imagine, is supposed to look somehow like this. The idea is to make the software modular to enhance better code reusability and readability.