Parking Sensor

Introduction

Originally published in September 2013.

My grandfather used to suspend a ping pong ball from the ceiling with a string in the garage. Initially, I was confused as to what it was for. As he parked the car in the garage, it became apparent that the string and the ball were placed such that you stop moving the car once the ball hits the windscreen.

It's an extremely low tech solution to ensuring you park the car in the right spot to allow easy access around it. But it's extremely cheap and very effective.

When I was living with my parents, they had a long carport and the cars were parked end to end. So the method we used to know when to stop was the same one we would use when pulling up at the lights; don't run into the car in front of you. Then, when I moved into my first house, it had an open backed carport. So then it was a matter of parking far enough to clear the door, and it didn't matter how far forward you went.

In the current house we have a more traditional fully enclosed brick carport attached to the house. And naturally, lots of junk on shelves in the carport to run into at the front!

So, more as a toy, I put together two Arduinos, Ultrasonic sensors, and cheap TM1638 based displays at the front, to give us real time input about the cars position as we are parking.

The hardware

The hardware is very simple. It's just an Arduino, an ultrasonic sensor, and the TM1638 based display board. The schematic is shown below.

Parking sensor schematic.
The parking sensor schematic. Created with Fritzing.

To mount them, I purchased some very cheap pine boards (140mm x 1500mm) from the local Bunnings ($7 each). Some holes and spacers gave me points to screw the boards into.

Ardino and TM1638 mounting.
The Arduino and TM1638 mounting.

There were two quirks with mounting all the hardware onto the boards. The first is that the appropriate height for the ultrasonic sensor and the display board is different for each car. I wanted to get the ultrasonic sensor at the height of the number plate to improve the distance detection accuracy. The display needs to be at the right height so it can be seen by the driver easily even if they have their sunshield down.

The two cars that we have is a 2001 Kia Rio and a 2012 Subaru Forrester. Some quick measurement with a tape measure gave me the right heights for each.

The second quirk with mounting the hardware was the ultrasonic sensors. The boards had only two tiny little holes that were unsuitable to put a screw through. In the end, I created two posts with two spacers each, and used those to wrap a cable tie around the sensor itself, holding it in place and keeping it pointed forward. Low tech, but effective.

Ultrasonic sensor mounting.
Ultrasonic sensor mounting.

Sofware

The software is incredibly simple. All it needs to do is read the distance, subtract the zero point, and show it on the display. The TM1638 boards that I had have a set of 8 Red/Green LEDs, as well as 8 buttons. So you can use the 7 segment displays as the distance, the 8 Red/Green LEDs as a very visible "stop"/"go" indicator, and the buttons for setting the zero point.

When you press any button, the current reading is taken to be the zero point. It is written into the EEPROM on the Arduino, and read on startup as well, so it survives power cycles.

You can fetch my sketch from the repository on BitBucket.

Building your own

You should easily be able to source an Arduino Uno R3 and an ultrasonic sensor from your favourite electronics supplier. The TM1638 boards, however, came from DealExtreme, and I can't recall any other places that have these boards. You could obviously replace the TM1638 board with any other kind of display that you wanted, that was visible enough for this purpose.

Future enhancements

I put the two sensors into use for quite a few weeks before doing this writeup. They performed quite well, although there were a few issues. The earlier firmware didn't handle the case where it was unable to get a reading, and also gave unstable readings at times. The firmware that's currently in the repository does handle this a lot better, by taking an average reading. (All the hard work for this is done in the NewPing library).

As to future modifications? I've had a few ideas, but haven't implemented them at this stage: