Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 57 Next »

Competition Year

2022-2023 Aerial Evolution of Canada Student Competition

Team

Waterloo Aerial Robotics Group

Architect(s)

Anthony Luo

Status

V2.0 - Final competition hardware list

Last date updated

- ZP-CV communication and CV search reference

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.

Please make ur RFC using the following link: 2022-2023: Request For Change Home 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

📐 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:

All components marked “Optional” will not be present for the 2022-2023 Competition happening in Alma, QC

  • Airframe (Wings, Fueselage, tail)

Power:

Propulsion:

Compute

Mandatory:

Optional:

Peripherals

Mandatory

Optional

Groundside Components:

Telemetry & Control

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. This page will be finalized on Nov 6, 2022. After that date, any changes must go through a formal RFC process involving all subteam leads.

Airframe Design

Mech to add information about the airframe design, with information about the wings, coating process, dimensions, structural tidbits, links to relevant pages for files / assembly instructions / operational limits & capabilities / etc.

Propulsion

lift, push, offsets, spacing?

Wings

wongs.

Servo locations? numbers? gg

Tail Section

Rudder/elevator

Fuselage

Fuselage is main passenger compartment?

Avionics Compartment

The avionics compartment will house all the airside compute. The compartment should be weather resistant, but be mounted on the drone in a way such that all electronics are easily accessible and serviceable with minimal effort (ideally no screws removed to plug/unplug connectors from any of the onboard computers.

The avionics compartment should allow for airflow and cooling over critical components. The Pixhawk should be mounted center with the COG, and peripherals should be mounted as explained below.

Sensors may be placed in the avionics compartment, but they should be mounted where they make sense. See below

Landing Gear

Design, limitations, etc.

Lighting

Airside Hardware Layout

The plane will be comprised of 5 main sections: the fuselage, cabin, avionics compartment, wings, and tail. The avionics + passenger compartment will be part of the main fuselage, while the wings & tail will house more electronics. All mandatory airside compute & airside peripherals must be mounted.

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

Batteries and Power Distribution shall be mounted in front of the passenger compartment, under the same access lid as the pixhawk & various other PDB/Sensors. Batteries will be multiple 6S batteries harnessed together to provide a total output of 12S.

The battery box should be easily accessible from the top so that battery swaps may be easily accomplished during task #2, and should be weatherproof and house the PDB, Batteries, and necessary power connectors in a manner that makes upkeep & plugging/unplugging/probing connectors easily.

Transmitters

Both transmitters (RFD900x, 1.3ghz VTX), should be placed in areas with adequate cooling/airflow. Airflow can be introduced passively (i.e., drone is moving through the air), or actively (i.e. a fan). These devices are not weatherproof, and care should be taken to place their antennas away from any other RF sensitive devices. Devices such as cameras, unshielded signal wires, IMU’s, and GPS devices may experience large amounts of RF noise if placed too close to the antennas.

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.

The RFD900x will use the stock dipole antennas, which means that RF Noise generated by the RFD900 may be fairly close to the source. It is possible to use co-axial extension cables to move the mounting location of the antennas. Recommendations to put one antenna along the edge of a wing, and to place the other antenna vertically along a vertical stabilizer or landing gear. Maintain one antenna perpendicular to horizon and one antenna parallel to horizon.

Mech to provide clarity on the actual mounting location of the VTX antenna.

The VTX will use a coaxial cable extension to a side-exit singularity 1280 antenna mounted on the horizontal stabilizer. The antenna may be mounted inside or on top of the horizontal stabilizer. Maintain antenna deadzone perpendicular to horizon.

Cameras & Related Peripherals

Mech to add additional information on camera mounting solutions.

There will be three pilot cameras. All cameras should offer +/- 10 degrees of adjustment minimum, up to +/-30 degrees is desirable from their intended direction. The mounting locations are as follows:

  • forward facing at front of drone, level with horizon.

  • downward facing, perpendicular to horizon.

  • Downward facing, at a horizon angle of -30 to -45 degrees mounted high at the rear of the drone.

The forward facing camera will be the primary in-flight camera used during transition & fixed wing flight, while the downwards facing cameras may be used during takeoffs/landings as well as searching for landing pads.

There are currently no plans to motorize or otherwise be able to move the cameras in flight. This means they must maintain a pre-set fixed position in flight.

All three cameras will be wired into the Video Mux Switch, which will then pass a single analog video feed to the OSD, before being passed to the VTX. See Airside Electrical Layout for more details on wiring and interconnects. The OSD and Video Mux should be placed inside the avionics compartment, and although they do not require cases, it may be prudent to electrically isolate them from other conductive materials such as: carbon fiber, exposed wires, etc.

GPS Sensors

Mech to add additional information on GPS mounting solutions.

The VN-300 receiver (red box) should be placed as close to the center of rotation 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 with low external RF interference.

Both VN-300 receptors & their grounding planes should be placed 1M apart, facing directly upwards, above other elements. These will be mounted inside the wings.

One NEO M9N GPS Module needs to be placed in an easily accessible location on the drone. The kit comes with a mounting stand which means that it could be placed on top of the drone, away from RF noise, but there is no strict requirement for this. The safety switch on the GPS module must be easily accessible. See Airside Electrical Layout for wiring limitations.

Peripheral Sensors

Mech to add additional information on the remainder of the sensors locations.

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

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

Please see 2023-03-07 - Clarity on Electrical Components on Comp Frame . EE Team member to update with more specifics Daniel Puratich

General Wiring Guidelines

Subject to change depending on what Anni decides to throw at people

  • Servos connect to I/O Output and follow AETR, L->R

    • 1/2/3/4 Aileron (LO/LI/RI/RO)

    • 5/6 Elevator (LE / RE)

    • 7/8 Rudder (LR / RR)

  • Motors connect to FMU 1-5

    • Mot X : FMU X

  • FMU 6/7 for Aux Lighting

  • FMU 8 for Video Mux

  • Telem 1 → OSD

  • Telem 2 → RFD900x

    • will need external Power

  • CAN1 → Hereflow

  • GPS1 → M9N

  • VN300 → GPS2 OR Telem 3

Power Architecture

Electrical to update with batteries && actual rails. Note that some devices (cameras & transmitters) may need cleaner / dedicated rails.

The drone will run a 12S power system.

  • VBatt Dirty (For ESC’s)

  • 12V Dirty (For Flight Controllers & Jetson)

  • 5V Dirty (for servos, LED’s, etc)

  • 5V Clean (for VTX, Sensors, etc).

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) , while the clean power rail will be broken out of the 3s battery.

