Introduction
This document describes CAN lighting board firmware. Check out the sub-pages and warg-internal documentation for more information.
POC
Anthony Luo Software architecture & board firmware
Folarin Fatola LED Drivers & Board firmware
Nick Armstrong CAN Drivers, Ardupilot Communication, & Board Firmware
Architecture
See Central LED control architecture and Single-Board LED Control for more detailed description. At a high level, there are 3 layers of control.
System level control is dictated by ardupilot (+ the pilot).
Board level control is handled by the primary controller.
LED level control is provided by each boards MCU.
This allows us to break our system into a few categories:
LED Driver
Board Lighting Controller
Central System Lighting Controller + Ardupilot Communications
Note that the boards will set different LED’s for each command domain depending on the drone state. Certain drone states will also enable certain command domains immediately (i.e.: landing lights).
Milestones
These are very brief. Who knows what we do with them.
M1 - Basic Functionality - F24 EOT
LED Control
- LED Boards light up & are controllable colour.
- Individual LED’s are controllable via Software.
- Controllable LED brightness scaling
Board Control
- Synchronization between all board-LED’s possible (i.e. fade all together)
- Strobe functionality achieved (either main WHILE loop or timer interrupts)
- Receive CAN communications & set colour appropriately.
- Basic LED command domains
Central Control
- CAN Communication with ardupilot possible
- Communication (any packet) between LED boards possible (can be on unique bus)
- Set colour and/or brightness over CAN (can be on unique bus)
- Enable command domain over CAN (i.e. turn strobe on/off).
- If possible - turn strobe ON when we receive ardupilot messages, otherwise turn it off.
M2 - “Advanced” Lighting Control - Ideally ready for COMP
LED Control
- State reporting
- HSL/HEX conversions available
Board Control
- Understand / retain position of board on drone
- State reporting
- Receive SYNC messages & re-synchronize to Central Controller
- Receives “flight / ground / landing / emerg / off” flight states
- State machine for flight / ground / landing / off, including standard LED configurations for each domain in each state.
- Emerg search light functionality if NO can message’s received after timeout.
Central Control
- Understand ardupilot messages & determine drone state.
- Send out drone state messages.
- Report derived flight state & command domain states to ardupilot
Integration level
- When first powered on, LED’s go into “sleep” state (slow breathing)
- When CAN from ardupilot received, “wake up” and start lighting control.
- If ardupilot messages DROP OUT, but power maintained, go emerg.
- Brake lights work (Rapid blinking RED when slowing down)
- NAV lights work (relative to orientation of the drone)
- Turn ORANGE when the drone is moving
- Landing lights work (Turn on when the drone is close to the ground)
- Beacon light turns on when LV is applied
- Strobe light turns on when HV is applied
- Stretch: strobe lights dim/different lights turn on when in different flight states (landing, ground, off)
- i.e.: landing stage, strobe lights still send sideways, but dimmer / less
- ground stage: strobe lights only blink on inside downards facing LED’s, at a low brightness, to prevent eye damage!
M3 - Stretch Goals for future
- Central Control failover (when one central controller fails, another node is able to pick up the task, round robin until all nodes fail)
- Wireless light sync between drones - strobe @ same time
- Central controller needs wifi/bluetooth/elrs/gps chip - anything to provide PPS sync
- Central Controller has light meter - auto-dims or auto-brights in certain conditions to prevent operator eye-damage
- i.e. strobe lights dim in ground mode at night to prevent glare, but will compensate in brightness when outside during the day to ensure visibility., etc.
OLD / archive
Introduction
The purpose of this document is to describe the plan for writing the firmware for the lighting board LED Board Rev 2. The board is planned to be used for competition drone for the AEAC 2025 competition Lighting Integration 2025.
The firmware for this project can be found in this Github repository: https://github.com/UWARG/efs-can-lighting.
Background
After conduction some research, we found that Ardupilot is capable of supporting LED DroneCAN peripherals https://ardupilot.org/copter/docs/common-uavcan-setup-advanced.html. We also found that DroneCAN can send a LightCommand message that can provide RGB data of the LED color.
Plan
The plan is to read and decode the LightCommand message and light up the LED’s based on that data in the messages.
Setup a Simple CAN Node
The goal of this step is to setup a simple CAN node that listens for the heartbeat message from Ardupilot.
Implement something similar to https://github.com/dronecan/libcanard/tree/master/examples/SimpleNode but compatible with STM32
Refer to the ESC node https://github.com/dronecan/libcanard/tree/master/examples/SimpleNode
Request and Receive a LightCommand Message
TODO: Add to this section of the plan
Parse LightCommand Message and Interpret Data
TODO: Add to this section of the plan
Set LED to Requested Color
TODO: Add to this section of the plan
0 Comments