Skip navigation
2016

In November I offered to use an Arduino UNO as a reversing monitor.

Arduino Uno THROWBACK THURSDAY Contest


It's a simple concept

  • Arduino
  • Ultrasonic ping sensor
  • NeoPixel LED's

 

You use the ping sensor to detect the distance and change the colour of the NeoPixel to show Green for safe, Orange for Warning and Red for Stop.

 

In Part 1 ( http://www.element14.com/community/groups/arduino/blog/2016/01/07/ultrasonic-reversing-monitor ) I made this comment :-

 

Part Two

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.

 

 

 

Short Distances

I was getting random short distances that made no sense.

I tried slowing down the Ping rate which seemed to help, but not make the problem go away.

 

I tried changing the hardware, using the theory it was faulty, but still I got random values that were short.

 

I tried a new library, various averaging approaches and searched the internet to see if the issue was common.

I found a site where the author used the "Running Median" of several readings, and while the code seemed to work at short distances, anything longer than 1m seemed to cause these random short distance values.

 

In the end I needed to start assembling the hardware in order to take some photos.

During the assembly I followed the instruction here that specified adding a 1000uF capacitor across the NeoPixel power wires.

DSC_8852_01%20(Small).jpg

    100uF instead of the 1000uF   photo source : three minions (me, myself and I)

 

When I next connected the assembled unit to the computer, it behaved perfectly with no short distances.

 

So my conclusion is that while the lack of capacitor didn't impact on the Neopixels, it did manifest in the Ping Sensor which was hanging across the same 5v source.

 

 

Distances

While you can hardcode the distance trigger points, it makes much more sense to allow the user to set their own.

The problem is how do you make something user friendly, and fairly clear while capturing the distance.

 

I elected to use a single pushbutton, and detect it at power-up.

If it is pressed and held at power-up, the display changed to three Green pixels to indicate the SAFE distance is stored when you push the button.


Set_SAFE.jpg Set_WARN.jpg  Set_STOP.jpg

photo source : three minions (me, myself and I)

 

Once you have set the SAFE distance, the display changes to three Blue pixels to indicate the WARN distance when you push the button.

If it is pressed, then the display changed to three Red pixels to indicate the STOP distance is stored when you push the button.

Once it has stored all three values, it returns to normal.

 

 

Why BLUE

When I started I was intending to use Orange for the Warning colour.

NeoPixels will do Orange but the brightness is so much less that I felt you may struggle to see it in bright daylight.

When you send the colour it is in the form of Red value, Green value, Blue value with a range of 0-255.

Hence RED is 255, 0, 0, GREEN is 0, 255, 0 and BLUE is 0, 0, 255 and so it is the next brightest colour available.

 

 

 

Errors

While the display is obvious, if the Ping Sensor is not working, or the distances aren't stored, then the sketch goes into an Error display mode.

I elected to make half the display Red while the other half was blank and alternate at about a 1 second rate.

 

It becomes very obvious there is an issue.

It is not easy to continually detect the Ping Sensor, as the library returns distances greater than the maximum as a zero, just as you get if there is no sensor.

 

I included a blanking routine that if it detected the same distance 120 times (approx. 60 secs) it made blanked the display.

If the ping sensor went faulty this would kick in, and it wouldn't come out of it when you reached the SAFE distance (Green).

 

Hence I think I covered all the errors I could.

 

 

Assembly

This version was done for The Shed Magazine which use this version of Arduino UNO.

It allowed me to connect everything to the pins using female to female jumpers, but the same concept will work for a normal UNO.

 

Enclosure.jpg

Enclosure2.jpg

photo source : three minions (me, myself and I)

 

The case is a food type container from a large retailer and at $2 makes a very suitable enclosure

 

I intend to make another version using a Prototype board to connect to the UNO that element14 kindly supplied


 

 

Did it work

Since my daughter moved out, I don't have a parking issue, but if she returns this would be much better than the "stick that moves" we used to have before.

 

The photos below show the false wall I put in my garage to test it out.

I was very happy with the results.


SAFE.jpg  WARN.jpg  STOP.jpg

photo source : three minions (me, myself and I)

 

Final STOP distance.jpg

 

This is the final distance, and from the drivers seat looks like it is touching.

 

Normally you would be reversing into the garage and having the issue of parking in the right spot, but everyone's needs are different, and this works forward or back.

 

The relative position of the display v the sensor may need changing to suit the vehicle and direction.

I mounted it over to the right to allow viewing in an external mirror.

 

 

 

Code

Attached is the sketch and libraries needed to run it.

There are plenty of comments because later I won't remember why I did xyz, or what I was thinking.

Comments take no room in the compiled code but do make it easier for others to use your sketch.

 

 

 

Enjoy

Mark

DIY-Thermocam - An open-source, do-it-yourself thermal imager

 

DIY-Thermocam_small.png

 

The DIY-Thermocam is a do-it-yourself, low-cost thermographic camera based upon the famous Teensy 3.2 mikrocontroller. It uses a long-wave infrared sensor from FLIR to provide high quality thermal images.

 

The aim of this project is to offer a cheap, open-source thermal plattform for private persons, educational institutes or small companies. There are various applications like finding heat leaks in the insulation of buildings including windows,  the analysis of electric components, as well as exploring at night.

 

The large firmware written in Arduino compatible C++ code can be used as it is or modified / extended to your own needs. That allows the DIY-Thermocam to be used as a versatile basis for various, different thermal applications.

 

For more information about the project, check out the website:

 

www.diy-thermocam.net

In November I offered to use an Arduino UNO as a reversing monitor.

Arduino Uno THROWBACK THURSDAY Contest


It's a simple concept

  • Arduino
  • Ultrasonic ping sensor
  • NeoPixel LED's

 

You use the ping sensor to detect the distance and change the colour of the NeoPixel to show Green for safe, Orange for Warning and Red for Stop.

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.

 

s-l1000(sml).jpg

 

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.

constant_noise.jpg

 

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.

 

 

My Advice

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.

 

 

Part Two

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.

edit Part 2 is here http://www.element14.com/community/groups/arduino/blog/2016/01/16/ultrasonic-reversing-monitor-part2

Mark

I've been working on this Arduino project for a while. Mostly mechanical issues, but finally got a solid solution for my LEGO train track switch. I am also using IoT style messaging to emulate a distributed network of "things". It's a little overkill for a single track switch, but it helps to understand the bigger picture with these types of technologies. I plan on integrating this with a train schedule API so I can send the train down a path based on real-world data. I also have an OLED display in the mail, so will be cool to show train times as well.

 

 

Train Track Switch – Servos, LEDs, PubNub and Johnny-five.io | Internet of Lego

train track switch - thumbnail.jpg

weather-station-lcd.jpg?resize=1024%2C576

 

This Lego Weather Station is an exercise in IoT concepts using an Arduino (Cactus Micro Rev2) which has a built-in ESP8266 WiFi module. It then sends the sensor data using MQTT to a Mosca MQTT broker. A Node-RED client subscribes to the data feed, stores it into a MongoDB and then visualizes it with a Google Chart. The blog article is more about the journey than just the destination . This is one of many cool projects in the Internet of Lego city, which examines all sorts of interesting embedded, NodeJS and IoT concepts using Lego.  Full Story: Weather Station – DHT11, MQTT, Node-RED, Google Chart, Oh My! | Internet of Lego