Wiring

All of the wires for the sensors will be pre-run through the frame in dedicated channels, with connectors left exposed near the sensor compartments and the avionics compartment. This means that any time a sensor needs to be replaced, we do not need to re-wire the entire sensor. this also means that when we need to re-wire the flight computers, we can use the cables that are already connected to the interface connectors an simply plug in a few large connector banks to our dev interfaces. Running more cables through the channels should be supported, but all necessary cables should hopefully be routed during assembly (or when it is easiest).

All sensors shall be connected to the respective device owners listed in the hardware components section. There will also need to be a single UART connection between ZP ↔︎ Jetson, as well as multiple (at least 5) communication wires available between the PX5 and ZPHW.

Connector Standardization

  • Gender Decoding

    • Gender conventions regarding what goes where are defined below.

    • Gender is defined by the metal conductors in all cases. Plastic housing should be ignored when deciphering gender. The manufacturer’s dictated gender decision takes preference over this, however, it will be clearly iterated here if that is the case.

  • XT series connectors are convenient, common in the hobby world, fairly reliable, and relatively cheap and will therefore be employed for all WARG DC power connections whenever possible.

    • COTS PCBAs after require solder pad connections which we will accommodate, but breakout to our prioritized connectors whenever possible.

  • XT60 connectors will be prioritized for any sub 150 A pulsed DC connection

    • For ESCs and anything smaller this should be prioritized

    • XT60-F is on batteries and so the XT60-F should be used on any voltage source and XT60-M should be used on any load. This gender convention is also used in the COTS world and keeps things simple.

      • Manufacturer PN Gender: “-F” is female & “-M” is male

    • Custom hardware will use XT60PW series connectors and follow the above gender convention.

  • XT30s will be avoided when possible for simplicity

    • While XT30s are smaller and meet our current requirements for lots of low voltage loads in order to minimize the amount of connectors we need to stock and use XT30s will not be prioritized when an XT60 can be used.

    • COTS loads and sources with XT30s will be adapted to XT60 through harnessing

  • XT90 connectors will be used for any greater than 150 A pulsed DC connections

    • COTS higher current 6S and above batteries often ship with these XT90s and so we will accommodate such a design decision as they are rated for the higher current.

    • Anti-spark XT90s should be used whenever possible to limit sparks from in-rush condition though this may not always be possible.

    • XT90 battery input splitting into ESC and converter connections should be done on a properly specified PCB with XT connections done in harnessing.

  • AC Mains is not used on any WARG aircraft and therefore a connector will not be specified

    • No voltage sources exceeding 55 V during nominal continuous operation are to be present on aircraft due to a lack of necessity and safety concerns

  • ESC BLDC Motor Controller Phase connectors will be specified in the future and require more decisions in the future.

    • 3.5mm banana connections is a solid option from the hobby world, but they can be a pain. Other size banana connections may be used as well on smaller aircraft as we come up with more specific decisions.

      • Gender Convention: Female on ESCs, Male on motors

    • Anderson Power pole series connectors are promising and have significant use in FRC, but will require validation before we fully adopt them in place of the ol' banana connectors

      • Gender is not present on these but ideally three different colors are used.

  • PWM Signal Connections

    • Should be done with with standard twisted PWM cables. Ideally locking stuff so it doesn’t pull out easily.

    • Simplest solution is often the best so sticking with these seems ideal.

    • Gender convention: Male pins on the signal generator and female sockets on the signal receivers.

    • We will use mechanical locking on the headers, copying how it is done in Vex to lock the PWM connectors into the board they connect to.

      • Where this is not viable we will defer to hot glue

  • Other low voltage signal connections

    • Debug versions should be done on standard 100mil pitch headers and jumpers

    • Flight versions should copy Pixhawk connectors whenever possible

    • Specific components will follow manufacturer recommended connectors if we for sure want to support it

      • i.e. the VectorNav VN-300 has it’s own connector we should just use since we are going to use this component on our system for sure!

    • If all the above do not offer adequate specification for a low voltage signal connector we will defer to automotive and marine standards and document here

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.

