We are all student drivers with no clue how to park- what if we could build a solution to help us park using off-the-shelf components? That was how AutoPark was born - a robot to facilitate garage parking and buildable by anyone with the parts. Yet, its functions make it universal to outdoor parking assistance for those tight spots where you don't have someone who can exit the car and guide you in, or mounting on an actual car to provide 3rd party drive assistance on and off the road.

Such an idea was applicable to us because we would be able to share our development with the world and other people could build similar robots; it was not too complex for beginners to make, and used typical Arduino components that you can find in many kits or just lying around. The core of the device does not require any Arduino components except the commonly available ultrasonic sensor. Thus, everyone not only has a chance to build a robot, but one that can help their daily lives. After all, what is the purpose of a robot in the long term if it doesn't improve your daily life meaningfully?

What it does

AutoPark is a robotic parking assist mounted on a tripod for use in garages, but can also be moved outside for training student drivers on proper parking distance thanks to its portable nature, or just if you're tired of having someone leave the car every time to help guide you in. An Arduino Nano powered by a powerbank runs all the C++ flashed code and integrates the key components together. By figuring out the car's distance through an ultrasonic sensor, the computer can figure out when to activate the green GO led, yellow SLOW led, and red STOP led.

An IR remote receiver and joystick make it easy to adjust the distance the car should be at, making the system workable with any garage or car type. The IR receiver also supports a variety of protocols; we have tested the device with TV remotes, and it has worked fine; the user simply needs to change the remote codes in the firmware using the Arduino IDE, which also provides an easy feedback display system to the remote code using the Serial Monitor.

The ranges for lights are as follows (setting is the user-defined distance):

-Greater than Setting + 0.75m - SLOW FLASH RED (Out of Bounds) - 
-Between previous and Setting + 0.75m - GREEN
-Between previous and Setting - YELLOW
-Between Setting and Setting - margin (can be changed in firmware) - RED
-Below Setting - margin - FLASH RED + Speaker Buzz

By implementing audio and visual cues to parking assistance, AutoPark serves as an aid for those suffering from worsening eyesight, especially if they live alone and don't have anyone that can help guide the car for them. Many of these people are elderly, meaning they drive older cars that lack the newer safety features that can save these people from making a wrong forward movement into their wall inside their garages.

How we built it

- Arduino Nano
- Full-size Breadboard
- 3D Printed Project Box
- Tripod
- Ultrasonic Sensor
- 20x4 Character LCD (Blue)
- Wires
- Analog Joystick
- IR Reciever and Remote 
- x3 LED with 330 Ohm Resistor
- Powerbank/Cable

Like all hackathons, we started with a document outlining the features we wanted our robot to have. Instead of waiting for hardware to be finished, we conquered the development with parallel work; simultaneously building the robot and coding based on outlined features to be combined on Saturday. I quick sketch helped both teams as we figured out exactly how we wanted the robot and code to work before building. During build, the one-piece 3D print was made in Autodesk Inventor, and we used Cura to process the model for printing.

It was not that easy to execute though, especially since while programming, there was no physical feedback if the code would actually work. Electrical would become one of our biggest problems as we had never made a device with this many components before- in fact, we almost ran out of wires! When it came time to combine the work of our two efforts, it took some minor debugging but we had the initial feature of the sensor and lights integration. After that, we added the these features in this order:


All features start at the planning level, and initially the plan was to have the LEDs like this:

Good, in the spot: Green
Slow, almost there: Yellow
Continue, out of the spot: Red

However, since our robot was dealing with cars, it didn't make sense to have Green mean good and stop. Green means Go! Luckily, with the power of team review we solved this issue before we had any big regrets a day later.

Good, stop: Red
Slow, almost there:  Yellow
Continue forward: Green
Too Close: Flash Red (Rapid)
Too Far to Detect: Flash Red (Slow)

Using the math we learned in physics, we knew a 330 Ohm resistor would be perfect for lowering the amperage of the 5V line to less than 20 ohms so that we would not burn the LED. This makes it brighter than using a 1000 Ohm resistor, but still saves the LED from burning. Initially we wanted to put a reflector behind the LEDs to make them easier to see, but tests in the daytime showed that our setup was bright enough to seen by any user without the reflector.

Ultrasonic Sensor

