Challenge Overview
Challenge Introduction
We are beginning a long term series of challenges to create a new version of a ground control station for small unmanned aircraft systems (sUAS; i.e., drones) based on QGroundControl. The ground control station will allow the UASs to be safely used for live flight operations while also providing the functionality necessary for researching advanced algorithms and human-automation teaming concepts.
Challenge Objectives
-
Update the GCS to display ICAROUS status with the vehicle state data.
-
Update the GCS to receive and display heading band data from ICAROUS running on the vehicle.
Technology and Frameworks
-
QGroundControl
-
C++
-
QT
-
Qt QML
-
-
ArduCopter simulator
-
MAVLINK
-
MAVProxy
-
Simulation
-
Docker
Code Access
You will find the link to our existing repo and instructions on how to access it on the challenge forum, available after registration.
Individual Requirements
ICAROUS (Independent Configurable Architecture for Reliable Operations of Unmanned Systems) is an open-source software architecture that is primarily used for detect and avoid (DAA) and geofencing capabilities (https://github.com/nasa/icarous) onboard small UAS (i.e., drones). ICAROUS interacts directly with the autopilot on the vehicle and can be run with a simulated vehicle using a SITL (software-in-the-loop) simulation (https://nasa.github.io/icarous/setup.html).
As part of this challenge, you need to integrate the QGroundControl app with ICAROUS in order to:
1. Display the ICAROUS status
1.1. You need to introduce a new configuration section in the app’s General configuration page. This new section will be named as `ICAROUS` and it will have a single checkbox with the label `Display ICAROUS information`. By default, this will be set to true and the user should be able to change it and the changes should be persisted.
1.2. When the ICAROUS feature is enabled in the NASA GCS, the area displaying the vehicle state data should also show the status of ICAROUS onboard the vehicle. This could be based on a MAVLink status message from ICAROUS, or if that is not possible, it could be based on whether or not ICAROUS messages have been detected.
You may refer to the WebGS code as a reliable source of information to understand how the data should be received and interpreted (https://github.com/nasa/webgs).
2. Display heading band data from ICAROUS (running on the vehicle)
When ICAROUS is running on the vehicle and configured correctly, it will send heading band data to the GCS. This data is meant to show the directions that should be avoided to prevent a collision. This data should be presented as a circle with green and red arcs that surround the vehicle that is currently running ICAROUS (see Figure 6). The MAVLink messages for ICAROUS are defined (https://mavlink.io/en/messages/icarous.html#ICAROUS_FMS_STATE), but these definitions may be outdated.
Again, use the WebGS code as a more reliable source of information to understand how the data should be received and interpreted (https://github.com/nasa/webgs).
Since we are not using any actual devices, you’ll be running a simulated device as well as ICAROUS on docker using our existing docker setup (details on the challenge forum). In order for ICAROUS to send different types of heading bands, you’ll need to simulate a collision scenario with two simulated vehicles (the other vehicle does not need to have ICAROUS functionality). You will probably have to update the docker env in order to achieve this.
As an optional requirement, you need to match the newly created widget/sections with the provided storyboard (attached to the forum). If you choose to implement this requirement, you will need to match the provided designs as close as possible and you will be scored for that.
If the winning submission has implemented this requirement, it’ll receive a bonus payment of $100
Should you have any doubts, please feel free to ask on the challenge forum.
Useful References
Final Submission Guidelines
Please submit a zip file that includes:
-
A patch file for the latest commit of the master branch of the QGroundControl repo.
-
A patch file for the latest commit of the develop branch of the docker-env repo in case you make any changes there.
-
A txt file with instructions on how to apply your patch and any other information that may be needed in order to test your submission.
-
Optionally, a video showing your submission in action.