NASA QGroundControl Station - USS Design Challenge

Welcome to the “NASA QGroundControl Station - USS Design Challenge”! The scope of this challenge is to add a new feature to the NASA Ground Control Station (NGCS) called a USS (UAS Service Supplier). This feature reserves airspace volumes for safe flying.  NGCS is a software that will be used for safe live flight operations, while also providing functionality for researching advanced algorithms and human-automation teaming concepts.

By building upon the foundation of a trusted open-source GCS software (QGroundControl), the NASA GCS can leverage existing safety and testing while adding experimental features. We have designed the NASA GCS interface in a previous challenge and we’ll continue to build on that solution.

Please read the challenge specifications carefully and let us know if you have any questions in the forums.

Note: As the previous design was built on Sketch, we will only allow Sketch and XD source files for this challenge. You will be expected to use those source files. For using XD, you can open the source files and work on them as usual due to their compatibility.

Round 1

Submit your initial designs for checkpoint review. Feel free to add any screens which are necessary to explain your concept.

1. USS Server
2. Generate and Request Airspace Volumes
3. Send and Display My Vehicle Position
4. Send and Display Other Vehicle Positions

Round 2

Submit your final designs plus checkpoint feedback implemented. Feel free to add any screens which are necessary to explain your concept.

1. USS Server
2. Generate and Request Airspace Volumes
3. Send and Display My Vehicle Position
4. Send and Display Other Vehicle Positions
5. Close Operation
6. Send Contingency Plan

Challenge Objectives

• Desktop application for Windows 10 (however the application will work on all platforms)
• 6 screens to be designed
• The design will be based on the previous design for the NASA GCS software
• The design should be focused more towards touch interactions than desktop mouse interactions (similar to QGroundControl, that NGCS is based on)
• The UI is assumed to be viewed on the large size viewport specified (1920px x 1080px). Please consider that in your designs and export files at this size.
• Focusing on a single drone scenario only

Application Overview

• The purpose of this challenge is to add a new feature to NASA GCS, called a USS which will be used to reserve airspace volumes for a period of time while flying. (Similar to an airplane submitting a flight plan)
• The USS will broadcast to all the other flight operators the reserved airspace so they don’t plan to fly in the same area at the same time.
• At the current moment, a drone is not being able to fly beyond visual line of sight. The USS will solve that problem by keeping vehicles safe to fly on separate paths and in separate areas.

Audience

• NASA employees who use drones for live flight operations, and to provide functionality necessary for researching advanced algorithms.

Persona

• Name: Mike
  • Occupation: NASA drone researcher
• Goals:
  • Fly his drone in the airspace on the defined path and being confident that there will be no collision with other vehicle
  • See the flight plan volumes and status of other vehicles from the USS
• Frustrations:
  • Not being able to exchange information with other drones related to their areas of flight
  • Can’t fly the drone beyond visual line of sight (the user has to be able to see it all the time)
  • Can’t see if other drones are departing their flight volumes and a potential conflict can happen
  • The USS is not part of NASA GCS
• Wants:
  • A way to autonomously communicate with other drones about their reserved airspace to fly to avoid any conflict
  • The ability to fly his drone safely
  • Integrate the USS with the NASA GCS

User Story
Mike is using the NASA Ground Control Station (which is based on an open source, QGroundControl software) to launch his drone, set up its trajectory and track it. QGroundControl (QGC) can run flight simulations with virtual drones or real drones.  

Once the drone is launched, Mike can create waypoints to define a specific path or open a file to load a predefined path. He logs in to the USS server and then sends a request to make an airspace reservation for that path for a period of time. His request is either rejected or approved. (The request may be rejected if the submitted airspace reservation conflicts with another vehicle’s airspace reservation.) If the request is approved, once the vehicle is in the air, it will continue to send his position every 3 seconds to the USS. The USS will use this information to make sure that the drone is staying within the allocated space volume. Mike can also see other vehicles' positions, flight plan volumes and statuses.

