The use of small autonomous Uncrewed Aerial Systems (sUAS) for Emergency Response requires rapid deployments into shared operational environments which we refer to as ``Pop-up Drone Zones'' (PuDZ). PuDZ represents a System of Systems (SoS), in which individual systems provide services such as air traffic control, environmental modeling, and support for sUAS autonomy.
Each system needs the ability to configure itself dynamically at the start of the mission, and self-adapt throughout the mission in response to environmental changes, emergent problems, and changes in the overall mission status. Each system is self-managed, using its own local MAPE-K loop, and can, therefore, adapt independently; however, adaptations in one system can have a trickle-over effect to other systems.
The tests reported on this page were conducted with four HX-10 drones (shown on the right) and were used to illustrate and validate various cross-system self-adaptation scenarios with physical and/or simulated sUAS.
Test | Description | Pattern | Triggering System |
---|---|---|---|
T1 | Mission state transition during normal operation | P1 | sUAS (Auton. Pilot) |
T2 | sUAS-A detects and tracks a person | P1 | sUAS (Comp. Vision) |
T3 | sUAS-A detects and sUAS-B tracks person | P2 | sUAS (Comp. Vision) |
T4 | sUAS misses heartbeat from GCS | P1 | sUAS (Monitor) |
T5 | EDS and Air-Leaser adapt due to high winds | P3 | EDS (Weather) |
T6 | Air-leaser adapts to grid layout | P3 | Air-Leaser |
T7 | Compass interference onboard sUAS | P3 | sUAS (Analytics) |
T8 | Human requests extended PuDZ Boundaries | P3 | EDS (boundaries) |
T9 | Ill-formed mission detected. Mission aborted | P3 | SoS Policy Manager |
T10 | FAA Part 107 flight regulation violation | P3 | Runtime Monitor |
Note: For help in interpreting mission specifications please see this link.
The test validates that the sUAS is able to transition effectively through a series of states. This is an example of internal system self-adaptation. The sUAS uses an internal MQTT system to coordinate transitions through the mission states. In particular, it demonstrates a 'phased circle', meaning that the drone flies around a specified part of a circle (as developed to support an image collection project at high altitude and distance). This test demonstrates transitions between many states including arming, takeoff, hover, fly-to-waypoints, phased-circle, land, and disarm.
- Video: T1 Field test video
- Flight Log: T1 Field test flight log
- Mission Specification: T1 JSON Specification
The test validates that the sUAS can transition states from 'search' to 'survey' when the onboard computer vision pipeline detects a person. One the person is detected, the sUAS computes the persons geolocation and circles around them. We are still working on accurate geolocation and have a solution ready to test once weather becomes warm. In this video, the adaptations work as intended.
- Video: T2 Field test video
- Flight Log: T2 Field test flight log
- Mission Specification: T2 JSON Specification
In this version of the test, we mimic sUAS-A detecting a person by publishing the coordinates of the found person to MQTT as: (MESSAGE HERE). sUAS-B subscribes to this topic and self-adapts from `flying' state to 'circle' state around the coordinates.
- Video: T3-Video
- Flight Log
- Mission Specification: T3 Specification
In this test, we added a new failsafe state (not shown in the JSON file as it is a default state for all states and therefore doesn't need to be specified by the user). When the heartbeat is lost then the drone transitions into heartbeat hover, and eventually if the heartbeat is not restored, it transitions into RTL.
- Video: T4-Video
- Flight Log: (Test executed correctly, but in this version it introduced a strange character into the flight log making it unreadable. New version is lined up for testing in the Spring).
- Mission Specification: T4 JSON Specification
In this test we mimic the adaptation of the EDS due to high winds. We publish a high-wind alert, and the air-leaser adapts by increasing the separation distances between sUAS.
- Video: T5-Video (Two sUAS flight, but no videos available of the air-leaser tests below.)
Drones fly to opposite ends of the runway, hover for 20 seconds, and then request air-space to fly near to the current location of the other drone. The expected outcome is that drones should deadlock and be stuck in hover. Both drones should continue requesting an air lease from the ground service and continue to be denied indefinitely until pilot takes over.
- Mission Specification:
Four drones are lined up South of the runway approximately 15-20 meters apart. Each one is given a flight plan to take-off, fly south to a waypoint, hover for 20 seconds, and return home. We expect to see all drones take off sequentially as they request leases, since they are positioned at spots greater than 21 meters. If there is an airlease error, they will not all take off. By progressively adapting the air-leaser's spacing plan, different outcomes are observed in terms of which sUAS take off in which order.
- Mission Specification:
The air-leaser adapts its layout due to high congestion. We have tested this in a low-fidelity simulator and not with the PX4 physics engine.
Onboard anomaly detection was tested for vibration with the high-fidelity Gazebo simulator. We demonstrated that it could be detected in real-time and lead to adaptations e.g., reduce throttle, LOITER, LAND. Currently being ported to physical sUAS.
Onboard anomaly detection courtesy of Md Nafee Al Islam.
This tests whether a change in PuDZ boundaries causes routes to be adapted. The image shows the GUI that is currently used to modify a search region which delimits regional searches. The fully self-adaptive solution is still under development as we currently have not implemented route reconfigurations during flight. The autonomous pilot has been designed to self-adapt routes, but some additional development and test is needed for full validation in the field.
This `test' was accidental. It was the result of several compounding errors and has been officially reported to the NASA sUAS incident service due to the high altitudes (over 400ft AGL). We had set up a geofence, but for some reason the geofence action was re-set to 'no action'. When the sUAS hit the geofence, it transitioned to STABILIZED mode and control was ceded from the onboard autopilot to the RPIC (human pilot). The throttle was very slightly above neutral. Therefore, the sUAS started ascending and flew in the direction of the prevailing wind. Retroactively we are developing a monitor to check for excessive altitude and adapt behavior to RTL.
- Video:
- Flight Log: T10-Flight Log
- Mission Specification: T10 Specification