Custom Hardware Mounting Hole Specification

For general custom EE flight PCBAs going forward on ground station and aircraft we will follow this mechanical mounting hole specification:

M3 - Any PCBA with area exceeding 2500 mm^2

3.400mm hole diameter (0.1mm tolerance)

6.000mm annular ring diameter

M2 - Any PCBA with area exceeding 750mm^2 and less than 2500mm^2

2.400mm hole diameter (0.1mm tolerance)

4.200mm annular ring diameter

No Mounting Holes - Any PCBA with area less than 750mm^2

No mounting holes will be present on board of this size.

All Mounting Holes will follow:

Electrically not connected to the PCBA (frame is ideally floating potential)

Eight vias (plated drills) placed evenly in the annular ring (in whichever drill size is used on the board (so effectively left to EE in charge to decide on via size)) for mechanical stiffness.

Electrical components and electrically pads should be at least 1mm away from the annular ring to avoid damaging the PCBA when mechanically bolting the board.

Groundside Architecture

Anni to update this

Mandatory Hardware

Optional Hardware

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

Antenna Towers

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 is only applicable if the compute units are mounted

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

There will be three computers onboard the 2022-2023 competition frame <name>. Each of these has a dedicated purpose and will function in a specific subset of our flight route.

PX5

The PX5 Will be set as a real time backup, as well as potentially act as a sensor readout. The PX5 has 3 IMUs, 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. It does not strictly need to placed at COM since GQC can correct for this. Dhruv Upadhyay

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 communications and other functions of the drone, but allows for failsafe in case of a compute error inside of 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.

Communication with barometer data may occur over a serial link such as UART, depending on UART availability on ZP.

The communication to ZP will include the following:

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

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

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

  • 1 channel configuration plane/quad/hybrid

  • 1 channel autonomous 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.

Flight Stages

We can break the autonomous flight modes 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 Communications (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) 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.

In this state, all systems should be in low power mode in order to prevent overheating. To arm the drone, the following process should be followed:

  • Arm the hardware. During this step, the hardware will ensure that everything is proper and the drone is fit for takeoff

  • Arm the controller. During this step, the pilot & flight crew should verify that they are ready for takeoff & flight.

  • Arm the software. During this step, the software should be checking to make sure that necessary links are established and ready to kick into effect.

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

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.

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 heartbeat, 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, including waypoint ID=0 (GS’s knowledge of the current position of the drone).

Waypoints

