Close
0%
0%

Ultrasonic Parking Aid without Arduino

Low power, battery operated ultrasonic parking aid.

jscjsc
Similar projects worth following
Uses the cheap SR-04 ultrasonic distance sensor to blink some LEDs based on distance.

I found a lot of similar parking aid projects, but they all, for the most part, call for tying up a full sized Arduino and providing DC power through a wall wart. I wanted something stand alone that could run for months off AA batteries. A low-cost embeddable board like the Pro Mini might have worked, but most use LDOs and have power LEDs, so waste power.

This is a useful example project, I think, to intermediate Arduino users who want to put their project onto a PCB. The routing is much simpler than a full Arduino-compatible board because no unused pins have been brought out to headers. It provides ICSP and serial headers for programming and debugging. You could easily take this layout, delete the parking related stuff, and route in your own project components. It uses an LTC3525 boost chip to provide 5V or 3.3V from one or two AA batteries.

Watch the test video to see how it works:

Runs in one of three modes: waiting, parking, and parked. "Waiting" is when no car has been detected for a while, and goes to a 2 second ping cycle, with deep sleep between pings. "Parked" is when a car is detected, but has not moved recently; then it goes to a 1 minute cycle. "Parking" runs an active delay loop at 100 ms. Red and green LEDs are constant, yellow LED flashes at a rate proportional to distance. LED flashing is controlled by timer interrupts, to avoid complicating the main loop.

STLs for a 3D printed enclosure is provided. Stand off holes are sized to self-tap with a #4 screw.

The PCB is suitable for reuse for any low power mobile Arduino-based project. Just remove the traces for the LEDs and their current limiting resistors and add your own components.

The schematic was mainly cribbed from the SparkFun Arduino Pro Mini and the LTC3525 datasheet. I chose an 8 MHz resonator because clock speed wasn't important and I wanted to reduce power consumption. I chose 5V because it is necessary for the SR04 sensor and it would complicate things to introduce separate rails, power down the 3.3V rail, etc. Also, those LTC3525 boost chips aren't cheap; more expensive than the microcontroller!

  • 1 × ATMega328P Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 3 × 0.1uF 0805 ceramic capacitor
  • 1 × 1uF 0805 ceramic capacitor
  • 1 × 22uF 0805 ceramic capacitor
  • 1 × 10 uH 1210 SMD inductor

View all 18 components

  • Added pushbutton, new case

    jsc01/02/2015 at 06:52 0 comments

    The previous case sucked, never stayed together properly. The new case is great, a single piece except for the lid, which snaps on with the power of magnets. I've also added a push button to calibrate the red light distance because I was making one for my dad and it's a bit much to expect him to reflash the firmware if he wants the trip distance changed. The setting will be saved in EEPROM, so will last through battery changes.

  • Alternative printed case

    jsc07/25/2014 at 13:51 0 comments

    I've added an alternative case design, which lays out the battery holder and the boards side by side rather than stacked. It makes for a wider but thinner case. The battery is held on a slide out compartment.

  • Power savings success

    jsc07/19/2014 at 05:23 0 comments

    Just got the latest revision from the fab. Using a low side MOSFET switch does indeed turn the power usage down to unmeasurable levels. There are a few considerations.

    You must disconnect the trigger pin by setting it to an input (and setting it back to an output when turning the sensor on) or else it will find GND through that pin and consume power.

    Also, the sensor doesn't like being connected to VCC first without getting GND. Several of the available datasheets warn against doing this, with unspecified consequences. Well, one consequence is that the echo pin stays high through the first ping after wakeup, resulting in a short read. I've found a sequence of wakeup, short delay (20 ms), and a sacrificial ping resets the sensor to a working state.

    The board has been tightened up some for v1.3, but the enclosure remains the same external size as the length is dictated more by the battery dimensions.

    There is also now a trace from VIN to an analog pin, to track battery voltage. It will report out the current battery state when in the parked state every minute by flashing red for the number of integer volts, and green for the first decimal place. When voltage drops to less than 2, it will stop working and flash red three times every few seconds, reminding you to change the battery until it dies.

  • Added MOSFET

    jsc07/01/2014 at 14:23 0 comments

    Updated board layout with a pull up resistor and a low side switch to power down the sensor. Hoping the external pull up will reduce the timeouts and checksum errors I still get occasionally. Waiting on PCBs now to test what I hope will be the final revision.

    Also made the layout a little denser, to reduce board size.

  • Not enough power

    jsc06/26/2014 at 18:41 0 comments

    Driving the HC-SR04 from a digital pin doesn't work. From a thread on avrfreaks, it appears it can draw up to 100 mA peak power, which is more than a digital pin can provide. Soldering a large cap across the VCC and GND pins lets it work when powered continuously, but causes it to return nonsense values when trying to turn it on and off. Need to put in a transistor as a switch.

  • Too much power

    jsc06/14/2014 at 02:07 0 comments

    Turns out the whole circuit draws 11 mA from the batteries when the ultrasonic sensor is plugged in, even when idle. I have respun the board to power the sensor through a pin instead of directly from VCC, so I can shut it off when not ranging.

