...

[Competition Requirements] [CR]Competition Requirements

📐 Architecture

...

<Add diagram>

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].

...

The wings and the tail will house a lot of the RF Communication modules, such as the VN-300, rfd900 antennas, vtx VTX antennas, and any gps GPS modules.

Transmitters

Both transmitters (rfd900RFD900, 1.3ghz VTX), should be placed in areas with adequate cooling/airflow. They are not weatherproofed, but do tend to be cooled passively by air moving across their heatsinks. In ground ops mode, it may be necessary to actively cool the devices over extended periods of time, especially if transmit power is high.

Sensors

The VnVN-300 receiver (red box), as well as the BMX160 IMU should be placed as close to the center of mass of the plane as possible, with the axis aligned (x is forward, refer to ZPSW Documentation for more detail). This can be done above or below the passenger compartment, but should be in a weatherproofed section of the plane.

...

Both VN-300 receptors & their grounding planes should be placed 1M apart, facing directly upwards, above other elements. These can be mounted at the ends of the wings, or on vertical mounts above the wings (like an AWACS disk) if airflow over wings is a significant issue. The VnVN-300 is significantly smaller than what is pictured on the right, and two vertical spars on each wing could be sufficient. The vn-300 is not weather rated, and should be protected.

Both NEO M.8 GPS Modules should be placed facing upwards, away from one another. There is no significant distance requirement beyond an initial small separation. This can be done by placing both on opposite ends of the fuselage, one on the fuselage and one on the tail, or however the mech mechanical team sees fit.

Airspeed sensors should be placed in clean air, facing forwards.

...

The RFD900x Antennas should be placed 90 degrees apart from each other. There is no distance seperation separation requirement. The RFD900X transmitter itself should be placed somewhere with adequate airflow.

...

Cameras will be mounted outside the fuselage, one pilot cam forwards, one pilot cam downardsdownwards, one CV cam downwards. The pilot cameras will feed into a 2-1 mux switch controlled by ZP before feeding into the VTX.

...

Motor controller placement is decided by mechMech, in a way such that the push prop ESC has adequate airflow, and the quad ESC’s have airflow when in use and are otherwise hidden.

...

All dirty power rails will be broken out from the flight battery using a PDB (i’m a fan of this one if we need a COTS pdb http://www.mateksys.com/?portfolio=fchub-12s PDB) , while the clean power rail will be broken out of the 3s battery.

...

On the ground, there will be a primary “groundstation” “Ground Station” GS as well as the two tracking antennas “T_Telem” and “T_VRX”. GS Will be able to run unsupported (no power, no internet), for the competition for a minimum of 1 hour or from a standard wall outlet. Main batteries should be included within the GS Enclosure as the enlosure may be left outside overnight in inclement weather. All of GS should be weatherproofed, or be able to collapse into a weatherproofed box (it could be sitting in a mud/ or a puddle).

...

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 guylines 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: nucleoNucleo, imuIMU, gpsGPS, 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.

...

In the event of tethered operation, towers will have a USB Link from the nucleos 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.

...

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 443 MHz Dragonlink 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 groundstation Ground Station inscludes the GUI, as well as all the backend processing for receiving/sendeng sending telemetry data. This is built entirely by the CV Subteam.

...

This section will discuss the computers involved, before then diving into communication architecture as well as messaging formats, different flight modes, and failsafesfail-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 PX5 Will be set as a real time backup, as well as potentially act as a sensor readout. does the px5 need to be placed in the middle of the airframe for inertial computation to work? It has 3 imusIMUs, 2 temperature calibrated barometers, and will run it’s own sensor fusion algorithms and can act as a backup source of information for position, and a primary source of altitude information.

When the PX5 is acting as a real-time backup, the PX5 will be communicating to and from ZP using 3 PPM wires. 1 PPM will be from ZP → PX5, acting as 8 controller inputs, while 2 PPM will be from PX5 → ZP, acting as direct motor outputs. This retains ZPin control of communicatinos communications and other functions of the drone, but allows for failsafe in case of a compute error inside of ZeroPilots ZeroPilot’s own attitude management system. The PPM from PX5 will either be encoded directly onboard, or the PM outputs from px5 will be converted externally by PWM → PPM converters.

...

• arm/disarm signal (arming before we takeoff for no errors)

• output enable/disable signal (so that ardupilot ArduPilot doesn’t freak out)

• 4 channels of input request of where to fly to (ardupilot ArduPilot will fly in GPS mode).

• 1 channel configuration plane/quad/hybrid

• 1 channel autolandautonomous land/takeoff/cruise.

Jetson TX2

The Jetson will handle geolocation of landing pads, as well as the final landing-approach sequence. ZP will request information from the Jetson when ZP is ready to begin the landing sequence, and Jetson will return data on which direction to fly in. Inertial flight < 1s closed loop should be possible with centimeter accuracy. Thus, the Jetson handles the search pattern for the landing pad, as well as the process of centering the drone over the landing pad. Once landing has begun, ZP will no longer request data from the Jetson.

...

ZeroPilot

ZeroPilot will handle all of the inter-computer communications, as well as the air-ground communications, path planning for flying through waypoints, attitude management, as well as gathering sensor information and relaying that to other components. It is the primary driver of everything on the drone.

...

During the boot sequence, all sensors should be initialized & calibrated if required. connection between GS ↔︎ Drone should be initialized and confirmed. Any errors should be detected during this sequence and dealt with accordingly. This stage should be able to be reached using a Communications (comms emulator) Emulator. The drone may need to be power cycled when going from comms emulator to rf RF comms. Comms emulator should verify all systems OK, and allow us to run certain diagnostic tests while on the ground (orientation, sensors, gpsGPS, etc) in the absence of Radio Frequency control (e.g. Radio silence during competition).

Disarmed

In this mode, ALL components are disarmed. This means the drone is disarmed, the controller is disarmed, and the GS_SW is disarmed. All three must become armed for us to move out of disarmed move.

...

Once all conditions are met, the drone will go into ground opsOps.

Ground Ops

This is a mode where the drone is armed, the props are unable to spin (for safety) and systems can be in a high power mode. No arming is necessary to leave ground ops mode - it is purely a software distinction between being on the ground and in the air. It can let as accomplish things such as hot swapping batteries, landing & loading passengers (by lighting up the PAX ABOARD) light, etc. We leave this here so that there can be future expansion as well.

...

• 2 byte header Aidan Bowers (Deactivated) Former user (Deleted) I don’t know what I’m doing with this

  • 4 bit message type

  • 4 bit destination

  • 8 bit message length

• [length] byte message data

• 2 byte footer

  • 1 byte crc

  • 1 byte stop bitsflag? Anthony Luo → could just be message type + stop bits

Communication message formats are TBD. Neha Srivastava Mika Shaw

...