A waypoint is a GPS coordinate paired with an ID number. The ID Number describes the sequence in which the drone is to fly waypoints. ZP will string together all the waypoints to create a flight path, where the final waypoint is the “hover” point and the transition to Search mode.

GS will send updated waypoints for the remainder of the route on a reroute, with waypoint ID=0 being the GS's knowledge of current position of the drone. This means that on a missed communication cycle, or on an updated diversion response, ZP will be able to dynamically re-route from the last known position of the drone to the next target waypoint without missing a waypoint since it can understand which waypoints it wants to hit and which waypoints it wants to skip.

Telemetry Data

Telemetry data consists of:

  • motor % values

  • Setpoints from the controller

  • current flight plan

  • attitude

  • battery voltages

  • sensor readouts

  • Mihir Gupta anything else?

GPS mode

The operator can override GS_SW to send a new list of waypoints for a custom route. ZP continues to directly pilot the drone in this mode. Once the drone reaches the final waypoint, it transitions to Search mode as normal.

Autonomous flight mode: Search

When ZP has arrived at the last waypoint and there are no remaining waypoints to travel to, 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, 2m left) if it sees the landing pad, or it will build a spiral search pattern and direct ZP’s movement until it can see the landing pad. See [CV Search] for technical details.

All direction commands sent to ZP are identical and include any direction in 3D space. 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 or rangefinder.

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 onto the pad. Auto-Land will be aborted after 3 failed communication cycles. At this stage, the drone shall return to a pre-determined height wherein landing requests will continue

Flight Control Modes

There will be a few distinct flight modes, each of which handles a portion of the flight. In each flight mode, the drone will process the controls differently.

GPS

GPS mode means that the drone will fly to a position that you specify. This can either be a GPS coordinate, or it could be relative coordinates that the drone well then rest at. This is how waypoints will be handled, and this is likely how most of the flight will be conducted.

LEVEL

LEVEL Mode means that the drone will self stabilize, but it will continue flying in the direction that you specify. Generally, this means that stick inputs will translate directly into a correspondent angle on the aircraft. This is likely how pilot manual flying will work.

ACRO

ACRO mode means that the controls control rate of rotation. It is unlikely that we will ever need to use this mode with a quadcopter, but it is possible that we will use this mode when doing an emergency takeover of a fixed wing aircraft to put it into a glide slope.

Communication

Communication between all devices will follow a standardized message format over UART (or serial) with a custom payload (so that is, retaining the regular UART start, parity, stop bits). See [UART] for more information.

Communication managers on each submodule should be responsible for decoding the incoming packets. We generally follow the HLDC frame protocol, which has the following structure:

Name

Size

Flag

1 Byte

starting byte for new message

Length

2 Bytes

Length of message (in bytes), including Type, Info, and CRC

Type

1 byte

type of the message. See Datatype Structs section for more information.

Indicates where data comes from and where it is meant to go.

Info

n bytes

one of the packets associated with the datatype struct.

CRC

4 bytes

CRC32 Val.

Datatype Structs

Please see Communication & Message Formats for defined datatype structs, they have been moved. Note that each struct has an associated internal number that tends to be used in our diagrams.

ZP-Jetson Communication

ZP-Jetson communication and states are defined here: ZP-Jetson Communication

Logging on ZP

Logging will be done using an SD card. It will either be on an SPI-Based carrier board or using SDMMC on the L5 pins directly. The former will be used if we fly on a nucleo, the latter will be used if we fly on zp.

Stanley Tang maybe add some more info on how logging might work?

Logging on Jetson

Log data on the Jetson will be recorded to the SD card containing the operating system.

🚀 Deployment Milestones

Fall 2022

  • ZP flying on ACRO mode fixed wing & LEVEL mode quad

  • ZP communicating with ground fully

  • Sensors ready to work

  • !?!?!?!?!??!?!?!

  • Nov 28: initial frame delivery & initial software delivery

  • Dec 20: See software-hardware integration, put in orders for everything that we will need for the next 4 months.

Winter 2023

  • Systems Integration Begins MID JANUARY

  • Competition Mock Flight MID FEBRUARY (maybe reading week or smth)

    • this is a hard deadline for software/hardware to be finalized. Past this point, we should stop development of new things and work on fixing / characterizing current things.

  • Multiple airframes ready mid-march

    • each airframe should be characterized and tuned. Pilots should be training on some of these models.

