Skip to content

SAREC-Lab/PuDZ

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

99 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Validating self-adaptation across a sUAS System-of-Systems


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.


🔎 T1: Mission state transition during normal operations

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.


🔎 T2: sUAS-A detects and tracks a person

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.


🔎 T3: sUAS-A detects and sUAS-B tracks person

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.


🔎 T4: sUAS misses heartbeat from GCS

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

🔎 T5: EDS and Air-Leaser adapt due to high winds

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.

Air-leaser

  • Video: T5-Video (Two sUAS flight, but no videos available of the air-leaser tests below.)

Air-Leaser Basic Test #1

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.

Air-Leaser Test #2.

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.


🔎 T6: Air-leaser layout adaptation

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.


🔎 T7: Compass interference onboard sUAS

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.



🔎 T8: Human requests extended PuDZ Boundaries

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.



🔎 T9: Ill-formed mission detected

(To do: upload screen shot)


🔎 T10: sUAS hits geofence and flies off course at high altitude

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.


About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •