...

Competition Year

...

2023-2024 Aerial Evolution of Canada Student Competition

...

Team

...

Waterloo Aerial Robotics Group

...

Architect(s)

...

Anthony Luo

...

Status

...

...

Last date updated

...

01 Jun 2023 - draft

...

On this page

...

🍞 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 specific sources and rails are listed below:

Wiring

Connector Standardization

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

...

📐 Architecture

...

Scope

This is the top-level document for the 2023-2024 AEAC competition aircraft “Pegasus”. These documents describe the purpose, function, and decisions made relevant to the design and use of the remotely piloted aircraft. It has been divided into sub-sections (in no particular order) which hope to offer a global overview of the design and implementation of all systems, as well as how they interface with each other.

Ultimately, this document serves as a “reference manual” for Pegasus, and should contain necessary information for the usage and support/maintenance of Pegasus. Justifications for design decisions and background knowledge should be provided as references, external links, or as subpages. This document seeks to state how the Pegasus system works, and not necessarily why it was chosen to work in that way.

Updates

If you are editing this document, please remember to update the changelog and modify the version ID (found in the table at the top of the page).

This document will be considered controlled from October 1st onwards. Any changes after that point must follow the formal RFC process. Ping Anthony Luo for more details.

Supporting Document

🗂 References and documentation

Anchor
arch24_refs arch24_refs

🖇️ Standards

BOM

This lists all of the components that constitute the configuration of a drone that we wish to fly at competition in May 2024. Some parts may be listed as “Optional” (🔍), in which case they will be they are not strictly necessary for flight but may be useful in improving system performance.

Here, “Quantity” refers to the number which is needed for a functional drone.

List of user manuals & references

We maintain an active list of PDF revisions of user manuals, datasheets, and spec reference parts in the event that an externally hosted server goes down or a manufacturer discontinues a part.

Pegasus Overview

Pegasus is a “heavy-lift” quadcopter designed to serve as a generic quad-rotor platform for AEAC 2024 (CONOPs linked in references) as well as future competitions. It features standard mounting grids across the entire frame, as well as modular landing gear and easy disassembly of all components for transport or repair.

Below is a summary of system characteristics which are expected of Pegasus:

Airframe

...

Pegasus is an X-frame configuration and motor arms attached directly to a straight aluminum block. Here are some of the key notes:

• 30x30mm mounting grid for peripheral and accessory mounting

• 1.25mm thick mainplates

• 76.2mm distance between mainplates

• 422mm plate width (flat edge to flat edge)

• 1.19m distance motor to motor

• 1.80m tip-to-tip with props on

• 20mm high spacer for the autopilot

Image Added

Top & Bottom Plates

Featuring 30x30mm pattern of holes on the majority of the surface with rounded square lightening holes, these plates provide torsional rigidity and protection for batteries within the drone. They are approximately 1.25mm thick, but the thickness across the sheets varies due to manufacturing imperfections. The plates were first made with custom carbon fiber flat layups, and were then cut out on the CNC router.

Center Block & Inner area

The center block is where all 4 arms connect, and how the arms remain rigid and centered on the drone frame. It consists or one aluminum square block in the middle with a large hole in the middle for wire routing and weight saving as well as 4 arm connector pieces. These bolt onto the center block using 4xM5 bolts and they have an OD that fits snugly in the ID of the carbon fiber arm tubes. The plates and standoffs are attached to the center block using M3 screws. It is designed for easy removal of the arms for transport, if necessary.

...

Interfacing

The center block and arms are designed to allow 3-phase motor wires to run through the arms and exit out the cube below the pixhawk or otherwise <drawings here would help>.

MT30’s are designed to fit within the cube and arms for quick-disconnect of the 3-phase leads. See connector standardization for more information.

Removing the arms

To remove the arms, the bolts on the top and bottom of the arm connectors need to be removed. After this, the arms can be slid off the arm connectors, the MT30 can be disconnected, and the arm is ready to be fully removed.

Arms & Landing gear

