The Near-miss-o-meter, Part 2

This post documents the route I took to arrive at the current configuration of the nearmiss-meter, so you don't have to.

The Digispark in my previous post introduced me to the Arduino family, but with only 8kB of memory it was never likely to have the capacity to process both GPS and sonar data and write it to an SD card. Arduino is not a technology I had played with before starting this project but turns out it is really easy to set up and get going. The 'Blink' sketch is the Arduino equivalent of the ubiquitous 'Hello World' of every programming language ever invented - one of many, many examples that come with the freely downloadable IDE.
En route to the Pantomime on Christmas Eve, we detoured via Maplin picked up an Arduino/Genuino Micro. This comes with a heady 32kB rather than the 8KB of the Digispark.

Adruino Micro, HC-SR04, USB GPS & SD card

Once the festivities subsided a little, I pulled together my collection of components and realised I couldn't just plug the USB GPS into the Arduino. I also couldn't justify (or wait for) a PCB GPS so after a glass or two of brain lubrication I started to cobble together a Python script to read the GPS via my PC USB port, spit it out of another USB port to the Arduino and also read back from the Ardino... Easy peasy eh?

It turns out Python blocks when it reads/writes to/from a serial port so I had to lean about Python threading. Then I had to learn about how you can Ctrl-C from a Python thread so I didn't have to keep manually killing the process! (As an aside, I also learnt enough Python to control my half price Maplin 433MHz remote sockets from my Pi. I'm easily entertained...)

There are a huge number of libraries for Arduino, so the chances are, if you want to do something, someone has probably done it already (and than made a library out of it). NewPing was the first library I 'discovered', when I setup the Digispark. This library does all the complicated stuff for ultrasonic sensors so I don't have to.

Next up was TinyGps, a small but perfectly formed library for parsing NMEA [pdf] data (this is a standard set of strings or 'sentences' that most GPS devices spit out). The sensor built by Dr Ian Walker used a combined Real Time Clock (RTC) and data logging shield. Microcontrollers (and the Raspberry Pi) do not have a RTC so do not know or store the current date and time. The Pi often gets its time from ntp when it boots up, but this requires a network connection. With a GPS we can get the exact time - down to the nano second!

By default, most GPS devices output location data once per second. It is possible to reconfigure the frequency, but the setup strings are not standardised across devices so I've left this alone for now. We definitely want more frequent readings from the sonar and after a little trial and error, I settled on a 'sonar heartbeat' of five times a second. This should not swamp the SD card and will also give sufficient time to get a median reading from multiple 'pings'.

Meanwhile, an SD card board had arrived, so I gingerly plugged it in. The repeated dire warning in many of the pieces of documentation I'd read about SD cards was: "Don't use 5v, anything more than 3v3 will fry your card.". The board I'd bought was listed as running on 3 or 5v, but I suspect I'd not be the first person who bought something from eBay that wasn't quite as described...

I tested with some old/broken SD cards and when they didn't smoke I put in the one and only spare I had. The example scripts for Arduino are brilliant.

I now had a working prototype, albeit with a laptop attached, so I stood at the side of the road and tested of the rudimentary setup. Thoughts turned to power supplies and charging - this Arduino Micro is 5v, so to power it on the move I would need either a portable USB charger or a LiPo battery + a step-up booster + a charging circuit. More components, more complexity. The USB battery is definitely an option when I revisit the Pi version, but for ease of shareing, the unit really needed to be self-contained. Enter the Adafruit Feather  Adalogger.

This featherweight microprocessor had an on board SD card and built-in battery charging. The only downside was it ran at 3.3 volts whilst the cheap HC-SR04 sonars run at 5v. However, it removed the need for several components with just the step up booster required.

With a new breadboard circuit made up, including the newly arrived Ubox GPS board, I now had my first fully portable system. Two resistors gave me the step down for the returned echo from 5v to 3v3.

I'd also ordered a couple more cheap sonars - I wanted to see how consistent their measuring was, but I couldn't get the two new ones to work. It seems not all HC-SR04s are created equal. Some will trigger with 3v3, others absolutely require 5v. Not happy. This would mean having a logic level shifter (new to me too!) - yet another component.

On the plus side, the Adafruit Feather performed well, despite only running at 8MHz but it was time to bite the bullet and buy a more expensive sonar that ran at 3v3. This is the Maxsonar MB1010, from Maxbotix. They have a huge range of sonars for every application, but my choice was based on price and easy availability in the UK as well as noting Ian Walkers use and comments. The top end fully waterproof models are way out of the target price range for this project, but may appeal to some who want to log data in all weather.

