ZP3 Architecture Research - FW

ZeroPilot will have mounting holes that can support anti-vibration mounts

A way to mound the board securely is required, and reducing vibration will protect the components onboard

• foam/rubber lining inside the case?

• anti-vibration standoffs.

ZeroPilot will have an LED driver

Allow us to use navlights, strobes, or whatever is appropriate for the given mission

• probably rgb? Makes easier to configure…(Plus you just choose which colour to plug in).

• should just be GPIO or 5v rails.

• Benefits for interfacing with zp? → we can make visual indicators (not sure if these would even be visible during daytime tbh)

• Benefits for interfacing to 5v rail → less things to go wrong?

ZeroPilot must accept tele-op input

Allows pilot to control aircraft

ZeroPilot shall have a DataLink to ground

Allows pilot to see information such as gps location and send autopilot commands

• should be mounted away from ZP board itself (more mounting options to extend DL range).

• * slightly * less critical, could be implemented as FW->CV->Gnd, or as CV->FW->Gnd.

  • Sending from CV Might be the lower-cost solution (COTS solutions)

  • Sending from FW Might be easier bc flight-related information could be relayed without CV passthrough.

• LoRa devices run off of uart, as do XBees. Doesnt' change pinout.

  • Xbees cheaper && longer range. Code already exists. @Aaditya Chaudhary might have more info?

The board will have user power input protection

Can save the board in case of user error such as reversing polarity or attaching incorrect voltage

Depends on power architecture

ZeroPilot must be able to communicate with other boards on the aircraft

Communication with the computer vision computer and the ground station will depend on this

 Dhruv Upadhyay

need to spec architecture

• air-air communications on one drone should happen through a wired connection (simplicity, reliability, interference to others).

• air-air communications between drones should happen on a separate frequency (could be higher though since there’s less stuff in the air).

ZeroPilot shall have an audible buzzer

Debugging, clarity of operation

 Christopher Chung

• Should at minimum be able to beep one tone (one gpio)

• Consideration for having multiple tones?

ZeroPilot will have sensor breakouts

External sensors that have not yet been identified may be desirable.

• i2c can handle up to 128 devices, and most sensors have i2c versions.

• spi can also have up to 128 devices, so we should be * mostly * covered.

• Can only get one pair of devices on UART traditionally

ZeroPilot must have a method to physically Arm/Disarm the aircraft

For safety while working on/around the drone.

For clarity of drone operation (ie armed = going to fly).

• Prevent accidentally triggering arm/disarmed states?

• How do we handle restarting the system in the event of hardfaults?

ZeroPilot shall have debugging LED’s of multiple colours

For status display when debugging

Could be RGB or multiple different LEDs (or both?)

• individual colour led’s are 1 pin (gpio), RGB led’s are 3 pin (and require pwm signals to mix properly - but can be driven on gpio).

• Could be worth to investigate an easily mountable debug shield that has buttons & lights / displays.

  • would be another separate EE project that could be brought up separately? In the meantime could just use serial output + a few onboard lights.

ZeroPilot will have Non-Volatile Data Storage

Having data storage allows logging of flight information for analysis

It should be accessible by devices other than just the MCU ← why?

ZeroPilot must be able to communicate with a GPS

Legal requirement

 Christopher Chung

ZeroPilot must have the ability to monitor the battery

Need some way to monitor battery health while in the air to prevent falling out of the sky?

The board shall have the option to use locking, non-reversible connectors and simple jumpers

Non-locking connectors have a habit of falling out of the board, and are easy to plug in in the wrong order. Jumpers make it easier to quickly test components without spending hours crimping connectors.

Perhaps connectors that are same form factor for headers and for locking, so can be soldered on depending on iteration of board.

Should not prevent easy access on breakout version of board

ZeroPilot will have power outputs for peripheral devices

Power for peripherals (5v, 3.3v) power should exist.

Power output protection (e.g. ESD protection) should be considered

ZeroPilot will be possible to place into a case

Putting the board in a case protects it from shorting components and makes it easier to handle

• Do ports need to be accessible while it’s cased?

  • would you have extension cables coming out of the box anyways? or is there a world you want to plug/unlpug things while it is cased?

• Is there a concern for stuff overheating? / shorting while we shove it inside the case tightly

• ZP should be able to be put into the case securely, which should then be able to be mounted to the drone securely.

ZeroPilot will have one microcontroller

Reduces complexity, and there is no need for two really (chance of failure of any given chip is still the same)

 Dhruv Upadhyay

• The chance of the “core” MCU failing will not be diminished by adding another MCU onboard. So, adding a second MCU basically means that if the MCU was going to fail, it doesn’t matter that there are other chips on board.

• Concerns for pinouts.

ZeroPilot will have a debugging output data pipe

Super helpful in debugging

(e.g. arduino serial)

• should exist indep of a debug shield?

  • allows us to log the serial output using a small arduino on the drone if we need to.

  • BUT also means extra breakouts

ZeroPilot will have an IMU

The IMU tells the aircraft it’s orientation in space, and without it cannot fly

This could be external or internal

• if we do not have an option to use a vn-300 on testing drones, it would be nice to have a imu on-board. Reduced the chances of a flight-critical component having wires unplugged and also means that the orientation of the IMU will never be questioned.

  • onboard IMU’s probably going to be more popular to get something like an MPU9250 (commonly used for arduinos) instead of bmx160… but mpu9250 is eol? https://invensense.tdk.com/wp-content/uploads/2018/10/AN-000146-v2.0-TDK_Migration_MPU_9250toICM-20948.pdf

• Could (potentially) have 2 imu’s to get better SF data, one internal and then an external one or just … idk a vn300…

  • plus if there’s i2c/spi broken out adding on an imu externally that we’ve written a driver for is not hard.

ZeroPilot will have debugging buttons

This will provide an easy way to test/configure the drone

Must be removable for flight (e.g. Debug Shield).

Should have a locking connector so that we don’t worry about it getting loose while testing?

• Debug shield could also have things like LCD crystal display for real-time readouts, led’s/fancier speakers.

• Could have basically it’s own chip and then 2 wire communication with ZP.

• Could have extra logging capabilities.

ZeroPilot will have at least 12 Motor/Servo/Actuator outputs

• octacopter - 8

• gimbal - 3

• actuator - ?

maybe put in as many as we can reasonably get?