Motion capture like we're on Mars!

Helium handles all of the legwork required for secure long range data transmission. And, best of all, that convenience on the hardware layer is matched by convenience in the cloud. By closely integrating with AWS (also Google, and Azure) Helium provides very straightforward data flow from field-deployed devices to common IoT pubsub architectures and state managers. And, for the win: Helium has made these integrations easy (tackling the creation of every certificate you could image, and more!)

We decided to challenge the notion that low-bandwidth networks should only be used for low-bandwidth applications. It's not that we necessary disagree, but this is a hackathon and why not try to break things? So we prototyped the various pieces that may be required for long distance document transfer. This includes:

• The field-deployed device (Raspberry Pi with camera)

• The network (Helium)

• The infrastructure (AWS IoT)

• The command/control interface (Rails app)

There were not many other projects taking advantage of the utility provided by AWS device shadows, and so we've also included an example for how state management can be implemented with Helium and have attempted to show why it is useful.

HARDWARE

We wanted to perform very basic motion detection. In this way the camera could somewhat intelligently decide what images to transfer. To accomplish this we're building on a Raspberry Pi and the Helium Ethernet Starter Kit for Raspberry Pi.

See project attachments for the software. We're essentially taking two photos and comparing the green pixels between each. For every pixel that changes a counter is increased. Finally we set a threshold (any arbitrary number -- we choose 1000) that says "If 1000 or more green pixels have changed, declare this motion!"

The python script then simply converts the image into a base64 encoded string, parses it into small payloads with unique identifiers, and executes a loop to slowly transmit the payloads over the Helium network. Compression? Oh heck no! This is a test!

NETWORK & INFRASTRUCTURE

In the past we've enjoyed using the AWS IoT core and wanted to use Helium's built-in integration to take advantage of a few things it provides out of the box. The first is a robust MQTT endpoint we could subscribe to. The second is a managed device state (essentially a fairly flat JSON tree) which the device can request and that we can update.

COMMAND CONTROL INTERFACE

At the end of the long journey from camera to cloud payloads are re-assembled into images viewable in a browser. A Rake task subscribes to the correct MQTT topic and routes all inbound packets to the Rails application. For the sake of example we've kept the Rails application relatively lightweight.

But what if a packet is lost in transmission? Or the rake task misses something? In this situation we need a mechanism to communicate back to the device that we need it to re-send data. Enter device shadows!

DEVICE SHADOWS

Device shadows are managed on AWS (the IoT core service). The Rails application we built manages our hardware state by managing its device shadow. When everything is hooked up properly a device can poll Helium, which polls AWS, for an updated state. This functionality is already implemented on Helium as well as the helium-python library!

On the Rails side we opted to leverage an MQTT based approach for manipulating device shadows. We can publish new states to specific topics reserved for this specific purpose. It's helpful to note that in addition to the MQTT approach we implemented, AWS also provides REST endpoints you could use!

INTERFACE

There isn't much going on here. Follow the readme to get started:

rails server

and in a different terminal tab:

rake mqtt:subscribe

SUMMARY

The purpose of this project was to evaluate the entire Helium ecosystem (from device to cloud) to better understand its capabilities and its limitations. We chose a project that was fun, simple, and ultimately relevant. While we wouldn't recommend scaling a solution like this, it does go a long way to demonstrate what is possible. In summary: it is impressive how complete the Helium offering is. From dev boards (Helium Atom) to gateways (Helium Element) it took very little work to get running with the physical layer. Moving data off devices and into the cloud was then very straightforward thanks to pre-built integrations. Those integrations, by the way, do a lot of helpful provisioning that can seriously muck things up in practice. If you've ever attempted to replicate similar functionality with other solutions you'll appreciate how straightforward this is.

Overall, 4/5. We'll leave one monkey on the table for next gen!