View all 6 project logs

  • 1
    Step 1

    Populate the microcontroller, resonator, decoupling capacitors, and ICSP header first. You can then burn a bootloader, or burn a sketch directly using the programmer.

  • 2
    Step 2

    The SMD resonator can be tricky to solder by hand, because the pads are entirely underneath the body. You may need to slightly offset the resonator to access the pads with your soldering iron. Make sure all three pads are soldered, with no bridges! If you change the Atmel fuses without the resonator working, you may not be able to recover.

    You can leave off the resonator and use the built in clock to reduce part count.

  • 3
    Step 3

    If you want to burn sketches using ICSP, you can use this boards.txt descriptor, taken mainly from the Arduino Pro Mini:

    atmega328t.name=ATMega 328 (8 MHz) - USBTinyISP
    atmega328t.upload.using=arduino:usbtinyisp
    atmega328t.upload.maximum_size=32768
    atmega328t.upload.speed=57600
    
    atmega328t.bootloader.low_fuses=0xFF
    atmega328t.bootloader.high_fuses=0xDA
    atmega328t.bootloader.extended_fuses=0x05
    atmega328t.bootloader.path=atmega
    atmega328t.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
    atmega328t.bootloader.unlock_bits=0x3F
    atmega328t.bootloader.lock_bits=0x0F
    
    atmega328t.build.mcu=atmega328p
    atmega328t.build.f_cpu=8000000L
    atmega328t.build.core=arduino
    atmega328t.build.variant=eightanaloginputs

View all 7 instructions

Enjoy this project?

Share

Discussions

Gene H wrote 01/22/2019 at 23:41 point

I finally got this sensor project up and running. While the LEDs seem to function properly to alert the driver of the distance, I seem to be having an issue with detecting when the vehicle is gone. After I move the vehicle, the red and yellow sensor LEDs seem to flash sporadically after the car is moved. What could be wrong? What should the unit be doing? When I re-park the car after 15-20 minutes, the sensor seems to be working properly to identify the distance. Please assist me with troubleshooting. Thanks!

  Are you sure? yes | no

jsc wrote 01/23/2019 at 16:29 point

Look through the Arduino sketch to get an idea of what it's doing. In short: there are several states it can be in: waiting, parking, and parked. In waiting, there is no car detected, and it is pinging every second to catch a car coming in. If it detects something, it goes to "parking" and blasts pings and flashes the LEDs. After 10 seconds of no more advancing events, it goes to "parked", where it only checks every minute. If it doesn't detect a car for five minutes, it goes to "waiting" (this can be upped quite a bit if you want to save battery life).

During the parked phase, it will blink the red and green LEDs every minute to indicate the battery level (see report_vin), red for the integer voltage and green for the fractional amount (so 2.5V will flash red twice, then green 5 times). You can disable that by commenting out the report_vin line 223.

  Are you sure? yes | no

Gene H wrote 01/25/2019 at 20:49 point

Thanks for the follow-up. I will run some more tests. I could be mistaken, but it seems like a lot of LED flashing/pinging is going on after the car is moved...longer than five minutes when it should be entering "waiting" mode with no car detected. 

Also, in your sketch, you wrote: // Must have DISABLE_ONE_PIN set to true! Not the default: edit NewPing.h to set it. 

However, in the Newping library v1.9.1 - 07/15/2018, there is no "DISABLE_ONE_PIN"...only "ONE_PIN_ENABLED". Should that be set to true or false? Maybe this was changed in this more recent library. Appreciate your help!

  Are you sure? yes | no

jsc wrote 01/25/2019 at 23:32 point

I can't reply to your last reply, so I'm following up at the top level. They must have changed the library since I wrote that. I don't remember why I specified that DISABLE_ONE_PIN had to be true, I wish I had been more explicit back then. In any case, they appear to have changed the sense of the test, so if DISABLE_ONE_PIN should be true, then ONE_PIN_ENABLED should be false... see if that works for you.

  Are you sure? yes | no

Gene H wrote 01/26/2019 at 03:35 point

I've had an interesting time messing around with the sensor tonight. I actually tried an older newping.h lib, but it didn't seem to make a difference in performance.  I did make the true-false change in the library as you mentioned. I'll keep testing it out and studying the code. Thanks.

  Are you sure? yes | no

Gene H wrote 04/02/2018 at 13:56 point

Although this project was posted/completed several years ago, I'm still quite interested in it.  I have a couple of rookie questions.  Since I haven't attempted any SMD soldering, should I try a through hole version?  Is there a schematic available?  If I do go with using SMDs, how do I order the PCBs from OSH Park?  Thanks!

Update:  Figured out how to order the PCBs from OSH Park.

  Are you sure? yes | no

Michael wrote 07/31/2014 at 20:39 point
Do you have the sketch available? I looked at source files but didn't see it. I am building a similar device with a pro mini powered by the wall (because an outlet is near). I'd like to see how you coded it out. It's cool to see someone else's take on a similar project, but going a different direction.

  Are you sure? yes | no

jsc wrote 07/31/2014 at 21:14 point
The sketch is the file Parking.ino at the top level of the github repository. Let me know if you have any questions.

  Are you sure? yes | no

Ron wrote 07/01/2014 at 22:36 point
I really one. you should see my garage back wall

  Are you sure? yes | no

jsc wrote 07/01/2014 at 23:42 point
Well, this project is almost complete, just waiting on the PCBs for the (hopefully) final revision. Have to get the power usage down so it lasts for months instead of a week.

All up costs if you want to build one yourself should be on the order of $25 or so: $10 for 3 PCBs from OSH Park, ~$4 each for the AVR and boost chip, then a little bit more for the random components. You will also need to be comfortable with SMD soldering, although there is no reason a through hole version couldn't be made.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates