A couple of weeks back I took part in a hackathon event put together by Unearthed in collaboration with BHP here in Perth. The idea behind the event was to give participants some cheap commodity hardware and a bit of cash, and describe two challenges faced by BHP that could benefit from digital enhancement. So to this end participants were divided into teams and each participant was given a Raspberry Pi Zero W board and AUD 60 for additional hardware spend and sent away to come up with a novel solution to one of the two nominated challenges over 2 weekends. I was in a team with one other guy and like all other teams save one, elected to tackle the distributed safety device challenge.
The major points of this challenge were
The challenge was to try and create some form of digital safety controls (preferably using the supplied commodity hardware) that would enhance traditional approaches.
The approach considered 3 main areas - communication amongst components of the system in the absence of any fixed network infrastructure, sensors to gather data from the environment, and components that used the data to communicate higher level information and warnings.
Clearly the most significant challenge was to enable communication between components of the eventual system, whatever form that took. System components (vehicles, personnel) are highly mobile, changing position frequently, and there is no networking infrastructure across most of the environment. There was a requirement that communication remained within unlicensed spectrum, and given the Pi zeros came with a 2.4Ghz wifi chip on board, this naturally led to the use of 802.11 for wireless communication.
Since there is no fixed network infrastructure within the target environments, direct peer-to-peer communication, without reliance on an access point is necessary. 802.11 defines the Independent Basic Service Set (IBSS) whereby all 802.11 stations (within radio transmission range), communicate directly with each other.
Enabling IBSS ad-hoc on the Pi is as simple as editing the content of the file
To the following (we select the SSID safetynet for the ad-hoc network, have no security, and have all devices on the 10.0.0.0/24 network)
auto lo iface lo inet loopback iface eth0 inet dhcp auto wlan0 iface wlan0 inet static address 10.0.0.1 netmask 255.255.255.0 wireless-channel 1 wireless-essid safetynet wireless-mode ad-hoc
Although Android does not support ad-hoc networking via IBSS (for a discussion on that issue see here), it is possible to enable it on supported Android devices using a custom ROM from CyanogenMod (we used an Asus Nexus 7 running CM as part of the prototype ad-hoc network). A really good discussion on ad-hoc networking support on Android is provided here. Windows generally supports ad-hoc networking (Windows 7 in particular), so there is a wide range of common hardware that can participate in an IBSS ad-hoc network.
Although the IBSS configuration provides for direct peer to peer communication amongst devices within radio transmission range, it does not allow for packets to travel beyond radio transmission range. In the diagram below, device A can communicate with device B, and device B can communicate with device C, but since C is outside of A's transmission range, device A cannot communicate directly with device Cwithout additional routing support. We utilised OLSR - a proactive ad-hoc routing protocol operating at Layer 3 to provide multi-hop communication within the system. This significantly increases the range at which devices within the system can communicate with each other.
In the final system we had both Raspberry Pi devices and Windows devices using OLSR and communicating over multiple hops. On the Raspberry Pi's we built the OLSR daemon from the Serval Project available here, and on Windows devices we used a build available here.
We connect the multi-hop, ad-hoc network to the wider internet via a gateway device - this is a Raspberry Pi model 2B with 2 network interfaces, one communicating on the ad-hoc network via nano USB WiFi adapter, and the other connected to the Internet. In the PoC the gateway node was connected to the internet via a wired Ethernet connection, but this could easily be made more mobile through the use of a GSM interface.
In order to pass traffic between the ad-hoc network and the Internet extremely simply, we first of all enable IP forwarding, and we use the POSTROUTING chain combined with IP masquerading
sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward' sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE
We enable OLSR's HNA on the OLSR daemon running on the gateway device to advertise itself as a gateway to devices on the ad-hoc network.
For the purposes of the PoC we designed a simple communication protocol with a limited number of message types - all communication took place via UDP over IP.
A simple controller application was written in Python (which has runtimes for most platforms) that processed communications messages in the system. This controller application runs on each Safety Net device, be it a Raspberry Pi, a Windows laptop, or some other platform.
For location sensing we used an inexpensive USB GPS receiver, a BU-353-S4 rather than getting a GPS board and connecting to the Pi via the GPIO pins, you simply connect the USB receiver to the Pi's USB port and NMEA data is delivered via a serial port.
We use gpsd and a python library to access GPS information from the receiver. You can install this on the Pi using apt
sudo apt-get install gpsd gpsd-clients
We also made use of cheap off the shelf ultrasonic sensors to detect objects within close proximity (~3 meters).
Below is an ultrasonic sensor soldered up to the appropriate resistors and connected to the GPIO pins on a PI Zero W.
We wrote some very simple Java UI clients which presented the data gathered from devices in the Safety Net network, to an operator. Java was selected as it can be run on a range of platforms, including the Raspberry Pi, as well as Windows laptops. It would be trivial to extend to an Android environment too. The 2 major pieces of information that were displayed were
At the end of the hackathon, teams were required to pitch their work via a 7 minute presentation to a panel of judges including the general manager of the Whaleback mine.
Despite some strong competition and great submissions from other teams, the Safety Net system won both first prize at the event, as well as the Peoples Choice Award (voted for by the community).