The arms mount to the airframe at the center block, and also through the spacers located at each corner of the frame. The landing gear mounts directly to the arms.

...

Payload attachment points

Two slots per arm have been left in the plate to accommodate payload mounting and any other necessary additions to the aircraft. The slots are designed to give sufficient clearance for members extruding downwards from the frame, and space to access any connectors on the top of the tubes to mount and dismount payloads.

...

Cabin + Cargo

The initial plan for the Cabin and Cargo bay is a main skeleton of 10mm diameter carbon fiber tubes mounted to the 30mm x 30mm hole pattern on the bottom of the drone. Attached to this will be swappable “aero-panels” that can be iterated on according to simulations and the results of flight tests in order to optimize flight characteristics. We will have a passenger cabin portion at the front with 4 seats and a cargo bay in the back. Both will be accessible through doors of some kind and the passenger cabin will have windows.

Motor Mounting

Motors are mounted on 3d printed mounts with a 32mm M4 bolt circle pattern with 4 evenly spaced bolts. The motor mounts have an indent to relieve wire strain, and minimal material to save weight.

...

Monster Mount (MM)

The plate section of the MM accommodates the $200 CV camera, FPV camera (down facing), OFS, and 1D lidar. The tube section is screwed onto the arm using M5 SHCS and a nut, and the plate which holds the actual sensors and camera is slid into the dove tail fit. A Cotter/Clevis pin is used to prevent the plate from sliding in-flight.

...

The cameras and lidar are screwed onto the plate while the OFS is clamped down.

...

Electrical Protection

Although not strictly airframe-related, avionics covers and cabin covers will be an integral part of the airframe design, and must be well-integrated. The end goal of the system is simple:

1. Protect electronics from the elements

2. Allow easy (tool-less or one-tool) access to the components, without restricting someone from working on or replacing components

3. Allow for appropriate cooling for the components

Typically, when airflow but water ingress is required, the use of S ducts and foam can be employed. Internal fans may also be used to provide airflow to prevent system overheating while on the ground.

Most components will run ~ 20-30 degrees hotter than ambient, and will thermal limit around 80 degrees celcius. This means that on an average “warm” day, our components have around 20-30 degrees of headroom. Think about how much hotter a cabin may cause components to be, especially if black carbon fiber and in the air (exposed, not under shade).

Propulsion

...

Pegasus uses 4 T-Motor Antigravity MN6007II kv160 motors. These motors are designed to run on 12s voltage and are wired to APD 120F3[x] v2 ESCs. The ESC’s are significantly overspecced and are designed to allow for continuous operation in high ambient heat environments and minimal passive cooling, although this is not a recommended mode of operation.

Motors

There are multiple alternative motors which we may use, and these interface to the carbon-fiber arms using 3d printed parts. The motor specifications change a bit depending on the propeller that we’re using. Review the following charts:

Expand
title MN6007II KV160 Charts
Image AddedImage AddedImage Added

From that data, we can synthesize the fol

Interface

The motors mount to a 3d printed block which attaches to the ends of the arms. Multiple propeller mounting options are available!

3.5mm male bullet connectors will exist on the motor leads, and these will plug into 3.5mm female bullet connectors on 3-phase wires which run through the carbon fiber arms.

Propellers

The current propellers are T-Motor MF2211 props. These do not follow typical propeller naming convention. They are 22” in diameter, but 8” in pitch (not 11). The 11 at the end of the name refers to the maximum thrust which the prop may provide.

Propellers are mounted in an “X-IN” configuration. Refer to the ardupilot docs for more information: https://ardupilot.org/copter/docs/connect-escs-and-motors.html

Mounting

These propellers do not need a prop-washer to be mounted, the following infographic from the T-Motor website explains proper mounting solution:

...

Vibration

With folding props, it is possible to have vibrations and harmonics. It is important to look at motor data from telemetry logs, as well as listen to pilot and operator feedback gained from visual and audio cues, especially if there is significant turbulent air or pressure differentials across the path of the propeller.

