Architecture Meeting 1

Owned by Anthony Luo, created
Last updated: 2022-11-02 by Neha Srivastava
4 min read

Purpose

  • The purpose of this initial architecture meeting is to iron out various blockers that may be faced by subteams for development.

  • This meeting will aim to create a source of truth for the entire team regarding how different modules interface with each other, and how the entire project will be built together.

Priorities

  1. Determine relevant actuators, motors, and general placement in order to provide more insight to Mechanical team as the frame is being designed

  2. Determine how different components between EFS and CV communicate with one another, including protocol and format. This includes:

    1. ZP3 - Sensors

    2. ZP3 - Ground

    3. ZP3 - Jetson

    4. Antenna - Ground Station

General

  • cameras

  • video transmission

  •  

Mechanical subsys:

  • Airframe motor / battery / prop / servo

  • tracking antenna

  • Tuning rig

CV Reqs

  • Data telem (airside, gs)

  • Path planning (gs)

  • Autonomous Landing (airside)

  • groundstation

Firmware Reqs

  • flight computer

    • actually flying drone

    • auto landing/takeoff

    • battery management

    • simple path planning

    • telemetry to ground, telemetry to air (jetson - zp)

    • position (gps/imu)

  • Peripherals

    • rfd900 ↔︎ RC Link

    • gps

    • imu

    • airspeed

    • optical flow

    • time of flight

    • sd card

    •  

  • tracking antennas (gs)

EE Reqs

  • ZP3 primary & interface

  • Power Distribution Board (COTS)

  • wiring harness (battery connectors & power distribution)

  • LED’s

Tuning Rig

  • has to exist for the competition frame.

  • able to isolate 1 axis at a time.

  • nice to have: multiple axis (pitch/roll).

  • idiot proof.

  • rotation around CG.

  • Does not have to fit in the bay? → probably will not @Conall Kingshott

Imacs

Telemetry & Command/Control

  • uplink to and from drone done on rfd900 (for rc-link & telemetry).

  • Zp ↔︎ Rfd900

    • distributes to:

    • jetson

      • from ground: nothing. If a waypoint is selected from ground, it will go to ZP.

      • To ground: CV program status

        • Hover: Locations of interest (maybe path planning e.g. waypoints?)

        • Landing: Landing pad location (given a single time to ZP so that it can initiate landing sequence, Jetson has no control after)

    • ZP from ground: next waypoint, killswitch, rc link

    • Zp to ground: altitude, groundspeed, battery levels, vertical speed, heading, lat, lon, motor outputs, throttle percentages, motor draw? GPS Position RC Link status, logging data

  • Tracking antennas x2, w/nucleos.

  •  

Video Link

  • 1.3ghz vtx

 

Airframe

comms

  • rfd900 → ground

    • UART to ZP

    • PPM to ZP

  • ZP ↔︎ Jetson

    • UART between

    • The idea is drone hover and hands the control over to cv and cv makes gives GPS data back to ZP and makes zp drive the drone to that GPS location. Then ZP initializes the landing sequence.

    •  

Sensors & Peripherals

  • Vn-300 → zp

    • 2 antennas very far apart

    • center around COM

    • aligned with axis

    • Comms to ZP over UART

  • Mateksys OFS → zp

    • pointed downard, no need to be centered

    • not at the very bottom (prevent bottom out)

    • Uart or SPI?

  • NEO M.8 GPS→ zp

    • horizontal, pointing up. RF Transparency towards sky

    • UART/SPI - using SPI

  • BMX160 IMU → zp

    • center around COM

    • aligned with axis

    • I2C

  • TBS airspeed → zp

    • in clean air facing forwards

    • SPI

 

  • airspeed → px5

    • in clean air facing forwards

    • UART

  • NEO M.8 GPS → px5

    • horizontal, pointing up. RF Transparency towards sky

    • UART

  • Mateksys OFS → px5

    • pointed downards, not centered.

    • not at the very bottom (prevent bottom out)

  • SD Card

    • SPI for nucleo

    • SDMMC For ZP3

 

  • pilot cam → splitter

    • facing forward

    • unobstructed view

    • maybe have it on adjustable tilt?

  • pilot cam → splitter

    • pointed downwards

  • pilot cam splitter → vtx

    • vtx takes 12 V

  • picam → jetson

    • centered wrt landing gear.

    • don’t break the camera in a crash.

    • facing downwards (otherwise on an axis).

  • Arm - Disarm button

    • away from props

    • → zp.

--

Mechanical Requirements

Actuators

Motors: ( 5 )

  • quad 4

    • same as vanny (~ 40A each)

    • same ESC’s as vanny (51A rated)

    • same props as vanny (17x4.5)

  • 1 push

    • 16*8 APC prop

    • ~ 100A burst, ~ 40-50 cruise?

  • running 6s.

Servos ( 8 ) 5V

  • 2 rudder

  • 1-2 for elevator

  • 2 per aileron = 4

  • cabin door actuator

Power Architecture

  • VTX takes 12V

  • Servos 5V + 5-10A?

  • Jetson 9-14V + 1.667A at 12V (20W) according to specs

  • PX5 5V

  • ZP 7V minimum (2W)

  • Custom 12-5V conversion?

  • Two separate 5V buses

    • Servos (noisy)

    • Sensors

Batteries

  • 6S:

    • With a step down to 5V

      • servos & other noisy things

  • 3S:

    • With a step down to 5V

      • sensors & other stuff

Wiring

  • try to make harness?

 

Airside Comms

  • System states:

    • Travel to waypoint (close to waypoint, wakes Jetson)

      • ZP autopilot

      • CV groundside ONLY

    • Search for landing pad

      • CV airside ONLY

        • Receives position, altitude, orientation from ZP

        • Receives request from ZP

        • Gives relative instructions to ZP (3m north, 1m west, 2m up)

        • Ability to abort movement??? (I saw something, freeze!)

      • ZP autopilot

      • Slow feedback loop

    • Landing at pad

      • ZP only

  • ZP

    • needs waypoint list (flight / travel phase)

    • needs size of waypoint list

    • once airside finds landing pad, needs boolean flag to start landing stage

    • needs relative landing suggestions. (search & landing)

  • Waypoint list:

    • Provided by CV groundside

    • Waypoint 1, 2, 3, 4, etc.

      • Waypoint:

        • GPS coordinate (so the waypoint list is a list of GPS coordinates).

  • Groundside

    • form of waypoints that competition has given us. Click each waypoint based on what competition is. Send list of waypoints to the drone.

    • autopilot or not & override

    • waypoints only.

      • needs way to generate the waypoints to fly to and give them to ZP in real time.

      • what about diversion for task 1?

      • waypoint ID=0 is current aircraft location.

        • every other waypoint follows from waypoint ID=0.

        • send new flight plan each time.

          • Old flight plan discarded.

    • Zeropilot handles transition → will request jetson to give control.

  • Airside

    • also handles search.

    • goes through geolocation program and tells you where to land ?

    • relative motion only.

      • relative translational movement

      • request for altitude.

    • Geolocation

      • altitude, orientation

        • alt from px5 baroms.

        • or alt from sensors?

    • Request - response format.

      • different message formats? How deal with structs / messages

    • gets position data from ZP.

      • zp send constant

    • makes unique request & waits for response.

Â