CAN Lighting Board Firmware

Owned by Mihir Gupta
Last updated: yesterday at 21:03 by Anthony Luo
3 min read

 

Introduction

This document describes CAN lighting board firmware. Check out the sub-pages and warg-internal documentation for more information.

Project Repo:

Sys Arch:

EE Top Level: Lighting Boards

POC

  • @Anthony Luo Software architecture & Board firmware

  • @Folarin Fatola LED Drivers, Lighting Control, & 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

Achieved using REV3 lighting boards

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

To be achieved using REV4 lighting boards

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

This probably includes at least another spin of a special central control node. That’s not so bad because we could have one node on each warg drone and then all the warg drones can have lights that sync with each other. pretty hype.

Code cleanup & optimization. More DMA. More Special shadow register magic. voodoo….etc.
Lighting Control board state reporting & logging?
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: GitHub - UWARG/efs-can-lighting: Firmware for WARG custom lighting board, communicate to Arudupilot over CAN bus..

Background

After conduction some research, we found that Ardupilot is capable of supporting LED DroneCAN peripherals DroneCAN Setup — Copter documentation. 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.

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

Contributors

  • @Folarin Fatola

  • @Mihir Gupta