Balancing

Our props come balanced from T-motor, and may need to be balanced if they acquire nicks, scratches, chips, or other deformities. See <prop balancing link> for more information.

Safety & Storage

T-Motor Polymer folding props require particular storage and upkeep.

Please refer to <general prop storage> for storage information, and please refer to T-Motor instructions on tuning the friction of the joints to ensure safe operation.

Electronic Speed Controllers

For the most part, the choice of electronic speed controllers is fairly relaxed as there are many commercial and off-the-shelf hobby components that may do the job. Keep in mind when choosing your speed controllers the software, protocols, and current/volage ratings that it may have.

Interfacing

ESC’s will have 3.5mm female bullet connectors on 3-phase live side. This will attach to a short MT-30 extension, where the MT-30 on the block-side will be fe-male, while MT-30 on the arm-side will be male.

Our speed controllers often have through-hole solder pads and castellated pads. Refer to EE guidelines on how these should be soldered.

There exist solder pads in between the voltage pads for ground, signal, and telemetry on all APD esc’s and PDB’s. These should be used, with M1-4 connections on the PDB being taken to the pixhawk.

Heatsinks + Cases

Custom mounts will be provided for electrical components as deemed necessary. Heatsinks will be provided as deemed necessary.

Cases for electronics are 3D printed in black PETG with the exception of cameras or other sensors where white will provide better sensor performance. Cases will mount to the 30mm x 30mm pattern on the top plate of the drone unless other mounting locations are deemed more appropriate. The monster mount is an example of this and will be located out on an arm. Mounting requirements for individual sensors and the decision process for their design is found in https://uwarg-docs.atlassian.net/l/cp/Y0pwRtx6 .

Software Configuration

It is recommended to run the ESC’s using default firmware (BL_HELI, Bluejay, etc) at 48khz update loop. This offers the best blend of controllability and power efficiency.

Bidirectional dshot must be supported as this offers critical logging and flight performance data, as well as advanced filtering options for the autopilot. On Pegasus, it is recommended to run DShot 300, as 600 may introduce significant signal integrity issues, and DShot 150 may be too slow for accurate bidirectional data transfer.

Telemetry wires shall be connected to a uart port, in the case of a bidirectional dshot failure. This is significantly slower than bidirectional dshot but offers us a failsafe and backup.

Connectors

Anti-spark XT90s need to be used for our battery connections. Anti-Spark Connector Standards

Power Distribution

...

On Pegasus, “power distribution” refers to all elements that affect and interact with power before it is distributed to individual components. Typically, this includes:

• Power distribution boards for ESC voltage

• 12v and 5v LV supply for peripherals

• Power monitoring & Power backups for the flight control system

All power on pegasus runs to a common source (the PDB), with the exception of the pixhawk system power delivery which will be provided by the power monitor + BEC backup.

Battery Voltage

Battery voltage is around 50 volts for pegasus. All high voltage systems follow <EE to insert spec here>.

Interfacing

There exists 30x30mm mounting holes on the PDB. These may be used directly on the 30x30mm mounting holes on the drone. Electrical isolation must be provided between the contacts of the PDB and the carbon fiber, as voltage may arc across the carbon fiber starting (at worst) fires.

<photo>

A case shall be provided for the PDB that covers the terminals, but leaves sections exposed such that it is possible to attach wires to the LV and motor busses.

<EE to attach photo>

• XT90’s will be used between battery and PDB

• XT60’s will be used between PDB and ESC

Batteries & Harnessing

Pegasus officially supports 4, and 6 battery configurations. Physically 8 batteries will fit with a light enough payload.

These batteries are cross-connected from each other, meaning that the only difference between a 4 and 6 battery connection is the NC of one pair. These should be labelled or colour coded

Below shows the two different battery configurations we can fly. Pairs of 6S battery cells are connected in series and terminated with an XT90. The harnesses below show how the batteries are attached and how removing harness 3 and the cells with it bring the drone into its 4 cell configuration.

...

