BHP Digital Tribes

August 3, 2017 - Reading time: 11 minutes

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

  • Interactions between vehicles and personnel within both underground and opencut mining environments present a risk to equipment and life
  • Current approaches to safety (cones and barriers) rely on awareness and compliance from personnel and are not digitally enhanced
  • Mining environments lack traditional network communication infrastructure

The challenge was to try and create some form of digital safety controls (preferably using the supplied commodity hardware) that would enhance traditional approaches.

Approach

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.

Networking

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

/etc/network/interfaces

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.

Multi-hop ad-hoc

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.

 undefined

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

Gateway and backhaul

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.

Communication protocol and logic

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.

Sensors

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.

Information emitters

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

  1. The relative geographical position of other Safety Net devices in a radar type view. This intuitive graphical view gives an operator a quick means to identify assets within his environment, including those that may not be within line of site. The view can easily be extended to display additional information about each device, including type, bearing,velocity etc.
  2. Safety alerts generated by the system when predefined safety rules are breached (for example, a proximity barrier has been breached).

Outcome

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).