Picture this-A watering hole in the Maasai Mara, one of the world’s most spectacular national reserves. A herd of elephants walk by, forming a silhouette against the setting sun. They stop to cool down in the heat and take a bath. Nearby a group of zebra graze on.
Wouldn’t it be spectacular to be able to watch this imagery from the comfort of your home? Not only is this an appealing scene for wildlife enthusiasts, but the prospect of obtaining such wildlife data is highly beneficial for conservation and would be a great driver to reducing activities such as poaching.
What’s the one major problem with this scenario? Why is this not yet a reality if it has so many benefits. The answer lies in the fact that such areas are too remote to have internet connectivity, and even if they do, services are quite limited. This is one of the many examples where we could really do with alternative data transfer methods. Another scenario is Yet, we all appreciate the power that the internet brings to us. How can we harness the strength of the internet and its connectivity, while yet tackling the issues of remote connectivity? Read on to find out what could potentially be a simple and yet elegant solution.
In this blog article, not only do we discuss how to go around this problem, but also provide a step by step guide on how you could create a set up of your own that would achieve the same objectives of remote data transfer. The Internet of Things is a phenomena that is quickly spreading across technology related circles. It revolves around the connectivity of devices to the internet and how we can process and utilise data being generated by these devices and being stored on the cloud, and sometimes go a step further and use this data to trigger desired outputs.
The Setup and Technology involved
We make use of microprocessors such as the new UDOO boards (we’ve just got hold of a UDOO Quad, which is a really great piece of kit that includes arduino pins/inputs as well), Raspberry Pi’s, BeagleBone Black’s, and the like. These are all quite convenient to use because a lot of the technologies are overlapping and since all of them use some form of Linux (most usually an underlying version of Debian or Ubuntu), most of the work we do can be used on any device. Another great benefit is the ability to connect a huge variety of input devices to these little boards. For instance you could connect arduino motors, servos, temperature and humidity sensors and even a camera to the UDOO board. Lastly, they are not very expensive to obtain and the power consumption isn’t something that would empty your bank account. These qualities make them ideal to use for such a project, where we want to continually gather and process data.
The setup involves several kits of the same equipment – a microprocessor with a USB Webcam for video recording. These are essentially data collecting devices that can be placed across the environment being monitored. We call these nodes. Several nodes are ‘connected’ to a central node, which we call a hub, which is again just a similar peice of kit, with the only difference being it has an internet connection. I use the term connected but all I mean is that the nodes send data to the hub for uploading to the cloud.
Another key piece of technology we shall exploit is the Microsoft Azure Service Bus. The service bus allows users to upload data and send messages as well as log data to tables. It is a tool with several capabilities, of which we shall use blobs, tables and topics and subscriptions. More is explained in detail about how we use these in later sections.
There are several nodes placed at strategic locations around the watering hole. They have motion detection software running on them and have a live server stream running simultaneously. The herd of elephants walks by, and motion is detected. The nodes start recording videos of the motion event. Messages about when the motion was detected and when it ended are also generated.
This data (the messages and videos) from several nodes is transported to the hub, which could be located at a viewing point. The hub is connected to the internet, and also acts as a node by carrying out motion detection and recording. The hub gathers the data, and uploads it all to the service bus, sending messages via topics and subscriptions, and sending large video files via blobs.
In another part of the world, you are seated on your laptop, and receive messages saying some video files have been uploaded and motion was detected at some specified time. You go to the link provided and can download and watch the whole scene. As you receive these messages, a log of this is recorded on tables, also stored on the Azure service bus.
This still leads to the same big question. How do you get data from the nodes to the hub. Well, there are several ways really.
One of them is as simple as having a wildlife ranger patrol every evening and take out the external storage (SD Card, USB Flashdisk, etc) from the nodes and bring it to the hub to upload. One issue this hits is that we are still independent on having to physically be there to transport the data.
Another is to fly in a UAV with some on-board storage as its payload. This could be an SSD, a flash drive or an SD Card. The key is to use storage that has wireless data transfer capabilities. This is where the Toshiba Flash Air card comes in. It is a wireless SD card that you can upload data to and download data from wirelessly i.e. it sets up its own wireless network. The UAV flies past the nodes, stopping at each node to gather data. At each node is a QI wireless charging pad, which is where the UAV lands. This powers the on-board SD Card (which is connected to a QI receiver). Once the data has been uploaded the UAV flies to other nodes, replicating the process. Finally, it arrives at the hub and offloads the data to the hub, which uploads it all to the cloud. Simple, elegant and yet quite unique.
It’s important to remember that such methods are quite useful in several other scenarios as well, and that it isn’t necessary to use a flying UAV with wireless capabilities in all cases. One good example is using microprocessors to monitor patient health, through the use of sensors such as accelerometers, room temperature probes and again possibly video recording processed using something like OpenCV. In such a case, you could easily have the nurse take the SD card out of the node and plug it into a hub for uploading.
As a result, I’ll run through the setup required to run both of these methods.
About Topics, Subscriptions, Blobs and Tables
I’ll just try and briefly cover the key elements we use as part of the Service Bus in this section. If you haven’t already set up a Service Bus account, now would be a great time to do that. Look at the Azure Service Bus website (http://azure.microsoft.com/en-us/services/service-bus/) for more details.
Topics and Subscriptions: These are used for sending and receiving messages. Messages are sent to topics and received form subscriptions, each of which has a rule. More on how to set up topics and subscriptions can be found in our previous blog article. Subscriptions allow users to receive messages based on filters that can be specified. In our case, we could have subscriptions for each node for instance, hence allowing users to select which nodes they want to get data from.
Blobs: This is essentially just online storage for large files. All videos and images are uploaded to blobs, which can be made available to the public through a link, which is sent through the messaging service.
Tables: These are very ideal for logging data. In our case, we log data to the table every time a message has been received. The information logged includes details of the message received, and all messages for a single date have a common partition key, hence making it easy to sort the data.
As you may have realised, the nodes don’t need to be powerful microprocessors. For this reason I use the Raspberry Pi B+ model as my nodes. The hubs on the other hand do a fair bit of data processing and upload all the data to the cloud and hence I opted for the UDOO Quad. There’s nothing to stop you from using any other device, like I mentioned, Another good alternative would be to use UDOO Dual Basic as the nodes and UDOO Quad as the hub.
I’ll be using PuTTY, which is an SSH client, to control and configure the nodes and hubs (see http://www.chiark.greenend.org.uk/~sgtatham/putty/ for more information).
The first step is to make sure your system is up to date. For those of you using a desktop environment, open up a terminal and run the commands:
sudo apt-get update sudo apt-get upgrade
We are now ready to proceed with setting up the nodes and hubs in turn. Note that the nodes and hubs are pretty much the same and will be running very similar, if not the same, scripts. The only difference is that the hub handles more data processing and uploads everything to the service bus, Hence in terms of setup, the hub is set up the same way as the node, with some minor tweaks.
Use the sub-links under the Internet of Things Remote Sensing Category to view how to set up nodes, hubs and receivers in turn.
Article by Umang Rajdev