We used an Ultrasonic sensor we had lying around to determine the distance of the car, providing accuracy between 150cm and 1cm distance. Programming it utilized this code to send a pulse through the sensor (we did not use a library and did the processing ourselves) and time how long the sensor took to pick up the ping after it had reflected off the car to determine the distance away.

// read from ultrasonic sensor 
  digitalWrite(TRIG_PIN, LOW);
  digitalWrite(TRIG_PIN, HIGH);
  digitalWrite(TRIG_PIN, LOW);
  duration = pulseIn(ECHO_PIN, HIGH);
  distance = duration * 0.0343 /2; //convert to cm


The LCD was a new addition and as such we had to find a library for it. Luckily, after doing our research we found a library that handled most of our problems and found the i2C address of the LCD for us. The rest was simple, though the wires we used for the LCD were unreliable, so we had to unglue it and put new wires onto the electronics. The use of a LCD unit with the i2C chip made it much easier to wire (4 wires versus 16 wires). One of us had used the 16 pin LCD in the past and it was not a good experience. The LCD uses all 4 lines to display:

User-set distance
Warning distance
LED Color
Ultrasonic distance (cm)

Joystick Adjustment

We already used the joystick before in our last hardware project, so the joystick did not take a while to implement. However, we paid more attention to user experience and quality-of-life; we tuned the joystick specifically so that it was just perfect for adjusting the screen variable.

IR Remote

This was our biggest challenge while programming (see below). We spent the majority of our combined hardware/software development on the IR remote and getting it to work. However, once we got it working the receiver can identify many different remote protocols, including many generic TV remotes. Our code analyzes any IR remote signal that is received and sends it through the USB to the computer's COM port for viewing in the Serial Monitor. Once we had that feature figured out, we figured out the key codes specific to our remote and put those in the code. Since this debug feature is present on the final code, it can still be used by any user to program in their own IR remote; we tested and got signals with a generic TV remote as well other than our small one. We know everyone loses their remotes at least once, so that ability to add new remote types makes things simple.

The codes we determined for our remote:
0xFF02FD | Play button | Set the distance setting to the current Ultrasonic measured distance
0xFF906F | Up button | Add 5 cm to the distance setting
0xFFE01F | Down button | Subtract 5 cm to the distance setting


The speaker was used to provide audible feedback in case the car got too close to the machine as a last warning. We also ran into unexpected challenges with the speaker, but in the end we got it to buzz to signal that the car should reverse along with the flashing red LED. The buzz is unique enough to be heard over an idling engine.

Challenges we ran into

While AutoPark was streamlined in our minds, we still faced challenges getting the robot to what it is now to automate parking assistance reliably and with a user-oriented experience.

Electrical Nonsense

At first, we wanted to use a small breadboard. However, while it was capable of handling all our electronics, the number we used meant it would nearly be filled out- as we were wiring, it became a mess and we knew we had to switch to the larger breadboard, which featured much longer power rails for us to use, especially important because all the components had to be wired in parallel.

Infrared Adventure

The infrared module and remote had never been touched by us. It was not as simple as using the library, as the library itself seemed complicated to us who hadn't gone that deep into an Arduino project. For example, the Arduino example code we saw on did not compile and had many errors, so we had no clue if it was even possible to use it.

Eventually, we figured out how to use the library, with the help of a handy downgrade to a previous version. Yet, our problems were not over. When we tried with the remote we got bogus button codes that kept randomly changing. The code we programmed was unfortunately hardcoded by the library to blink pin 13 every time the receiver got a signal- our receiver was using pin 13 as a data input, so we had to move it to pin 2. After all this, the remote code finally worked. The benefit of using the library was the support for multiple receivers; not only did our small remote work, but also a generic TV remote. The user can see button codes when using the debug Serial Monitor as long as the device is connected to a computer, and modify the codes simply in the firmware to use any remote.

Speaker Conflict

We were not prepared for the IR library to conflict with the Tone PWM library we normally used to make a buzzer play a note. By utilizing the Servo PWM library instead, we mitigated the issue and allowed the speaker to make a warning buzz if the car gets too close. We also tried attempts such as using AnalogOut.

Joystick Drift

There was a slight amount of joystick drift (analog sensor and stick was not perfectly centered). This small error compounded over time, caused the setting value to shift by about 1cm every 5 seconds, extremely bad if we wanted to let AutoPark become a permanent part of the garage. Taking a page out of video game controllers, we added a deadzone to the stick that made it so unless significant movement was detected, it would not report any change in value. Additionally, we tuned this deadzone so the user still had precise distance control, though the IR remote is the easier and primary way to adjust.

Accomplishments that we're proud of

We used some new components for this hack that we had never tried before, like the speaker unit or the IR remote.

When we finished testing and filming the video, it was very rewarding for us to feel that our efforts had resulted in an actually useful product. Being a student driver, I will definitely be using AutoPark more as I learn to park better; the visual/audio feedback and adjustable settings make sense. With some improvement to the electrical hardware, it would be a simple robot product that we could send to other people to use in their own garages; after all, the body of the device is already mostly done.

We felt very fulfilled at the end because all the pieces of our project had came together. At the end of the day, all the features we put on the planning document were worked out, and when we tested with a car instead of a flat piece of foamboard, it worked perfectly. I think this shows to us the importance of choosing manageable projects that we can still get a lot of, because as always, anything can go wrong.


As we were designing and coming up with firmware planning, it became clear to us that anyone in the world could build their own AutoPark from our development. Thus, our firmware is easy to modify and we have also included the 3D printable files along with CAD files in our Github. There is no requirement to have the AutoPark be 3D printed though; just a few Arduino components and they can make one too hardware-wise, and modify or create their own firmware. This also makes it easy for us to make more AutoPass robots to help automate other people's parking. The user-centric design and usage allows for quick repairing or modification.

Those new but interested to tech can build the simple core of the device with just the sensor, Arduino, and LED, learn to code it themselves or use our documentation, and then give it to someone who needs it, like a student driver (themselves?) or a senior who needs parking assistance. The other features with the LCD, Speaker, and Remote can easily be added as well. Having worked on teaching young kids how to make their own Arduino robots ourselves, we developed the AutoPass with similar values of being universal to build and learn.

AutoPark Robot Makes it Easy to Build And Use:
- Understandable firmware / Arduino IDE to write new firmware 
- Debug sent through USB to adjust parameters or add support for other universal remote types
- Joystick has mind-friendly sensitivity tuning
- One-piece 3D print design or can use any box as enclosure
- Can be mounted anywhere, be creative!
- 20x4 LCD used for debugging and live data display
- Large breadboard for easily understandable wiring and troubleshooting
- The core of the device can be made for around five dollars when made in bulk for educators

What we learned

Adding some new "cards" to our arsenal with the IR remote and the speaker is incredibly helpful to us, especially since we are just starting into the realm of utilizing hardware to solve problems in conjunction with code. Our IR remote has 18 buttons, but default TV remotes have many more. That way, we do not have to physically hardwire buttons and can utilize a much smarter and user-friendly experience. After all, wiring 3 LEDs today was already hard because they all used a different digital pin and have to be wired to a common breadboard ground. By working smarter using a digital device such as the IR receiver or I2C LCD, we save valuable wiring and hardware electrical time to focus on the firmware itself, and also bolster our core tenet of this project: user friendliness, as if a wire comes out it will not be hard to repair compared to a mess of wires we could have.

Throughout our journey, we carefully wrote down things that went wrong and what we could improve, and wrote them in the Project Story. The next time we use these components with Arduino, we will have all the documentation and FAQ needed to progress smoothly with these components.

What's next for AutoPark

The best part about AutoPark is that the sensor system can be reversed: the sensor and display can be mounted on older cars as a 3rd party budget upgrade to provide detection warning, especially for people like us where parking into a wall might be hard because we don't have the muscle memory to know how far the car should truly go. Hardware wise, the mounting case needs to be revised to fit on more things than just tripods, and also fit the breadboard or custom PCB inside. Additionally, since we were limited by the parts we had, our sensor could definitely be upgraded into a more powerful and longer range one, at the cost of power consumption. Speaking of consumption, since the LCD's backlight can be controlled by the Arduino, we can implement a "sleep mode" that shuts off the LEDs and LCD backlight when no car has been detected in range for a certain amount of time.

AutoPark - making parking easier, one LED at a time, for anyone.

Built With

Share this project: