...

🍞 Acronyms & Links

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

...

[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 avionics compartment should allow for airflow and cooling that can be shut (either manually or automatically) in inclement weather.

Sensors will not may be placed inside the avionics compartment due to electrical noise. They shall reside in another weather-sealed compartment away from the main avionics compartment, but they should be mounted where they make sense. See below

Wings & Tail & Fuselage & Peripheral Mounting

...

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 Vn-300 is significantly smaller than what is pictured on the right, and two vertical spars on each wing could be sufficient. Is the The vn-300 weather sealed?is not weather rated, and should be protected.

Both NEO M.8 GPS Modules should be placed facing upwards. There is no significant distance requirement, although a small separation would be ideal. 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 team sees fit.

Antennas

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

Barometers can be placed as necessary.

Antennas

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

...

Darwin Clark maybe this is something thath you can take a look at?

• All connectors for motors will be 3mm banana plugs? The ESC end wil be male and the motor end will be female. Could we consider using something like 3 pin EC5 connectors? Not sure what would be more space efficient / less likely to short.

• Connectors for sensors: locking JST connectors, with the sensor end soldered directly to the sensor?

• Link to dev interface ? idk…

LED’s

For realism, we will have

• XT60 used for DC power.

• XT90 used on batteries & solder pads for COTS ESC’s PDU’s

• 3.0mm female banana plugs on the ESC’s

• 3.0mm male banana plugs on motor terminations?

LED’s

For realism, we will have regular Nav lights on the dirty 5V or 12V rail, as well as a green PAX aboard light that is on a 12V or 5V relay controlled by ZP.

...

The antennas ill 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 guyouts guylines to keep them upright (much like regular 5G antennas). They . 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.

...

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

...

We can break the flight stages down into: Boot, Disarmed, Ground Ops, Takeoff, Cruise, Search, Landing, Operator Override. In each of these modes the software will interact differently to accomplish the tasks that it wants. It is important to note that at competition, the drone should be able to go from boot → ground ops with user input (physical drone arm, controller arm, software arm), and then it should be able to fly autonomously for the rest of the competition (including going between ground ops and flight).

Operator Override: This is the only mode where user inputs will translate directly to the motion of the drone. In all other modes, switches & buttons from the user may configure the drone to move to certain locations, but operator override gives the pilot the opportunity to control the control surfaces & attitude of the drone directly.

Boot

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 comms emulator. The drone may need to be power cycled when going from comms emulator to rf comms. Comms emulator should verify all systems OK, and allow us to run certain diagnostic tests while on the ground (orientation, sensors, gps, etc).

...

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

User Flight Mode: Operator Override

At any point, the remote pilot can override the system and control the drone in GPS, LEVEL, or ACRO (if the quad is in fixed wing mode).

Autonomous flight mode: Takeoff

Once the takeoff command is given, ZPSW or the PX5 will take the drone from the ground to a steady height in the air. The drone will hover in the air until it receives the ACK signal from GSSW saying that telemetry & vtx are OK (making sure that tracking antennas are working). Once it receives the ACK Signal, the drone will return ACK_Confirm wait for GS_SW to send a list of waypoints and then enter into cruise mode. Takeoff mode is purely ZP based. We expect GS_SW to send a list of waypoints before we liftoff from the ground.

Should an error occur during takeoff, the drone will land itself. Should an error occur when the drone is in the air, user override can be provided to bring it into cruise if desired, or the drone will land itself within 2 minutes. is this a reasonable amount of time to debug?

Autonomous flight mode: Cruise

During cruise, the drone will continually send back healthcheck, telemetry, and position data. In cruise mode, the primary decision makers are ZP & GS_SW. Should a re-route be needed, GS will send the remaining waypoints for the rest of the route, with waypoint [0] being the current position of the drone.

...

R D Anthony Luo Do we want Jetson active in this mode?

autonomous flight mode: Search

In search mode, GS_SW sends to ZP that we have no more waypoints, and then ZP will request from the Jetson where to go. During the flight, the jetson will be continually receiving position packets from ZP, and so it should be able to correlate known landing pad locations to waypoints as we fly over them. At the final waypoint, the Jetson will either direct ZP in a relative direction (e.g. 4m forward, 2 m left) if it sees the landing pad, or it will direct ZP in a spiralling search pattern until it can determine the location of the waypoint.
To ZP, the data that is received is identical. The Jetson is responsible of keeping track of what general locations have been swept over using the position data, which includes altitude from the barometer.

autonomous flight mode: Landing

Once the Jetson determines a suitable landing location, it will direct the drone to be centered above the landing pad and then drop the altitude to 2m above the landing pad in a controlled descent. At that point, if Jetson sends a message to ZP acknowledging the position is good to land, ZP will use a variety of sensor fusion algorithms & the optical flow sensor to descend vertically over the pad .using a velocity controlled curve? Gordon Fountain (Deactivated)

...