Competition Year | 2022-2023 Aerial Evolution of Canada Student Competition | ||||||
|---|---|---|---|---|---|---|---|
Team | Waterloo Aerial Robotics Group | ||||||
Architect(s) | |||||||
Status |
| ||||||
Last date updated | by Anthony Luo | ||||||
On this page |
|
...
[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].
...
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?
Cruise
In During cruise mode, the groundstation will continue sending a list of waypoints to the drone . 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.
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.
...
Communication Message Formats | |||
|---|---|---|---|
Message Type (Bits) | [message name] description | Expected Uses | |
0001 | [position] Position only data | GSPC → Tracking Towers ZP → Jetson | |
| Code Block | 0010 | [waypoints] Full List of waypoints | GSPC → ZP |
0011 | [Telemetry] Full telemetry struct | ZP → GSPC | |
0100 | [movement request] Relational movement request | ZP → Jetson | |
0101 | [movement command] Relational movement command | Jetson → ZP | |
Datatype Structs
0001 - Position Only Data Mostafa Hussein
| Code Block | ||
|---|---|---|
| ||
// could this just be the LOS_Pos struct? |
0010 - Full List of Waypoints
| Code Block | ||
|---|---|---|
| ||
struct TelemWaypointData { double longitude; // 8 byte double lattiude; // 8 byte uint8_t waypoint_id; // 1 byte }; typedef struct CommandsFromTM{ bool start_landing; // 1 byte |
...
uint8_t num_waypoints; // |
...
1 byte TelemWaypointData waypoints[num_waypoints]; } CommandsFromTM; |
0011 - Full Telemetry Struct Mihir Gupta
| Code Block | ||
|---|---|---|
| ||
// No clue what |
...
we |
...
include |
...
in telemetry |
0100 - Relational Movement Request
| Code Block | ||
|---|---|---|
| ||
struct ZpToJetsonLandingRequest { |
...
uint8_t |
...
request; |
...
} |
0101 - Relational Movement Command
| Code Block |
|---|
struct JetsonToZpMovementCommand { |
...
float x; |
...
float y; |
...
|
...
|
...
float z; |
...
float heading; |
...
} |
...
[waypoints] Full List of waypoints
...
GSPC → ZP
...
[Telemetry] Full telemetry struct
...
ZP → GSPC
...
[movement request] Relational movement request
...
ZP → Jetson
...
[movement command] Relational movement command
...
Logging
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.
...