Skip to content

Commit

Permalink
Update README.md
Browse files Browse the repository at this point in the history
  • Loading branch information
mihirbala authored Nov 28, 2023
1 parent 34a0fce commit 9bddc99
Showing 1 changed file with 11 additions and 33 deletions.
44 changes: 11 additions & 33 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,55 +9,33 @@ SteelEagle: Edge-Enabled Drone Autonomy

Introduction
------------
Today, commercial autonomous drones are used for increasingly demanding tasks, from building inspection to area surveillance, which require
computationally heavy algorithms. These algorithms necessitate the use of high-end CPUs and GPUs which are often mounted onboard the aircraft, driving up
cost and weight. Additionally, drone programming is often limited to proprietary APIs that have no cross-platform support. With SteelEagle, we propose a solution to both of these problems. We have created a framework that enables small, lightweight, and cheap drones to run these
algorithms with similar performance to larger, more expensive drones using edge computing. We have also created a drone language interface to go along with this framework that can unify many different drone control APIs under one system.
SteelEagle is a software suite that transofrms commercial-off-the-shelf (COTS) drones into fully-autonomous, beyond-visual-line-of-sight (BVLOS) UAVs. This allows users to develop complex autonomous UAV applications without needing to purchase or configure expensive aircraft hardware. SteelEagle drones are easy to deploy and importantly, are drone agnostic. This means that SteelEagle can be adapted to work with any drone control API, as long as it supports control over WiFi. Of particular interest to us are extremely lightweight drones because of the simplified regulatory approval process.

[Democratizing Drone Autonomy Via Edge Computing]() published in SEC 2023
[Democratizing Drone Autonomy Via Edge Computing]() published in ACM SEC 2023

Nomenclature
------------
**Mission** - A mission is an automated drone flight which consists of one or more tasks that is designed by a mission planner.

**Task** - A task is a unit of work that should be completed during a mission which consists of a scope and actions. Initially tasks can be simple self-contained units or, in the future, can have dependencies on other tasks. Task ordering will be done by the mission plan generator.

**Scope** - The georgraphical extent of a particular task, as defined by the GPS area polygon drawn by the planner.

**Actions** - The list of operations to be performed during the execution of a task.

**KML/KMZ** - Keyhole Markup Language is an XML document that is used to define the scope of a mission’s tasks. A KMZ file is a zipped version of a KML document that includes any additional styling resources needed for the KML document.
[**Quickstart**](https://cmusatyalab.github.io/steeleagle/docs/user-guide)

**MS** - A Mission Script is the set of drone-specific instructions that are generated by the hermes compiler.

**DSI** - Drone-Specific Instructions are commands which are written using the API for a specific drone (e.g. Parrot GroundSDK commands for Parrot Drones).

**Drone Platform** - The specific instruction set needed to control the drone; this is derived from the drone manufacturer (e.g. Anafi uses Parrot GroundSDK).

**Drone Brain** - The app running on the onboard computer which acts as an LTE bridge between the drone and the cloudlet.
Hermes - Compiles high-level mission parameters from KML document into an MS.
[**Documentation**](https://cmusatyalab.github.io/steeleagle/)

Design
------
Steel Eagle is separated into three distinct parts: the local commander client, the cloudlet server, and the onboard software. The commander client is intended to run on a personal computer close to the PIC (Pilot in Command) with an internet connection. It gives an interface to receive telemetry and upload an MS to the drone. It also provides tools to assume manual control of the drone while it is in-flight (_kill_ command). The cloudlet server is the bridge between the onboard drone software and the commander client. It relays messages between the two and also publicly hosts flight scripts. Additionally, the server runs compute engines for the drone which will be executed on the offloaded sensor data/video stream. Finally, the onboard software consists of an app that runs on the drone-mounted Android device. This app relays telemetry and offloads sensor data/video frames to the cloudlet server. It also is responsible for interpreting an MS as DSI which are then sent to the drone to execute. Note: once an MS is sent to a drone, it is downloaded onto the onboard app. This means that in the event of a disconnection, the drone can continue executing its mission. See the **Architecture** section for a detailed system diagram.
Steel Eagle is separated into three distinct parts: the local commander client, the cloudlet server, and the onboard software. The commander client is intended to run on a personal computer close to the RPIC (Remote Pilot-in-Command) with an internet connection. It gives an interface to receive telemetry and upload an MS to the drone. It also provides tools to assume manual control of the drone while it is in-flight. The cloudlet server is the bridge between the onboard drone software and the commander client. It relays messages between the two and also publicly hosts flight scripts. Additionally, the server runs compute engines for the drone which will be executed on the offloaded sensor data/video stream. Finally, the onboard software consists of an app that runs on the drone-mounted Android or router device. This app relays telemetry and offloads sensor data/video frames to the cloudlet server. In the Android case, it is also responsible for running the mission script and directly sending control commands to the drone. In the router case, the cloudlet runs the mission script and sends control commands over the network to the drone.

Architecture
------------
![drawing](https://docs.google.com/drawings/d/1C_G5kXBvF5zbd1iQ8FaUf4WKSYaBuEyBUcdjsvlQMbg/export/png)
------
![drawing](https://github.com/cmusatyalab/steeleagle/blob/main/docs/images/system-arch.png)

Workflow
--------
1. A planner utilizes Google MyMaps to define the mission in a graphical UI by creating tasks. A task is created by drawing a polygon/marker, naming them, and defining the actions associated with that task by adding these to the description textbox. You can find documentation for all internally implemented tasks [here](https://cmusatyalab.github.io/steel-eagle/).
1. A planner utilizes Google MyMaps to define the mission in a graphical UI by creating tasks. A task is created by drawing a polygon/marker, naming them, and defining the actions associated with that task by adding these to the description textbox.

2. Once defined, the planner exports the mission as a KML file.

3. The planner generates an MS using the Hermes compiler. The compiler is a CLI program that takes many parameters. These parameters are used to specify things such as the drone platform to compile to, the filename to output to, whether to take into account current weather conditions, etc [If there are errors (e.g. action syntax is incorrect, the simulation finds issues), they are reported to the planner who can return to step #1]
3. The planner generates a mission script (`.ms` file) from the KML file using the Hermes compiler.

4. The pilot will start the command server on a publicly hosted machine and connect their commander client on their local computer to the server.
4. The pilot powers on the drone, starts the onboard software, connects to the drone through the commander, and sends the `.ms` file.

5. The pilot will then power on the drone, pair the onboard watch with the drone, and start the Drone Brain app on the watch. The watch will then register itself with the command server to ready itself for flight.
5. The drone executes its mission.

6. When ready to launch the mission, the MS can be sent to the watch over LTE via the command client where it will then be executed.

7. The drone will start flying. The commander client will be updated to reflect the current status of the drone(s) (telemetry) as well as the mission status. The pilot can assume manual control at any time by sending a _kill_ command to the drone.

0 comments on commit 9bddc99

Please sign in to comment.