In November I offered to use an Arduino UNO as a reversing monitor.
It's a simple concept
- Ultrasonic ping sensor
- NeoPixel LED's
Simple enough .... a few lines of code and its' all sorted.
What about Safety?
There are no safety issues, you just reverse until the light changes colour.
What safety, nothing will fail.
That's the difference between a "Fail to Safe" system and the above assumption.
In some cases, the person may not be aware of all the factors, and therefore they assume something.
Neopixels retain the last instruction until you send a new one, or remove the power.
If the Arduino or the data line fails for whatever reason, you have the display showing Green and it never changes.
The average user will just think these are lights and if you turn them off they go off.
However as the Engineer designing this system, I know better, and therefore should be designing the system to take the NeoPixels characteristics into account.
What about the Distance settings?
Having hard coded distance settings is fine, but what happens if you install it in your parents place and they want to change the trigger point.
You could reprogram it with new figures, but what happens if you don't have that capability?.
Having the ability to set the distance makes it much more user friendly, but it also brings some other challenges.
You need to store the setting, and read it at startup.
There needs to be a warning if there is no settings read (because they aren't stored or corrupted)
The method of setting the distance needs to be considered, and made user friendly.
I'm pinging all the time
Pinging constantly is fine, but why wear out the transducer while the car is either not there, or is parked for two weeks.
Since it is ultrasonic is there an effect on animals?
Perhaps this might be great to persuade mice and other rodents to vacate the place, but I'm concerned if domestic pets are troubled by it.
I decided that after 10 seconds of the detecting the same distance, we can reduce the ping rate.
We can drop the ping rate down to once every second, we reduce the wear, but allows for any movement to be detected.
We really need to know when the car is returning and the distance is getting less.
Since these can work from 4.5m (14 feet), the first few seconds are likely to be well within the safe distance.
Blank the display
Having the Neopixel stuck on the last distance colour is fine, except it simply wears them out and is not necessary.
It would be much more useful to blank the display while it is in 'sleep' mode.
We still ping every second, and if the distance changes then unblank the display.
I thought that 60 secs is adequate time to decide the car is staying put, and this becomes the sleep time.
How do I know it's working?
Having a 'heartbeat' is necessary to provide user confidence that its working.
I elected to make one LED White and cycle it around at a 1 sec rate.
While the display is blank, the same will work, or I could leave it blank and maybe flash the onboard LED.
For the error warning, I elected to flash half the ring RED, with the rest blank. This alternates at a 1 second (1Hz) rate.
ie the first half is RED while the second half is blank and then it swaps to first half blank, second half Red.
It becomes very obvious something isn't right.
What does this all mean?
What it means is that this device performs the same function ie detects a distance and changes colour.
We have added :-
- Allow the user to change settings.
- Provide confirmation it is working.
- Warn if there is an error.
- Reduce the wear by reducing the ON time of some parts.
- Reduce the ultrasonic pollution created by the pinger.
The hardware remains the same, but the code has grown exponentially.
It might not be the most efficient code (I have stated before I'm not a software programmer), but it includes plenty of comments for anyone to follow.
That helps me later when I think why the .... did I do that, or What was I thinking?
It also means the quick simple task has morph'ed into a much longer project, and has consumed far too much time.
If you get into these projects, you need to think of the things that could go wrong and deal with them.
Your time is spent planning how to do xyz, coding it, and working out a means to test it.
We've made comments before about Engineering is 90% planning and 10% doing, and this is no different.
The end result is a much better product, that is much safer and more user friendly.
I'm still completing the final parts of the code.
There have been some other distractions (inc silly season) and I want do some more testing on the code.
I have found a suitable enclosure but I need to live test it before I fit it to the enclosure.
The Ping sensor uses a Tx and Rx ultrasonic transducer to send out a burst of high frequency audio.
This causes ringing of the transducer and can cause the mounting hardware to resonate which may give false readings.
I've been finding that doing this work in a confined room results in lots of echo, and therefore my "same distance' measurement isn't the same.
I've also had some issue with the IDE and the colourisation of keywords, that threw me off for a few days.
It's got to the stage where I can start actually testing it, and testing the hardware before fitting it into an enclosure ensures you can determine where the problem is, if it doesn't work as expected.
Hopefully soon I can do part 2 and include the code, and some more details of the project.