IoT and Drones: Akka in the Cloud, and up in the Clouds, Literally

Broadcast Actor is an actor that sends UDP-broadcast messages for the node to be identified and added to the cluster.
Embedded Actor is an actor that processes the messages from other nodes of the cluster and interacts with hardware. This actor can be extended to implement user logic.
Hardware Layer is the layer for hardware interaction. It is an actor that receives binary commands and writes them to the serial port.

Also, we introduced one more type of nodes, Manage Nodes, to work on a server, command the devices and provide interaction with other systems. Pragmukko allows extending the functions of a Manage Node with plugins that could also integrate with other systems. The plugins we have can integrate with MongoDB and HDFS as well as implement the REST interface based on Akka-http. Below is the illustration of this node:

UDP-Responder is an actor that adds new nodes to the cluster.

Sample code

Unfortunately, the project team was unable to implement the business case described above since there’s no fridge with ice cream in our office. Therefore, we tested a simplified case. We had several quadcopters randomly flying over a certain territory. They were controlled by the control station that kept them inside the perimeter.

Here’s the example of the code that works on a quadcopter:

object EmbeddedMain extends App with DroneCommands {

  //  Initialize initial speed of the drone
  var (vx, vy) = (Random.nextFloat(), Random.nextFloat())

  // Special helper to create Embedded Node
  EmbeddedPragma {
    ctx => {

      // The Start message comes right after the node joins the cluster
      case Start =>
        // Here, we notify the hardware that we want to receive telemetry
        ctx.subscribeHardwareEvents()

        // Notifying the hardware layer about the desired initial position and speed of the drone
        // We tell the drone to rise 10 meters up and start moving in directions vx and vy with the specified              // speed

        ctx.self ! moveTo(0,0,-10)
        ctx.self ! direction(vx, vy, 0)

      // Here, we process the autopilot data
      // The data is received in the binary format
      // The tools for processing are available in the DroneCommands trait
      case TelemetryBatch(batch) =>  // TelemetryBatch - message contains drone
        // Checking if the received data contains the information about the drone’s position in space
        val position = batch.collect { case DronePositionLocal(p) => p }.lastOption
        // If the position is located, we send the information about it to all listeners
        ctx.listeners foreach ( _ ! position )

      // Processing commands from the control station

      case "turn x" =>
        vx = -vx
        ctx.self ! direction(vx, vy, 0)

      case "turn y" =>
        vy = -vy
        ctx.self ! direction(vx, vy, 0)
    }
  }
}

And the code of the control station:

// plug-in listing
class DroneControlExt extends GCExtentions with DroneCommands {

  override def process(manager: ActorRef): Receive = {

     // Processing messages from a drone
     //  If the drone crosses the 20x20 m perimeter
     // we send the command to turn along the required axis
    case DronePositionLocal(position) =>
      if (position.x > 10 || position.x < -10) sender() ! "turn x"
      if (position.y > 10 || position.y < -10) sender() ! "turn y"
  }

}

Basically, that’s all with the code. We compiled it and launched the Embedded Node on the drone. As for the control station, it can be launched anywhere: for instance on a laptop, provided that it is located in the same network with drones.

So, what’s happening behind the scenes? A drone, when launched, starts identifying itself with broadcast messages. As soon as a control station gets the message, it adds the drone to a cluster. Finding itself in the cluster, the drone adds the control station to the context.listeners list.

The control station and the drone’s Embedded Node implement the trait DroneCommands. This trait contains utilities for Pixhawk MAVLink protocol. For example, direction(dx:Float, dy:Float, dz:Float) method forms a binary command that sets the drone speed along certain axes. All incoming binary commands are automatically transmitted to the hardware interaction layer that communicates with the drone’s autopilot. Since we implemented the hardware interaction layer as a simple interface to the serial port, other autopilots would work if you change the implementation of DroneCommands.

Here are a few more words about the deployment. As the number of drones and IoT devices we experimented with grew bigger, the time to deploy them also increased. We had to go through the same routine for each device: install Java, upload the app, register it as daemon, and reboot the device. Only after all these steps could we deploy the Manage Node with all the components it interacted with. The process was so complicated that the team immediately wanted to automate it. On the advice of our partners from Cisco, we used Mantl.io. A platform for rapidly deploying globally distributed services, Mantl provides all the necessary components to start fast and improve often. As Cisco's CTO Zorawar Biri Singh outlines in his exclusive interview to InfoWorld, in the foreseeable future, this lightweight, high-level container PaaS can be used as an orchestrator solution for building tightly coupled systems.