-
Notifications
You must be signed in to change notification settings - Fork 2
1. System overview and software structure
At the time of writing, the SUAS 2025 rules haven't been released yet, and so the following section is subject to change. The SUAS competition is designed to foster interest in Unmanned Aerial Systems (UAS), stimulate interest in UAS technologies and careers, and to engage students in a challenging mission. The UAS is generally composed of a ground station and an Unmanned Areal Vehicle (UAV, aka the drone). The mission specifics change every year, but in general the mission tasks require that:
- The UAV must be able to autonomously perform a lap in the airfield, staying within mission boundary, and avoiding obstacles such as trees and other UAVs
- There may be up to 3 other UAVs in the airfield at the same time
- The mission boundary is revealed within the rules, published around September
- The mission lap way points are revealed during mission setup time, the day of the competition (around June)
- The UAV must perform airdrops on specific targets autonomously
- Targets are objects such as paper cutouts of different shapes or mannequins, found on the ground within a survey zone.
- Like the mission boundary, the coordinates of the survey zone are revealed within the rules, published around September.
- The payload, which is a small plastic water bottle, must reaches the target undamaged (lowered gently).
- There are also the following constraints
- The UAV must perform a lap before performing the airdrop.
- The UAV must stay within a height range at all times outside of the takeoff area
- In 2024's SUAS rules, the height range was 75 to 400 feet Above Ground Level (AGL)
- There are 5 airdrops to perform to get the maximum amount of points.
- There is a time limit for the mission.
- Going above that time limit will lead to penalties, but is allowed
- In 2024's SUAS rules, the time limit for the mission was 30 mins
- There is a limit to the number of people allowed to interact with the drone during the mission (Operators).
- Having more operators will lead to penalties, but is allowed
- In 2024's SUAS rules, the number of operators allowed without penalties was 2
There are other parts to the competition that are not the mission, such as the flight review or the mission setup, which would be too long to mention and not too relevant for the software team.
More information on the competition and the rules can be found in the SUAS website and I strongly recommend that you read through the rules as they will dive into the rest of the details and cover other critical parts that the above points don't mention.
A UAS is generally composed of 2 parts, the UAV (aka the drone) and the ground station.
- UAV
- In general:
- Flight related sensors, such as GPS, airspeed sensor, etc.
- Flight related actuators, such as motors, servos, etc.
- Other flight related components such as batteries, Electronic Speed Controllers (ESCs), telemetry radio, RC receiver, etc.
- Flight Controller, a micro controller flashed with the autopilot of choice
- The flight controller is the hardware, the autopilot is the software (also called the firmware)
- The actuators and sensors mentioned above connect to the flight controller
- The autopilot on the flight controller interprets sensor data which it uses to monitor the drone
- It also sends telemetry information the ground station through the telemetry radio (Using the MAVLink protocol)
- The autopilot on the flight controller then controls the actuators in order to satisfy whatever its current goal is, such as taking off, holding a position, going to a position, etc.
- We will use CUAV pixhawk as our flight controller
- We will use PX4 as our autopilot
- For autonomous flight:
- Autonomous flight is acheived by having a computer onboard the UAV, called the offboard computer (since its offboard with respect to the flight controller) or companion computer, which sends position commands to the flight controller.
- Thus, without the need for human input, the UAV will be able to perform waypoint to waypoint navigation.
- The offboard computer is connected to the flight controller to establish a communication link that allows it to monitor the state of the drone and to give the flight controller commands.
- This is done through the TELEM2 port of the flight controller and the TX/RX pins of the companion computer for the PX4 autopilot, Here is a tutorial
- The companion computer is where our code will be running
- By having the companion computer and the ground computer on the same Local Area Network (LAN), we could ssh into the companion computer, to either start our code, see debug messages, or do whatever we want to do from the terminal
- For our specific needs:
- We need to do things such as avoiding obstacles, detecting targets and performing airdrops
- This will require additional hardware, that will connect to the companion computer, as they do not relate directly to the task of flying to a given way point.
- This additional hardware may be cameras, lidar sensors, or an extra micro controller, whose task is to give the companion computer a higher level interface for the airdrop mechanism.
- In general:
- Ground Station
- In general:
- QGroundStation is a 3rd party program that shows standard UAV data in a graphical form, things like the drone's position, the mission boundary, etc.
- A ground telemetry module, connected to QGroundStation, establishes a communication link to the UAV's flight controller.
- Pre filght, helps setting up various flight controller settings, such as max pitch rate, maximum horizontal velocity, etc.
- Pre flight, facilitates uploading a mission (waypoints, with a mission boundary) to the flight controller.
- Shows the UAV's position, velocity and other information that may be relevant
- Send UAV commands
- QGroundStation is a 3rd party program that shows standard UAV data in a graphical form, things like the drone's position, the mission boundary, etc.
- Other information that are specific to our project will require custom software to showcase, things like the current target or the current state of the airdrop controller (DROPPING or IDLE).
- Ideally we would merge both general and use case specific information into one GUI, but such a task is not necessarily required and may be more trouble than its worth
- If this is of interest to you, please let me know (Imad, the software lead)
- We may also want to ssh into the offboard computer, to run whichever script starts the program and to get more control over the offboard computer. This is possible as long as the ground computer is in the same LAN as the offboard computer.
- A safety pilot is also an essential part of a ground station, which is a person capable of taking over control of the UAV and capable of flying it safely. This is done through an RC transmitter
- In general:
In 2024, the drone team wanted to make a VTOL UAV, a drone capable of both fixed wing and quad copter flight. This was scrapped much later into the year for a quadcopter only UAV. Thus, there may be a discrepancy between the following concept model and the code you will find in the drone 2024 repo. We also had to abandon obstacle detection as a lidar is not the best sensor for such a task on a UAV.
The fancy diagram above showcases the various parts of the program needed to satisfy the specific use case, shown as the rectangles, the way they connect/communicate with each other, shown as the arrows/edges, and the external actors/facilitators, shown as the little stick people.
At the end however, it looked more like the following diagram:
This diagram represents the various ROS 2 nodes at play and their topics/services. If you have never used ROS before, you may have trouble understanding the diagram, see the tutorial section of ROS 2 before trying to make sense of it. The circles represent nodes and the boxes around them are the package that contains them in the drone 2024 repository. The parallelograms are topics, in which an incoming arrow means publishing to the topic, and an outgoing arrow means subscribing to the topic. Non ROS nodes that may subscribe/publish to a topic or other hardware are represented as little stick people. The types used by each topic can be found either in px4_msgs if they relate to px4's MicroXRCE topics, custom_msgs if they are use case specific or the various message types that come by default with ROS.
To come :D