XT90 standard across the board, but the maximum peak current draw from all 4 motors is anticipated to be around 90Amps. Any individual motor will not draw more than 23 amps at a time, not including the path.

Errata

Low Voltage

< Insert schematic here >

Low voltage systems on Pegasus run at either 5 or 12v. Below are the voltage and current draws of each (potential) Noteworthy peripheral. Please refer to individual documentation for more information

• Raspberry Pi + LTE: 12V 2A

• Pixhawk: 5V 3A

• 800mW vtx: 12V 1A

• Gemini: ???

• I may be missing multiple items. EE leads please double check from prev. years and compare

Power Monitoring

We use powering monitoring from a Holybro PM02D HV module. This uses I2C to communicate with our autopilot, meaning that we don’t need to do analog voltage or current calibration.

This is used in isolation, with no backup. There is only 1.5A continuous draw available ee leads fact check me, and this power monitor will continue to update current and voltage measurements even after LDO failure.

LDO failure should be mitigated by providing the pixhawk with a BEC that is capable of up to 5A continuous draw. fact check me 5 or 3a.

Pixhawk Errata

Note that the pixhawk telemetry ports only support 0.5A current; with the exception being “Telem1” which supports up to 1.5A.

The pixhawk also supports two concurrent power monitors. We are using 1 power monitor and 1 BEC with NC’s on the remaining pins for better redundancy under thermal limit.

DShot is only available on FMU out as of 4.4.0, but will be available (tentatively), on certain I/O FMU Outputs in the future.

Flight Control System

...

Pegasus will operate using an ardupilot software stack. As of Fall 2023 Pegasus runs software revision 4.4.0, as this brings necessary changes for digital power monitoring and bidirectional dshot.

Software Configuration

The airside compute system will consist of a pixhawk 5x or pixhawk 6x, augmented by an auxiliary compute unit handling LTE telemetry and video transfer.

This auxilliary compute unit will be a Raspberry Pi 4.

Bidirectional DShot will be used on the 6x. Functionality may not be available on the 5x due to the different MCU’s (H7 vs F7).

Wiring & Outputs

We will follow the ardupilot “quad-X” configuration for Pegasus:

...

Lift motor wires must be plugged into FMU output, with each output number corresponding with the motor number as shown in the configuration.

Relays may be used on FMU or I/O pins. Refer to ICARUS documentation tentatively.

All PWM outputs will be attached to the I/O pins.

USB

• Usb port will be connected to the RPI for LTE Telemetry

Telem 1,2,3

• Telem1 will be reserved for the RFD900x (should it be needed)

  • Telem1 is the only port that is rated for 1.5A

• Telem2 will be connected to the Lightware SF45B

• Telem3 will be connected to ELRS Diversity RX / Gemini RX (EP1 TCXO Dual)

GPS 1, 2

• GPS1 - GPS1 (front)

• GPS2 - GPS2 (back)

I2C

• I2C will be sent to the rangefinder (downwards facing)

CAN1, 2

• CAN1 will be connected to the OFS

• CAN2 will be reserved for CAN interface boards (should they be required)

Serial/UART 4

• Reserved for further comms w/the rpi if necessary

Power 1, 2

• Power1 will be connected to the Holybro PM02D

• Power2 will be connected to a BEC

Sensors

Please refer to each sensors page under our operating manuals space in sysint.

Pegasus will use the following external sensors:

• Two M9 or M10 sensors, using GPS blending for position; or 2 RTK sensors being blended.

  • one of these will be the “primary” gps, and must have an accessible safety switch.

• 1 Optical flow sensor, facing downwards and aligned with the drone

• 1 Lidar rangefinder, facing downwards

• 1 Omnidirectional rangefinder, mounted on-top of the drone.

Anni to make mounting requirements pages for all of these (see sysint space most likely).

GPS Sensors

The two GPS sensors will be placed inline with the roll axis of the drone, on posts to elevate them away from the rest of the wiring. One GPS will be facing forwards, while the other GPS will be facing backwards (in order to improve wire lengths). This GPS will be calibrated as “YAW180” within software.

