🍞 Acronyms & Links

[The Drone] - The drone as a whole, including electronic components and integrated software systems.

[(the) Airframe] - Fuselage, wings, control surfaces, & mechanical components used to connect them

[ZPSW] - ZeroPilot Software ZeroPilot 3.0 Architecture

[ZPHW] - ZeroPilot Hardware

[IMU] - Inertial Measurement Unit

[GPS] - Global Positioning System (device to capture GPS data)

[ESC] - Electronic Speed Controller, Motor Controller

[GS] - Groundstation

[Tracking Antenna][Antenna Tower][Tracking Tower] - all tracking antenna systems.

[T_Telem] - telemetry tracking tower

[T_VRX] - video receive tracking tower

[GSPC] - groundstation PC

[GS_SW] - groundstation software

[GUI] - groundstation gui (software gui for user).

[OSD] - on screen display (attitude information overlayed over video feed

[MUX] - Video Mux

[rfd900x] - RFDesign RFD900x Modem (singular)https://uwarg-docs.atlassian.net/l/cp/LPn8hwCv

[Competition Design Outline] [CDO]Competition Design Outline

[Competition Requirements] [CR]Competition Requirements

[VN-300] [VectorNav VN-300] 2023-03-26 - VN-300 Rugged Harness

📐 Architecture

The architecture of a drone can be found in the [Competition Design Outline]. <# iterations> iterations of the drone will be created, at <#milestones>. <# final copies> of the drone will be created in “competition spec”. Our system will meet the requirements in [Competition Requirements].

Our general architecture has the following hardware elements:

Airside Components:

Power

• PDB

• 4x APD 120A ESC’s

• 4x T-Motor 160KV MN6007II Motors

Propulsion

• 4x T-Motor MF2211

Compute

Mandatory:

• Pixhawk PX5 or PX6

  • http://www.holybro.com/product/pixhawk-5x/

  • Pixhawk 6X,Pixhawk 6X (holybro.com)

Optional:

• Jetson TX2 + Carrier Board

  • NVIDIA Jetson TX2i: https://www.arrow.com/en/products/900-83489-0000-000/nvidia

  • Connect Tech Quasar carrier board: https://connecttech.com/product/quasar-carrier-nvidia-jetson-tx2/

• Custom STM Flight Board (Nucleo OR ZP3)

  • ZP3 Custom Hardware Specifications:

    • ZP3 MCU: STM32L562ZET6Q

    • Add ZP3 Interface: https://warg.365.altium.com/designs/14CBC2A9-7887-4911-B7F1-874B17856231

    • Add ZP3 Primary: https://warg.365.altium.com/designs/8E6687CB-1A15-4D5A-BEAD-9E45C5E56743

    • Add ZP3 Hardware Link: ZeroPilot 3.0 Hardware (ZP3HW)

Peripherals

Mandatory

• Optical Flow sensor (Hereflow Can)

• Rangefinder (Benewake TF-MINI S PLUS)

• LTE Hat + LTE Device

• 2.4ghz diversity RX

• 1.3ghz vtx

• 2x pilot camera

• vmux

• osd board

• cv camera

• 2x neo m9n gps (holybro flat version)

Optional

Groundside Components:

Control

Telemetry

Video

Optional Tracking Antennas

Airside Architecture

Now that we know what components are going on our drone, let’s talk about how they’re going to be laid out on the drone itself.

Airframe Design

Propulsion

lift, push, offsets, spacing?

Payload

Fuselage is main passenger compartment?

Avionics Mounting

How avionics will be mounted && standards for sensors

Landing Gear

Design, limitations, etc.

Airside Hardware Layout

Where everything airside is going to go

Compute

The Holybro PX_ system should be placed as close to the center of rotation of the drone as possible, offset in ONE axis only to allow for the installation of the VectorNav VN-300 module. There is an arrow on the top of the Pixhawk, which should point toward direction of forward flight. Keep in mind that wires need to be accessible from the “back” of the pixhawk (I/O & FMU Output banks), as well as from the side for USB debugging as well as retrieval of the SD Card.

There is no strict need to electrically isolate the system (the baseboard & cube are already protected), but it could be helpful to mount the system on vibration damped material (yellow sticky tack is good for this purpose).

Batteries & Power Distribution

Transmitters

Cameras & Related Peripherals

GPS Sensors

Peripheral Sensors

Optical flow sensors & rangefinders or lidars should be mounted at the bottom of the drone, in a sensor cluster without obstructions (clear or otherwise) in the fov of the devices.

It is mandatory to have at least 1 hereflow and 1 tfminis lidar module, the rest of the sensors are optional.

Airside Electrical Layout

Harnessing, wiring diagrams, etc.

General Wiring Guidelines

Power Architecture

The drone will run a 12S power system. The drone will be able to run on either 4 batteries or 6 both configurations at 12S. The power from the batteries will pass through a custom High Current Power Module board which will supply a clean 12V and 5V rail. The remaining battery current will pass through the PDB board which will supply directly battery voltage to the ESCs and motors. This PDB will also have a 5V and 12V rail.

Wiring

Connector Standardization

MT30s will be used as a quick connect in the 3-phase wires from the ESC at the entrance to the drone arms. This will allow the drone arms to easily be unplugged from the ESC and taken off. They are rated for 15A nominal and 30A peak which is more than the 14.05A drawn by the motor at 80% throttle.

Bullet connectors will be used for 3-phase connections at the motor to allow the polarity change or disconnecting of the motor to be fast and easy.

Groundside Architecture

Mandatory Hardware

Two RadioMaster TX16s Mk II Radios will be linked together using their trainer ports. One radio, serving as the “master”, will use a TBS Tracer system as a short relay to the RFD900x, connecting only a PPM or SBUS signal wire.

Any power that must be provided to the groundstation will use Turnigy 3s 4000mah nano-tech batteries. Any cooling fans will be noctua 40x10mm 5v 3 pin fans unless mech or ee requests otherwise.

Telemetry & Control

Telemetry will be provided via RFD900x, with the stock antennas mounted >20cm apart. There will be a USB cable which allows direct connection to the groundstation computer. There may need to be additional power supplied to the RFD900x to allow full power operation, and if such is the case it is possible to use XBEES in transparent serial mode instead of a USB cable, allowing the antenna to be moved further away. The RFD900 may require active cooling, so mech to add design that allows a fan to be attached (zipties are effective solutions).

Control will be provided using a TBS Tracer module, TX in the controller and RX outputting PPM or SBUS wired into the respective pin on the RFD900. There will be no downlink over TBS Tracer (i.e., no telemetry from the TBS Tracer). Wires from the rfd900 harness will be soldered directly to the TBS Tracer, providing power, signal, and gnd connections. It is important that the tracer and it’s antennas & wires are placed in a safe position where it cannot easily short and/or become disconnected or damaged.

Video

There will be 2 major components to the video system, one is the video relay and the other is the video receive devices. The video relay handles the transition between low frequency (1.3GHz) analog video into 5.8 GHz analog video. This video relay system will exist on a unique video relay tower, which houses the 1.3ghz antenna (singularity 1280), the 1.3ghz VRX, as well as the 5.8 GHz VTX and the respective antenna. Note that the VRX outputs video in an RCA format, and this will need to be spliced to solder pads or 2.54mm pitch pins on the VTX. The singularity 1280 must also be mounted so that the null zone is vertical.

If the 5.8 VTX were to be the Rush Tank Race II, then the antenna would be a u.fl terminated rush cherry w/long stem. If the 5.8 VTX were to be an AKK TS832, then the antenna would be an SMA terminated rush cherry w/stem. EE to provide clarity on whether or not adapters are needed. Both VTX will take signal from the video receiver, and share common VBatt & GND where VBatt is a 3S voltage. This VTX will be paired with the VRX, and can either be mounted on a tripod or a tall PVC pipe. This VTX may also require some degree of active cooling, consider how a fan may be mounted.

User endpoint Video Devices

All remaining VRX devices operate at 5.8 GHz, this includes:

• pilot FPV goggles

• FPV monitor

• 5.8 → USB receiver chain

Pilot FPV goggles are up to descrition of the pilot, and will be provided RHCP polarized stubs or stems depending on preference. These goggles will likely need 3s power. EE to determine how they receive power and what connecters sneed to be made. We will likely try and record the flight using the FPV goggles using the internal DVR function of the EMAX Transporter 2. Pilots may choose to use their own goggles, in which case the emax will use stock dipole antennas and function the same as a 5.8 GHz Monitor.

The FPV Monitor will likely use stock dipole antennas, but allow flight engineer to monitor FPV footage in real time along with the pilots. Currently, one monitor has a 2pin JST to XT60 adapter, EE to verify functionality and determine whether or not to make more. The FPV Monitor is capable of an RCA output, which means that it can be used with an RCA → USB adapter. EE To verify we have enough RCA cables in the right direction to operate in this mode. Theoretically, you could have one 5.8 Monitor away from the flightline for the rest of the team to view with. Up to you guys GG it just needs power.

There will also be a dedicated 5.8 GHz Video Receiver, currently we have an RC832 module, but any generic 5.8 GHz Receiver will work. This receiver can either output RCA, which will be adapted to a USB format to be used as a webcam on a PC, or it can output in a USB format directly. This video feed will be fed into the groundstation computer to allow for landing pad detection, or to allow recording of the flight.

Optional Hardware

Optional hardware typically requires the use of ZP with custom telemetry.

Tracking Antenna

The antennas will use directional antennas to improve connectivity with the drone, and must be placed as far apart and as high up as possible. They can be mounted on poles, and stakes may be driven into the ground with guy-lines to keep them upright (much like regular 5G antennas). Grounding wires can be driven into the ground as well. The towers should be as far apart as possible (one may have to be behind the tent and one in front of the tent - hence why it is important to get them to be able to go as high as possible), so that we have minimal interference. Even though we’re using different frequencies, they are still close to each other and notch filters may help significantly in signal quality, as will antenna separation. Antenna Towers should support fully tethered & fully untethered operation.

Each tower will have a: Nucleo, IMU, GPS, antenna all mounted on the panning & tilting head. This pan/tilt head should be able to track a drone flying ~ 70km/h at a 50m radius away while maintaining accuracy within 15 degrees of the center of a drone at a max range of 7km away. Mounted on the tracking antenna (but perhaps not on the moving head) of the antenna may be signal boosters, signal relays, excess wires, wire splitters, power, etc.

Tethered Operation

In the event of tethered operation, towers will have a USB Link from the Nucleo boards to the GSPC, as well as a set of coaxial cables (or a single one in non-diversity operation) to the modem located within the GS enclosure. Power may be supplied along a custom cable, but all of the cables running to the tower should be wrapped up and terminate together with clearly labelled interfaces on the GS enclosure.

Untethered Operation - not strictly necessary?

The towers should be able to run self-supported and disconnected from the rest of the system (including no power) for a minimum of 40 minutes. In the event that we want the towers to be running fully untethered, the Nucleos will communicate with the PC using low-power XBEES@ 2.4ghz instead of the USB tether, and we will use a PPM Relay with lower power 2.4GHz TBS Tracer rc system to communicate from the controller to T_telem. It is also possible for T_telem to be set up as a mesh where there is permanently a third nucleo inside the gs_enclosure, which will be linked to the main antenna on T_Telem that allows data to be passed through from airside to T_Telem to GSPC. A 5.8GHz video relay will be used to distribute video from T_Vrx to the pilot goggles, as well as the DVR → GSPC. Individual batteries will be provided to each tower, but these should support the system for a minimum of 1hr.

GS_SW

The software on the Ground Station inscludes the GUI, as well as all the backend processing for receiving/sending telemetry data. This is built entirely by the CV Subteam.

Telemetry TX/RX

messaging formats will be defined in the software architecture section.

The GSPC will receive from the RFD900x as a serial stream. This will be processed by the GS_SW before being displayed on the gui and passed to the tracking tower nucleos.

The tracking tower nucleos will also interface with the computer as serial streams (either xbee or wired). Care will have to be taken to ensure there is no crosstalk between them.

GSPC will send to the aircraft using the rfd900 serial communications port.

GUI

The gui should allow for the user to see the aircraft status, aircraft track, path, waypoints, and other relevant flight data listed in Ground Station-GUI .

The GUI will also allow the pilot to edit waypoints & command the aircraft to takeoff/land in certain modes. The Aircraft shall operate in GPS_Hold mode when being operated remotely from the groundstation.

Remote Piloting

The command of the aircraft will be done by the pilot with their choice of either a dedicated set of FPV Goggles or Monitor, connected to the VRX either by 5.8 relay or direct by split rca. The controllers used will be TX16s MKII models, and a ppm relay or output converter will be provided on a frequency other than: 900, 1.2, 1.3, 2.4, 5.8. this means we need to buy more dragonlink modules?

Two controllers will be linked together, with one controller being the “master” using the trainer port. This means that if one pilot is unable to continue flying, the second pilot can takeover simply by hitting the switch. CC: Megan Spee confirm this is ok w/u at comp?

Software Architecture

This section will discuss the computers involved, before then diving into communication architecture as well as messaging formats, different flight modes, and fail-safe contingencies.

Note that in our architecture, all communication from and to the ground is going to go through either the RFD900x, or the VTX module.

The computers

🗂 References and documentation

• How to use RFD900X: https://uwarg-docs.atlassian.net/l/cp/LPn8hwCv

• VN-300 Rugged pinout: 2023-03-26 - VN-300 Rugged Harness

• ZeroPilot Software ZeroPilot 3.0 Architecture

• [UART]  UART

• [Competition Design Outline] Competition Design Outline

• [Competition Requirements] Competition Requirements

• [CV Search] Search for Landing Pad