✅ Action Items

Action

Description

Owner

Due date

Jira ticket

1
  •  

2

Test Airframes

Cornflakes

Frosted Flakes

Wiring Diagram

^ quad H motor layout

  • fmu ports connect to escs for data. ports 1-5 connect to motors 4, 1, 2, 3, 5. in that order.

🗂 References and documentation

Version Date Comment
Current Version (v. 57) 2023-03-22 20:42 Anthony Luo
v. 67 2023-07-05 20:20 Amy Hu
v. 66 2023-04-07 01:07 Jack Greenwood
v. 65 2023-04-04 03:45 Jack Greenwood
v. 64 2023-04-04 03:31 Jack Greenwood
v. 63 2023-04-02 04:19 Ethan Abraham
v. 62 2023-03-27 23:57 Daniel Puratich
v. 61 2023-03-26 01:08 Anthony Luo
v. 60 2023-03-24 12:31 Anthony Luo
v. 59 2023-03-24 12:27 Anthony Luo
v. 58 2023-03-23 00:59 Anthony Luo
v. 57 2023-03-22 20:42 Anthony Luo
v. 56 2023-03-14 14:34 Anthony Luo
v. 55 2023-03-13 00:15 Anthony Luo
v. 54 2023-03-08 00:40 Anonymous
v. 53 2023-02-16 17:15 Daniel Puratich
v. 52 2023-02-16 14:55 Daniel Puratich
v. 51 2023-02-16 14:49 Daniel Puratich
v. 50 2023-02-15 19:14 R D
v. 49 2023-02-15 19:13 R D
v. 48 2023-02-15 19:08 R D
v. 47 2023-02-11 01:36 Anthony Luo
v. 46 2023-02-11 01:35 Anthony Luo
v. 45 2023-02-10 02:27 Anthony Luo
v. 44 2023-02-07 23:11 Anthony Luo
v. 43 2023-02-06 23:10 Anthony Luo
v. 42 2023-01-23 23:29 Anthony Luo
v. 41 2022-12-02 15:14 Anthony Luo
v. 40 2022-11-27 16:26 Anthony Luo
v. 39 2022-11-14 15:17 Anthony Luo
v. 38 2022-11-10 03:46 R D
v. 37 2022-11-08 03:09 Megan Spee
v. 36 2022-11-07 14:18 Anthony Luo
v. 35 2022-11-07 14:15 Anthony Luo
v. 34 2022-11-07 14:14 Anthony Luo
v. 33 2022-11-07 13:18 Anthony Luo
v. 32 2022-11-07 03:42 Megan Spee
v. 31 2022-11-06 05:21 Megan Spee
v. 30 2022-11-06 04:52 Anthony Luo
v. 29 2022-11-06 01:56 Anthony Luo
v. 28 2022-11-06 01:55 R D
v. 27 2022-11-06 01:21 R D
v. 26 2022-11-05 21:12 Anthony Luo
v. 25 2022-11-05 20:50 Anthony Luo
v. 24 2022-11-05 20:29 Sahil Kale
v. 23 2022-11-05 19:38 Anthony Luo
v. 22 2022-11-05 05:32 Neha Srivastava
v. 21 2022-11-05 04:37 R D
v. 20 2022-11-04 05:26 R D
v. 19 2022-11-04 05:25 R D
v. 18 2022-11-04 04:21 Anthony Luo
v. 17 2022-11-04 04:14 R D
v. 16 2022-11-04 01:43 Mika Shaw
v. 15 2022-11-04 00:38 R D
v. 14 2022-11-03 22:10 Anthony Luo
v. 13 2022-11-03 13:12 Anthony Luo
v. 12 2022-11-03 12:43 Yuchen Lin
v. 11 2022-11-03 12:40 Yuchen Lin
v. 10 2022-11-03 03:26 Anthony Luo
v. 9 2022-11-03 00:48 Nathan Green
v. 8 2022-11-03 00:42 Anthony Luo
v. 7 2022-11-03 00:38 Anthony Luo
v. 6 2022-11-03 00:21 Anthony Luo
v. 5 2022-11-03 00:20 Anthony Luo
v. 4 2022-11-03 00:19 Anthony Luo
v. 3 2022-11-03 00:15 Anthony Luo
v. 2 2022-11-03 00:15 Anthony Luo
v. 1 2022-10-21 15:26 Anthony Luo
  • No labels