Optical Flow Sensors

A single hereflow optical flow sensor will be mounted on the monster mount.

Lidar Rangefinder

A single lidar rangefinder will be mounted below the drone, facing downwards.

If deemed necessary through testing, a second lidar rangefinder may be mounted on top of the drone, facing upwards augmenting the omnidirectional lidar

Omnidirectional rangefinder

A lightware SF45/B provides obstacle avoidance through ardupilots in-built obstacle avoidance system. This rangefinder is not weather sealed. See documentation on choosing a lidar for more information on the final decision: Decision: Type of Rangefinder for Obstacle Detection - SysInt - WARG (atlassian.net)

A word about calibration

It is not necessary to re-calibrate the compass every time you fly, but it is strongly recommended to do so if you have moved more than 40km from your original location as you may have different magnetic interference.

Accelerometer calibration does not need to be done more than the first time you did setup, or if there is significant concern about the health of the system.

Autonomous operations

The drone has 3 scopes:

• Cruise: Multiple waypoints in the entire flight boundary

• Search: Landing pads around a single waypoint

• Landing: Single landing pad

Autonomous operations use MAVLink to communicate with the flight controller.

Autonomy airside

Autonomy airside is at the search and landing scope, around a single waypoint, and is responsible for guiding the drone from the final waypoint to landing. Control is handled by the airside system running on the Jetson.

Airside System

Ground station

Ground station is at the cruise scope, for multiple waypoints, and is responsible for guiding the drone along the most efficient waypoint to waypoint path. Control is handled by the pathing system and Mission Planner running on the ground station computer.

Pathing

RF + Peripherals

...

There are a number of external devices on the drone. Autonomy is largely responsible for additional compute, while Electrical is largely responsible for RF

Frequency Distribution

Pegasus will support 2.4+900+433 interchangeable control links, as well as LTE+piggybacked telemetry, and dedicated 2.4 or 900 telemetry systems. 1.3 and 5.8 video systems shall be supported. The primary distribution:

• 900mhz RFD900x or ELRS Airport - Backup telemetry. Not mounted typically but possible addition in case of poor LTE coverage.

• 2.4 ghz ELRS Gemini control link - Primary control link, carrying MAVLink info air->ground as well as typical control link ground->air

• 1.3 ghz video link - Primary pilot video link

• LTE Telemetry + Video streaming - Primary telemetry link, primary computer vision video link.

Antenna Choice

2.4ghz antennas will be regular dipoles, potentially folded dipoles. Refer to https://docs.google.com/spreadsheets/d/1G2Ue9xrBFwbJbkzpw3Gx3-eZ3x3dWSVjVrP4fPepvcg/edit#gid=0 for the best selection.

1.3ghz antennas will be circularly polarized antennas provided by TrueRC. Airside antennas will be Singularity 1280’s. Information regarding this antenna can be found in Singularity 1280 V2 .

900 MHz antennas tbd

433 MHz antennas tbd.

Antenna Placement

< EE TO ENTER MORE INFORMATION ABOUT RF STUFF >

Control Link

The airside control link will be an ELRS Diversity (true diversity) receiver wired into a telemetry port on the autopilot. This receiver will be flashed with gemini firmware, and paired with WARG’s gemini transmitters on the groundside.

The groundside control link will involve a TX16 paired with a small EP1 or EP2 receiver, which will be wired directly to the gemini transmitter. The EP2 receiver baud rate will be modified to match the gemini spec?

Telemetry Link

Telemetry will be provided through LTE, with ELRS gemini allowing MAVLink packets to be piggy-backed in between regular RC link packets. This gives us a second redundant option in case the LTE system loses power or is otherwise unusable, at least temporarily and for long enough to recover the drone.

There are no current plans to forrward MAVLink out from the TX16 - yappu scripts may be run in order to assert basic RTL functionality in the event of a lost LTE link.

Video System

