Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Attendees

Flight Test

Embedded Flight Software

Autonomy

Problem Statement:

Most drones or arial vehicles, all have a navigation and position lights that have colors and certain sequences that allow other pilots to identify the aircraft; orientation, visibility especially in nighttime operation. Certain lights must be on the time due to regulation.

  • Realism points for replicating this on our drone.

  • Legal requirement for flying at night/civil twilight

Past implementations:

ICARUS

LED strips taped to cable channels.

  • looks bad (white strip on entirely black drone)

  • Zip tied on

  • not very bright

  • tied to one relay, poor control of lights

Previous drones have not had lights other than Icarus.

Proposed Solution:

Constraints:

  • Visible at night and daytime (very bright)

  • Controllable through Ardupilot software

    • Autonomously without pilot input

  • Well integrated

  • Each light must be visible from 120 degrees,

    need to go on ends of motor mounts and below/above arms?

  • 4 LEDs (red, potentially blinking) one on each corner is the absolute minimum control requirement.

    • realism for airplane:

      • white strobe light (pulsing?), visible 360

      • beacon light, visible from 360 around. red.

      • red on left, green on right, white on BACK. static.

        • ‘don’t need white on back probably'

  • maybe: green, red, yellow, one on each corner, based on movement.

  • yellow on back motors while slowing? not requirement for realism…

  • green LEDs on PAX aboard - if still conops req

  • also need to decide reflectors - these can be picked in tandem with LEDs, as adding reflectors may eliminate the need for a stronger LED, etc.

  • even numbers are good for neopixels with pixhawk

    • note that pixhawk is not required. can be controlled with whatever

    • lights controlled through ardupilot …. but maybe EFS can do it better

    • uses serial protocol

    • lua scripts… suboptimal… ?

  • EE global constraint should be weight

    • save weight instead of add more brightness (if the tradeoff is reasonable)

Existing Solutions that work with Ardupilot:

  1. Existing I2C, Neopixel

  2. GPIO, PWM - Use PWM/relay sequence to toggle light off.

Decision Matrix:

Pros

Cons

Neopixel

WS2812B

  • Boards of variety of sizes

  • Use sets of lights and route cables to Pixhawk channels

    • Each set needs power (external)

      • 45mA Total Max

  • can change colours.

  • More Expensive

  • “Fixed” Assemblies

  • need to be connected to pixhawk?

Striplights

  • Cheaper overall

    • “Less Smart”

  • Easier to cut up

  • Custom control and power

    • Extra level of complexity

Potentially ruling out neopixels

  • we don’t need to change colour

  • having too many connected to pixhawk → not great

Suitable LED strip lights should be chosen via similar setup to Decision: Type of Rangefinder for Obstacle Detection page. Can include neopixels if desired, but please compare individual part numbers.

Project Owner Availability:

Neel Patel : 10-15h hours a week

Parker Lawrence-Valeriani 5-10h a week - better idea of availability after midterms.

Agreed upon timelines:

  1. Architecture plans for next week. (research and decisions)

  2. Order components end of October.

  3. Full working prototype for end of term.

  • No labels