A couple of (late) nights later, with the great Antoine de Saint Exupéry sitting on my shoulder, I had reduced the design to the minimum: a single sided PCB with just three main components. Although this design is operational on a breadboard, this PCB layout is currently untested as my local PCB fabricator wanted to charge me £800 'consultation' fee before looking at it! The next step is to implement this on a peg board, to improve the connection reloability of the prototype, then I'll probably use Fritzing to get a test board made up.

Other than the plethora of new new things I've learnt, one of the biggest personal benefits of this project was that for almost the whole of the Christmas and New Year period I watched very little television but we're back into the swing of work/life, time is a little more limited.

I now have the Arduino code mostly written and a rudimentary Leaflet based web 'viewer' of the data.

This is a local street on the way back from my local bike shop that is absolutely awful to cycle along. The colour grading of the line shows red for less than 1m and shades from red to yellow to green for 1m to 2m passing distances. The data is only ever held locally (using Javascript FileReader), so privacy is ensured.

The next post will document the device I have prototyped in greater detail, along with the functionality implemented in the Arduino code. I have created a Github repository, but that is another learning curve I need to overcome before I populate it.


Part 3: Breadboard to Pegboard

The Near-miss-o-meter, Part 1

It all started with this tweet from @beztweets:

Idea: build handful of these (crowdfund costs), lend to people for ~1wk each, voilà data… https://t.co/Oe8EeyMMxU @ianwalker @RachelAldred

— Bez (@beztweets) December 15, 2015

with a link to this great post by Dr. Ian Walker. I'd seen a few of these previously (whenever a '3 foot rule' is introduced somewhere) but the suggested addition of a GPS seemed to make sense, possibly for the Near Miss Project run annually by Dr. Rachael Aldred and Emily Brooke.

Coincidentally, I was about to receive my Raspberry Pi Zero on the front of the MagPi magazine. It seemed like a perfect match: a few days off for Christmas, a £4.00 computer, a £10.49 USB GPS (you can get them cheaper if you're will ing to wait for shipping from China) and a £1.61 ultrasonic sonar (HC-SR04) from that auction site.

The Aim

To create and document a compact design that can be built by anyone using easily available components without requiring a huge amount of technical knowledge. Although I played a little with electronics as a teenager, my knowledge is pretty much limited to knowing the difference between a capacitor and a resistor. I do like a challenge.

This is the first of several posts that will briefly document the journey and finish up with a more detailed 'howto' of a reference design.

Prototype 1: Pi, USB GPS, Sonar

After a mad run up to Christmas, I had half a day free, so started playing. Hooking up the Pi to a breadboard and wiring in the sonar is well documented on the web (e.g. here). Major lesson learnt here was how to drop 5 volts (from the HC-SR04) down to 3.3 volts (also known as 3V3, the maximum voltage allowed by the input pins on the Pi) using two resistors (or any three resistors of the same value using two in series).

With the USB GPS plugged into a powered hub, we were away!

Not quite. The Pi works very well with the sonar as long as that is all it is doing. The HC-SR04 works by setting the ECHO pin 'high' for the length of time it takes for the ultrasound 'ping' to bounce to and from its target, but if you start to add any logic into the measuring process, the Pi wanders off to do other things and forgets to listen to the ECHO pin for a few nano seconds. This results in frequent over-long distance measurements.

Thankfully, I'd done a bit of reading, so it was quickly on to:

Prototype 2: Pi, USB GPS, Digispark+Sonar

A Digispark? No, I hadn't heard of them either. They are a tiny, USB powered Arduino. About the size of a postage stamp and costing all of £2.99 on eBay. Unlike the Pi, this is a realtime microprocessor (with 8kb of memory!).

Shamefully, I'd not yet played with an Arduino before so there was a small learning curve to get up to speed. This excellent post, meant the Digispark was quickly wired to the sonar and plugged into the Pi.

Success! Consistent distance readings now being recorded with lon/lat, time, heading and speed from the GPS. Here we have a complete (hardware) solution for less than £20 (plus a USB booster battery to power the Pi on the go).

There was one minor issue: all the data was being recorded onto the Pi's SD card. This is fine for me (we have been 100% Microsoft free since 1997...) but a Windows PC cannot read the Linux Ext4 file system on the card without installing additional software. It is theoretically possible to dual partition the SD card, but Windows still struggles if it doesn't recognise the first partition. I still think this approach has mileage (particularly overlaying data on video etc) but given my my goal of this solution to be easily built by anyone, this was getting a little too techie. Besides, I was now learning about Arduino - perhaps I should follow Ian Walkers lead...

As you may have noticed from the picture above, I also discovered a new tool whilst trying to document my wiring: Fritzing - the open source world never ceases to amaze me!

Coming up in Part 2: The Arduino(s)