There will be at least 1 forward facing and 1 downward facing camera. There may be a third camera installed at the pilots discretion.

The entire pilot video system uses Analog video, including:

• 2 Caddx baby Ratel 2 cameras (or cameras of similar size)

• 1 PWM-based video mux

• 1 OSD using ardupilot telemetry

• 1 1.3ghz video transmitter.

FPV/Pilot Cameras

One FPV camera shall be mounted pointing downwards, with no obstructions from landing gear or payload systems, allowing the pilot to view the landing zone and safely guide the drone to the ground. The orientation of the downward camera shall be as if a typical camera were pointed forwards, and then rotated 90 degrees to face downwards. The angle of this camera should tied to the angle of the drone.

A different FPV camera shall be mounted pointing forwards, with +/- 20 degrees of adjustment from being level while the drone is in forward flight. This adjustment allows the pilot to fine-tune the field of view for their flying style. For design purposes, level flight will put the drone at around 30-45 degrees pitch. There should be no obstructions in the field of view of this camera, with the exception of propellers which may be in the field of view provided they do not obstruct vision such that the pilot can not see past them.

Wiring from the FPV/Pilot cameras is a pure analog signal, and should be shielded and kept away from sources of high EMI as much as possible.

Video Mux

Connectors will not be used directly on the video mux, and all input/outputs should be soldered with pigtails or extension leads, with locking connectors. This is done since connectors are easy to bump and come loose, especially when non locking.

The video mux & the OSD may share a case.

OSD

Similar to the video mux, only locking connectors or soldered pigtails shall be used on the OSD. OSD & VMUX may share a case.

Video Transmitter

The video transmitter will generate a lot of heat, but comes with a heat sink. The video transmitter will also mount to a standard 30x30 pattern (fpv standard).

Autonomy Video System

Per a discussion in the 2023-10-03 AEAC Sync, the Jetson will not be mounted airside. Digital video will be transmitted via LTE from the Raspberry Pi on the drone to the autonomy computer on the ground.

The CV camera will be connected to the Raspberry Pi to provide digital video.

Ground Systems

Our ground systems will consist of 2 primary tracking towers (Control + Video links), and one potential backup tower for Telemetry link.

All tracking antennas will consist of the same control scheme, using an arduino, neo m.8 gps, and bmx160 IMU. They will receive forwarded communication from the ground station computer, and will operate autonomously.

...

Control Link

Control will feature a small relay to allow for a fully wireless tracking antenna. Wireless SBUS trainer will be provided to the groundside TX16s, meaning that there are the following links:

TX16 (secondary) → EP2 (inside controller primary)

TX16 (primary) EP2 -(wired)-> Serial port 1

TX16(primary) → EP2 (tracking antenna)

EP2 (tracking antenna) -(wired)-> Gemini (tracking antenna)

Gemini → Diversity RX (airside)

Diversity RX -(wired)-> Autopilot

Gemini

The Gemini is supplied with 5V power from the tracking antenna PCB. The Gemini antennas that will transmit to the drone are clipped directly onto the two red TX modules on the PCB. It is directly wired to the TX16 controller to receive the command data over UART.

The Gemini board draws an absolute maximum of 2.26A. During typical operation with both transmitters working it should draw somewhere around 1.2A ~ 1.5A.

A wiring diagram of the Gemini board in standard operation is shown below.

An RGB LED on the PCB display’s the Gemini’s current status. The different statuses are described in the following table (taken from ELRS Wiki).

The Gemini PCB runs ExpressLRS code from the ELRS GitHub. Updating the code to a different version can be done over WiFi or USB. For details, see ELRS Gemini TX - Programming the Gemini TX.

Video Link

Video will be run on 1.3. A diversity (!!!) video receiver will be connected to an omnidirectional antenna as well as a patch antenna. The output will be wired to a 5.8GHz video transmitter, which will re-broadcast the analog video signal to further groundside devices (goggles, displays, etc).

Open Questions

PIKACHU OBLIGATORY PIKACHU

...

ok thank you for listening

Change Log