Drone Design

Akshay Dahiya edited this page Aug 22, 2017 · 2 revisions

This page explains the design, architecture and the implementation of Drone Component for the simulation.

Table of contents

General Design

Drones act as Hydra Servers as well as Hydra Clients (Hybrids): they have some exposed endpoints where other Hydra Client can send orders or ask for updates, but they also have Hydra Client capabilities themselves, to send information and signals to the Controller by calling the Controller’s Hydra API.

Main Features

  • Drones can receive commands from the server at /api/CommandCollection.
    Each command has a State object with properties like Speed and Direction or Status. Upon receiving a command the drone will act immediately unless there is some issue and it needs to override the command.
    The drone deletes the command from it's /api/CommandCollection after successful execution of each command.
  • Drones publish their current state with all other properties at /api/Drone.
  • Drone publish the latest Datastream from its temperature sensors at /api/Datastream.
  • Each drone has a unique id assigned by the controller at runtime.
  • Drones cannot interact with other drones or issue commands to them directly, they need to do so via the central server.
  • Drones will automatically decide when to charge and only, in that case, override the commands sent by the server only after sending a log of its status to the central server.
  • Drones obey some basic rules ( For example - can’t hit each other)

Drone Behavior

Drones are driven by a 15 second time loop after which the drones update their position, generate new sensor datastreams depending upon anomalies detected (if any).

Main Loop design

"""Main 15 second time loop for drone mechanics."""
        print("Retrieving the drone details")
        drone = get_drone()
        drone_identifier = drone["DroneID"]
        datastream = None

        # Commands will be executed in any state
        drone = handle_drone_commands(drone)

        if is_not_off(drone):

            ## Handle drone battery change
            drone = handle_drone_battery(drone)

            ## Handle drone general behaviour
            anomaly = get_anomaly()
            if anomaly is not None:
                if anomaly["Status"] == "Confirming" and drone["State"]["Status"] == "Active":
                    drone["State"]["Status"] = "Confirming"

            if is_confirming(drone):
                print("Drone handling anomaly")
                drone = handle_anomaly(drone)

            elif is_inactive(drone):
                print("Drone battery low, needs to charge")
                drone = handle_drone_low_battery(drone)

            elif is_active(drone):
                anomaly = gen_grid_anomaly(drone)
                if anomaly is not None:
                    print("New anomaly created")
                    send_anomaly(anomaly, drone_identifier)
                    datastream = gen_Datastream(gen_abnormal_sensor_data(
                    ), drone["State"]["Position"], drone_identifier)
                    datastream = gen_Datastream(gen_normal_sensor_data(
                    ), drone["State"]["Position"], drone_identifier)

            # Handle positions change
            drone = handle_drone_position(drone)

        # update the drone both locally and on the controller

        update_drone_at_controller(drone, drone_identifier)

        if datastream is not None:
            # Send datastream to central controller
            # Update datastream locally

    except Exception as e:

        # call main() again in LOOP_TIME
        threading.Timer(LOOP_TIME, main).start()

The full implementation of the main loop is available at flock_drone.mechanics.simulate.

Sample Drone Object

All the drone configurations are defined in a drone object.

    "@type": "Drone",
    "DroneID": "-1000",
    "name": "Drone 1",
    "model": "xyz",
    "MaxSpeed": "130",
    "Sensor": "Temperature",
    "State": {
        "@type": "State",
        "Speed": "100",
        "Position": "0,0",
        "Battery": "100",
        "Direction": "N",
        "Status": "Active",

During runtime the drone mechanics modifies the State object to simulate the drone behavior.


The speed of each drone can be controlled by user from the Simulation GUI.
NOTE:- Speed <= MaxSpeed of the drone.

Direction and Position

  • Drones will always move within the area of interest, if a drone reaches the boundary then it will change its direction.
  • Each drone can move in one of the four directions East, West, North and South [E, W, N, S]


Drones use different Status values to handle different scenarios

  • Active - Active is the drone default drone status, in this state the drone is free to move around within the area of interest.
  • Inactive - The inactive mode is like power saving mode. Drone takes only 1/4 battery in this state and all the sensors are turned off. Drones use this state to return back to the central controller for charging.
  • Charging - Drones need to return to the central controller for charging. Drones change their status to Charging once they reach the central controller.
  • Confirming - When the drone is confirming any anomaly detected by some other drone. User can't change the drone direction in this state.
  • Off - Drone is turned off.


  • When Battery>20 - Drones function normally when their Battery>20
  • When 4<Battery<20 - Drones enter power saving mode (Inactive state) and start moving toward the central controller for charging.
  • When Battery<4 - If any drone fails to reach the central controller then it shuts down.

Full source code for the drone component is available here.

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.