Mike will also send contingency plans (additional areas he might need to use in case of an emergency. For example: ditch sites). When the drone has landed and is disarmed, the reservation will be closed.

Design Goals & Principles

• Base your design for this challenge on the previously designed NASA GCS interface
• Any elements newly added should look as they belong to the existing application (follow same design style)
• Keep in mind that the main OS for this is Windows 10, however the application will work on all platforms
• The design should be more focused on touch interactions than desktop mouse interactions (similar to QGroundControl)

Exploration Score
In terms of expectations, we would like to measure the concept against the following in the one to ten scales:

• Creativity: 3
  • 1: barely new ideas
  • 10: a utopic product with features not proven to be able to be fully implemented
• Aesthetics: 8
  • 1: low-fidelity design, wireframe or plain sketch
  • 10: top-notch finished looking visual design
• Exploration: 1
  • 1: strictly follow an existing reference or production guideline
  • 10: open to alternative workflows/features not listed here that would help the overall application
• Branding: 7
  • 1: don’t care at all about the branding just functionality
  • 10: without a properly branded product there is no success

Glossary
GCS = Ground Control Station is a control software for Unmanned Aerial Vehicles (UAVs also named drones). The hardware includes the Human-Machine Interface, computer, telemetry, video capture card and aerials for the control, video and data links to the UAV. You can see some examples here.

NGCS = NASA Ground Control Station

QGC = QGroundControl - is an open-source software that provides full flight control and mission planning for drones. NASA Ground Control Station will be built on it to leverage existing safety while adding experimental features.

Waypoint trail = represents the vehicle flight plan and consists of several points with coordinates where the drone will fly through

Ditch sites = safe areas to land in case of an emergency such as battery running low or important vehicle issues that prevent it from continuing along the flight path

Site = refers to location/ position of a drone landing area in this context

Vehicle = it’s used for referring to a drone in this challenge

UAS = Unmanned Aircraft System is a drone and other vehicles flying without needing a human on board

USS =  Unmanned Aircraft Systems (UAS) Service Supplier  -  it’s the main component for NASA’s air traffic management system for drones

UTM  = UAS (Unmanned Aircraft System/ drone) Traffic Management System

Contingency plans = are additional volumes of air the user is not reserving, but letting everyone know that he might use those in case of emergency (they are the volume airspace for safe ditches)

BVLOS = Beyond Visual Line of Sight, refers to flying a drone beyond the area you are able to see


Background
Note: This is background information for your understanding. You do NOT need to design how the connection is happening. Only design the required screens listed below.

The NASA Ground Control Station is built upon the foundation of a trusted open-source GCS software (QGroundControl), to leverage existing safety and testing while adding experimental features.  QGroundControl (QGC) is an open-source GCS that provides full flight control and mission planning for drones. The software is designed to provide a single codebase that can run across multiple OS platforms and devices. We are going to focus on Windows 10 OS.

Another open-source GCS software that is similar to QGC, and can be referenced for implementation ideas, is ArduPilot Mission Planner. Mission Planner is only mentioned here for reference. It will not be integrated with the NASA GCS.  

QGC doesn’t have simulation capabilities built in now. However, in order to do simulations we use the ArduPilot Mission Planner to get the vehicle running, and then connect with QGC to track all data. To set up your vehicle, follow the steps from this video.

We have recently run a challenge to design the NGCS interface and add ICAROUS feature to detect and avoid collisions. In this challenge we are focusing on the USS feature.

NASA is researching prototype technologies such as airspace design, dynamic geofencing, congestion management and terrain avoidance for a UAS Traffic Management (UTM) system that could enable safe, efficient low-altitude operations. Drones can fly now from 0 to 400 ft altitude, space which is considered safe as the airplanes are flying above it. Also they are not allowed to fly near airports for the same reason. Check this illustration.

Right now, when a user wants to fly a drone it cannot go BVLOS (Beyond Visual Line of Sight). With the new UTM system, NGCS users can login to a USS server, submit flight plans (as a collection of airspace volumes), send vehicle state data, and see all other nearby vehicle flight plans and states.

