Competition Year | 2022-2023 Aerial Evolution of Canada Student Competition | ||||||
|---|---|---|---|---|---|---|---|
Team | Waterloo Aerial Robotics Group | ||||||
Architect(s) | |||||||
Status |
| ||||||
Last date updated | - draft | ||||||
On this page |
|
Summary
This page describes the top-level view of the 2023 competition airframe, and contains references to sub-pages with implementation specific details. This page will be finalized as of Nov 6, 2022. Any changes after that point must follow the formal RFC proces. Ping Anni for more details.
| Note |
|---|
Please make ur RFC using the following link: tbd |
🍞 Acronyms & Links
[The Drone] - The drone as a whole, including electronic components and integrated software systems.
...
[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:
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
All components marked “Optional” are not final but must have the capability to be supported. |
Power
Propulsion
Compute
Mandatory:
...
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
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
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Mech to add information about the airframe design, with information about components, assembly, expected failures, etc. Mech to add links to relevant pages of documentation. |
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
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Electrical to provide insight on where the antennas should be mounted to minimize RF interference with devices such as GPS sensors, and also to provide detailed information on coax cable extensions. |
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Mech to provide clarity on the actual mounting location of the VTX antenna. |
Cameras & Related Peripherals
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Mech to add additional information on camera mounting solutions. |
GPS Sensors
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Mech to add additional information on GPS mounting solutions. |
Peripheral Sensors
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Mech to add additional information on the remainder of the sensors locations. |
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
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Anni to update this |
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
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Mech to add finalized designs for static towers |
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Electrical to update with batteries & wiring diagram for the towers |
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:
...
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.
...
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
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
This section is only applicable if the compute units are mounted. Otherwise, refer to arduplane documentation. |
...
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
...