In order to support advanced lighting modes such as:

• strobe

• nav lights

• beacon

• taxi / landing / approach lights

• breathing “standy/decorative” lights

One extra CAN node (This does not have to be an LED board, it can be any CAN-enabled peripheral) will serve as a master controller on the CAN bus. This node will interpret the state of the drone over telemetry or custom lighting commands, offer synchronization messages, and command external LED boards to perform certain activities. Should this node go down (3+ sync frames missing), the next highest ID will assume control of synchronization & command (everyone can see ardupilot CAN messages). This continues until no nodes are available. If all nodes go down, it is reasonably expected that lights will default to < some error state >. If ardupilot CAN messages stop for any reason, it is expected that the LED’s will go to some < search pattern >

We choose to have this LED perform all of our actions for two reasons:

1. Defining & supporting our own CAN messages on our own firmware is pretty easy

2. It is easier to meet hard timing deadlines / requirements for synchronization, compared to using LUA scripts which make no such guarantees.

Lighting Control Messages

When desired, the central CAN node will send messages to request certain colours or patterns from all LED’s. The LED’s will be stored with enums to define their position static and relative to the drone. This means that you might expect the following series of messages:

• LED FRONT_LEFT, BACK_LEFT set COLOUR_RED

• LED FRONT_RIGHT, BACK_RIGHT set COLOUR_GREEN

• LED <ALL> strobe at EVERY_SECOND

and on braking / descent, you might expect:

• LED <ALL> flash_brake_lights

• LED <ALL> enable_landing_lights

Control Synchronization

Largely TBD, but the master node will attempt to synchronize the lighting of all nodes, such that effects of strobe should be synchronized. How we intend to do this over CAN is still tbd, but our wires are pretty short so it’s possible just to send SYNC frames every N hz and have internal timers on the ST side re-synchronize. It is expected that the lowest-rate pattern (beacon) is at 0.5hz (once every 2 seconds) when in-air, while the fastest-rate pattern (search/strobe) might operate at 100hz (strobe is 100hz for double blink, every 1.5s)

Lighting Control Patterns

• StaticColour: Set to a static colour

  • typically NAV lights

• Beacon: breathing RED light, visible all around to indicate drone is powered on.

  • Half outwards nodes breathe until takeoff, other half show original colour

    • TBD on how this is wired, depending on ee …..

    • Upon takeoff, these nodes will flash LOW RATE red.

  • 4 of 6 bottom LED’s breathe red until take-off. This needs to be bright enough to be visible above the

    • other 2 show nav colour

    • upon takeoff, only 2 bottom lights flash red (central)

• Strobe: 2 pulses bright white (255, 255, 255), 100ms on, 100ms off (tbd). On only above 10m AGL (central node controlled).

  • 2 of 6 bottom LED’s will flash, returning to the original colour when not set to white

    • It would be nice to make these the two OUTER LED’s, but then we’ll need markings on which side is installed facing outwards

  • all outwards LED’s will flash, returning to original colour when not set to white

• Landing / Approach: four bottom facing LED’s bright white, beacon operation is now shared with nav lights & strobe.

  • When enabled, strobe / bcn brightness reduced to improve operator visibility.

• Decorative: If powered up and no can messages are received from ardu

  • Assume we’re just powered up standalone, go to a nice breathing colour cycle, avoiding colours like red / green / yellow that might indicate flight status.

  • Potentially cycle led’s of different part of the drone indep of each other (i.e. led’s across from each other) to truly indicate “asleep”

• Search: If CAN messages were received and are no longer viewable.

  • SCREAM