When the drone is in disarmed mode, the user will connect to the USS and the NGCS will convert his waypoint file into a wayspace volume with height of maximum 400 ft altitude and a tube for the volume space or a box representation. This volume will be submitted to the USS as a reservation for a period between 5 minute to 1 hour. The USS will send a message for approval and also broadcast to other vehicles about our drone’s volume reservation so they don’t fly around that area in that time interval.  When a reservation is completed, the user will close the reservation and the USS will confirm, at which point the reservation will be removed.

You can read more about how the USS works here:

• UTM Service-Based Architecture Illustration (note that “UAS Service Supplier” is the USS in our case, the “UAS Operators” are NGCS and other GCS systems, and “UAS” are the drones)
• Example USS Developed by NASA
• UTM Concept of Operations
• UTM Media Day
• Do your research about the USS and other UAS softwares that might be out there

As the previous design was built on Sketch, we will only allow Sketch and XD source files for this challenge. You will be required to use and build on these original source files. For using XD, you can open the source files and work on them as usual due to their compatibility. Download from here the source file from the previous challenge.

User Flow
Here’s the entire user flow that includes the flight path creation, creating ditch sites and generating airspace volumes (note: you don’t need to design all these screens, it’s just to provide context):

1. User makes flight plan and uploads it to the vehicle (Plan View)
2. User adds ditch sites and uploads them to the vehicle (Plan View)
3. User switches to Fly View as they are preparing for takeoff and doing preflight checks (external to GCS)
4. From the Fly View, the user presses the "Submit Operation" button in the USS widget, and the NGCS then (in one action) converts the waypoint plan into airspace volumes and sends the request to the server. While this is happening, the user can see the volume outline around their flight plan (this is a toggle feature to show the volume outline before the user submits)
5. If the operation is accepted, the user sees the volume on the display as "Accepted"
6. The user arms the vehicle, which starts sending the position data to the server and the operation status then changes to "Active"
7. After landing, the operator would press the "Close Operation" button

SCREENS REQUIREMENTS

1. USS Server (fly view)
The USS will be displayed like a widget, similar to ICAROUS to keep the modular functionality of NGCS. In the settings section of this widget, the user is able to provide the host URL (for the USS server), username and password. This should be saved between different NGCS launches. The user should then be able to attempt to connect to the USS server. The status of this connection should be visible during flight operations. The user should also be able to disconnect from the server in the settings view. Next time, the user could connect with the saved information. He would not need to enter URL, username and password to connect.

2. Generate and Request Airspace Volumes (fly view)
Before generating airspace volumes, the user will set the flight duration and volume radius. The volume radius will not be changed very often, but the user will need to have the ability to change it in special cases.

The NGCS shall be able to generate airspace volumes from the current loaded waypoints and submit the operation to the USS.  This can be a toggle feature to show the volume outline before the user submits. These actions should happen together when the user presses the Submit Operation button. The NASA GCS should show the status of the submitted operation. The request status will be obtained via the websocket connection established during login. There may be a slight delay while the USS processes the request.

The USS will approve the airspace reservation and will broadcast to all other drones in that area about the position and flight plan (i.e. airspace reservation). The USS would deny the reservation request only if another drone’s airspace volume is overlapping ours at the same time. In this case, it will send a message. At that time, the user can decide to change its flight path or adjust the radius of volume, and resubmit the request.

3. Send and Display My Vehicle Position (fly view)
The NASA GCS should have the option to start sending the vehicle position when the autopilot is armed (checkbox or switch “Send Positions when Armed”). If the vehicle has a reservation, it starts sending the position every 3 seconds. It must continue sending positions until the operation is closed. If the USS goes longer than a set time period (about 3 seconds) without an update, the vehicle status will change to “non-conforming”. The vehicle could also become “non-conforming” if it moves outside of its airspace reservation.

If the vehicle status remains “non-conforming” for a set time period, the vehicle status will change to “rogue”. Once the status is “rogue” it cannot be changed until the vehicle lands and closes the operation. If the status is “rogue” the other vehicles will pay attention to it and know this drone is not following rules and it might disrupt their volume reservation.

