2023-09-26 COTS clarifications and priorities

Priorities

  1. Gemini

  2. CAN sensor board & RTK support

  3. other random projects?

    1. lighting control

    2. OSD

    3. support for individual sensors

 

Gemini - End of Fall Term

  • Most important thing

  • First board by end of Oct

  • all control and telem links will run through this for forseeable future

  • ELRS

    • express LRS

    • wireless transmission protocol

    • really good long range performance

    • high speed control

    • open source

    • started as a racing control link

    • added support for mavlink, support for serial uart link

  • gemini is an addition to elrs which transmits the same packet over 2 different frequencies

  • helps with avoiding interference and lets us have more control with antenna setups

  • fw exists as open source

  • things we can add

    • more than 2 frequencies

    • better control

  • we want our controller (tx16) to work with gemini

    • Gemini control board is on tracking antenna

    • tx16 uses crsf (crossfire)

    • 400k baudrate

    • controller communicates with 420k baud

    • figure out how to flash to gemini and output our crsf at the correct baudrate

    • 2 wireless links

      • tx16 pairs with elrs rx over wireless elrs using the internal elrs module of the tx16

      • gemini tx on the tracking antenna to the gemini rx on the drone

    • we need to bridge the elrs rx to the gemini groundside board using UART

    • Tasks

      • understanding the transmission modes of elrs

      • figuring out what baudrates are available

      • configuring the baudrate we choose and flash

    • more features

      • better MAVLINK streaming support

        • currently it does bytes in bytes out

        • bandwidth at lower frequencies isnt enough for both control and telem with bytes in bytes out

      • integrating it into ZP ecosystem

      • attaching a GPS to pwm recievers to get location

      • SBUS and pwm outputs

RTK GPS - By end of Comp have it flight tested

  • ardupilot has a list of supported GPS that communicate using NMEA protocol

  • we can potentially consider this cycle if its been proven flight tested by november, but thats unlikely

  • doing RTK on supported GPS costs a lot

  • only 5 or 6 GPS that ardu supports and they are expensive

  • RTK capable GPS are cheaper on sparkfun and are better

  • Figure out what GPS we could use and how theyre better than what we have right now,

    • RTK

    • GNSS vs GPS

    • how many antenna

  • RTK uses base stations to get very high accuracy GPS readings

  • the reason GPS isnt very accurate is because the ionosphere changes, so using a base station lets you find ionosphere corrections and you can apply it to drone location

  • GPS correction data formats - check in mavlink?

  • ardupilot uses a particular gps correction format

  • submit corrections over mavlink and ardupilot driver would unpack that and send it to the RTK capable GPS

  • driver basically converts correction data from MAVLINk to whatever format the GPS uses

  • tasks

    • research what all these terms mean

      • what can be used as a base station

      • make an arch doc

    • research what family of GPS to use (use the same protocol)

      • cheap stuff, expensive stuff,

      • long term what family do we want to invest our development time into

      • feel out what the space is like

    • get a gps

    • write ardupilot snf mission planner driver for it

  • https://navspark.mybigcommerce.com/ns-hp-gn5-px1125r-l1-l5-rtk-breakout-board/

CAN sensor board - Summary Of findings by feb/march (using nucleo and wires) (wait for arch meeting)

  • family of boards and sensors

  • lots of off the shelf sensors are ugly and use protocols like i2c and uart and spi that cant be easily networked

  • http://www.mateksys.com/?portfolio=can-l431

  • take a small chip like an f0 that can interface with the sensor and connect to a CAN network

  • still in arch phase

  • still up in air exactly

    • one board is sensor + f0

    • on board has a bunch of sensors on it + a beefier chip

      • OFS

      • range finder

  • figure out

    • need to figure out what chip can do CAN,

    • what sensors we want to support,

      • dont support sensors that are near EOL

    • how to communicate with ardu using CAN

      • dronecan has support but others might be better

      • how to pack sensor data together

      • how to send sensor data that isnt necessarily supported by ardu

        • might require some ardupilot driver

    • coding

      • write generic driver for the CAN side

      • create a collection of existing sensor drivers that we either already have or will write

      • failure scenarios and protections

lighting for Ardu POC on ground by end of fall term)

  • kinds of lights

    • strobe lights

    • nav lights

    • taxi lights

    • beacon

  • DJI drones

    • rgb on all 4 sides

    • change to indicate state, direction etc

  • software support for changing

  • might be a separate board with f0 to control that

  • might be an ardupilot driver

  • ardu doesnt support mixed lighting modes

  • how we should light our aircraft to make it safe at night

    • look up the law

    • look up common methods and standards used in cots drones

  • degrees of visibility when putting a light on the drone

  • all for exterior ^

  • interior

    • emergency lighting in airplanes

    • car door lights

    • make it so that in ardupilot, some action will trigger lights,

      • when you land turn off external and turn on cabin lights

      • dim cabin lights

    • realism

  • hw

    • select a part and ee makes a custom board

    • buy a cots board

    • do some research on neopixels vs rgb vs whatever and ask for input

OSD (summary of findings by feb/march)

  • exists between camera and tx

  • overlays mavlink information onto the video feed

  • EE had trouble sourcing a chip for OSD

  • potentially works with ST chip

  • research and proof of concept project

    • if it goes well, ask EE to help and make this a formal project

    •  

Support for individual sensors (POC of rplidar A1 by early dec)

  • lots of sensors dont have support but are cheaper than ones that do

  • ties in with CAN sensor board

  • sensors

    • RPLidar A1 and A2

    • any lidar that they have at robohub

Â