The NASA GCS should display the current reservation volumes as two-dimensional boundaries on the map view. These boundaries should display for each vehicle controlled by the NGCS (example here - note: ignore the blue rectangle in this image). Here are another 2 representations of airspace volumes: example 2, example 3 (you can get more context about these examples from the UTM Concept of Operations.pdf, page 36 and 38).

The design should also include some representation of the vertical dimensions (altitude) of the vehicle’s airspace volumes. This could possibly be shown in the “Terrain / Altitude” widget. We’re interested in seeing creative ideas for this.

The NGCS should also display the current status of the vehicle in the USS widget and on the map view (by changing colors of the volume reservations). The status of my vehicle / airspace reservation should cause the color of the reservation volumes to change. Standard colors for implementing with the vehicle are listed. But, we would be interested in seeing other color ideas if you feel there is a more suitable option.

Status = standard color:

• Approved = Light Blue / Cyan
• Active = Light Pink / Magenta
• Non-Conforming = Orange
• Rogue = Red
• Closed = White

4. Send and Display Other Vehicle Positions (fly view)
The GCS will be able to read and display traffic positions, flight plan volumes, and statuses for other vehicles in the area from the USS (example here). The NASA GCS should display the current reservation volumes as two-dimensional boundaries on the map view for each traffic vehicle received from the USS. We are not interested in a 3D representation of the volumes of space. The GCS should also display the current status of the vehicle (For example: non-conforming, rogue, etc.) with the traffic vehicle state data. The status of the vehicle should cause the color of the reservation volumes to change. The colors can be the same as those for my vehicle, but we are also interested in seeing other color ideas if you feel there is a more suitable option.

5. Close Operation (fly view)
The NASA GCS should have a button to close the current flight operation. The NASA GCS should show the status of the closed operation.
Close Reservation: When the reservation is completed, the user will have the option to close the reservation. The USS will respond to confirm, after which the reservation will first turn white and then be removed after several minutes.

6. Send Contingency Plans (fly view)
The contingency plans are additional volumes a user will submit to the USS to extend their area from the flight plans to other areas. These added volumes are not reserved, but they are added to notify others that if there is a problem or emergency situation, these are the areas he will fly to. These plans are mapped to the ditch sites. This feature should include a button to update contingency plans (based on current Safe2Ditch ditch sites) and a button to remove all contingency plans. When the user has an airspace reservation that is “Approved” or “Active”, they should have some indication on the map and/or in the USS widget that either confirms all Safe2Ditch ditch sites have been sent to the USS or shows that they have not been sent.

Assets
You can find all assets mentioned above in this Google Drive folder.

Branding Guidelines

• Follow the NASA branding for colors only and logo
• Use the NASA Logo from here
• Fonts: use same fonts as in the provided source files
• Icons: try to keep the look and feel close to what we have now for our current design to keep the consistent look and feel and avoid any safety issues.

Size

• Desktop: 1920px x 1080px (width x height)
• Note: when saving your files, DO NOT export at 4K size. Export them at 1920px x 1080px

Stock Photos and Icons

• Photos are not allowed in this challenge
• Icons: you can only use icons that are free (based on Topcoder icons policy) without giving attribution or design the icons yourself. If the icons are not free, we will ask them to be fixed in the final fixes.
• Fonts: use same fonts as in the provided source files

Marvel Prototype

• Upload your screens to Marvel App.
• Send your marvel app request to keyla. blue1@gmail.com or ask in the forums
• Include your Marvel app URL as a text file in your final submission. Label it “MarvelApp URL”.

Final Deliverables

• An archive called Source.zip file to include:
  • All original source files created in Sketch and XD in an archive called
•  An archive called Submission.zip file to include:
  • All your design files in PNG or JPG format
  • MarvelApp link for review and to provide feedback
  • Your declaration files to include any notes about fonts usage, photo and icon declaration and link to your Marvel project
• Create a JPG preview file of 1024 x 1024 px