Skip to main content
shopping_basket Basket 0
Log in

Adding a distance sensor to the Arduino Robot


Using the PING ultrasonic distance sensor with the Arduino Robot and modifying an obstacle avoiding sketch to work with it.

A previous blog post took a first look at the Arduino Robot. Next I wanted to use the Runaway Robot sketch and this required an ultrasonic distance sensor.

Connecting the PING

I followed the instructions in the code for Runaway Robot and connected the PING ultrasonic distance sensor to TK1 on the control board, with a little research first to make sure that the wires were the right way round.

Uploading Runaway Robot

When I tried to upload the code to the robot I had a few issues: for some reason the sketch would not upload to the robot even though the IDE was successfully compiling it.

Testing the individual components

Initially I thought this might be a issue with the robot, so I uploaded a basic example sketch to it to see if this worked, which it did.

The next thing I checked was the PING and I did this by connecting to it an Arduino Uno board. I found a PING example sketch on the Arduino website and uploaded this. To check that it was taking readings I then opened the serial monitor and moved the PING so that the data displayed changed.


At this point it was clear that both the PING and the Arduino Robot were working fine independently, and that the problem only occurred when the two were connected together. This made me realise that I needed to do some more research to determine the problem.


I soon found the cause of the problem: this was because the PING is a digital device and the one suggested to use in the sketch (Maxbotix EZ10) is an analogue device. Because the Runaway Robot sketch is not designed to work with the PING, the sensor needed connecting to a digital pin and the sketch needed modifying.


Connecting to a digital input

The first issue to fix was fairly simple and meant finding an alternative input which was digital. Unfortunately the Arduino Robot's pre-soldered TinkerKit connectors are all analogue. This meant that I had to unscrew the control board so that I could gain access to the solder pads on the underside of the board, to add a new header.


I looked at the specifications for the control board on the Arduino website to see which solder pads are digital inputs. I chose TKD4 and soldered a three pin header.


I wanted to be certain which way the PING should be connected. Using the control board schematic and a multimeter I was able to confirm the correct way round to connect 5v, signal and GND.


Modifying the sketch

Next I had to modify the sketch so that it would be compatible with the PING. This was by far the biggest and most time consuming job of the whole process.

I combined elements from the Runaway Robot and the PING sensor example code. In the original Runaway Robot sketch there is a function called 'getDistance', which converts the sensor reading into a distance. However, because this particular function is designed for the analogue Maxbotix EZ10 sensor it would not work with the PING.

I could have chose to edit the code for this function to work with the PING, but I decided to keep it for reference and to create a new function instead.


The new function was called 'getCm' and used a digital pin. This needed to:

  • Set the pin to an output.

  • Send a pulse to the PING to tell it to take a reading.

  • Set the pin to an input.

  • Measure the duration of the pulse received back from the PING.

  • Use the correct calculation to convert the length of the pulse into a distance.

I took the relevant parts of the PING sketch and included it in the getCm() function. This was then integrated it into the modified Runaway Robot sketch.

The main loop could then be updated to use the new getCm() function instead of getDistance(). At this point the part of the main loop which controlled the motors was commented out so that basic testing could be done.

Testing the Arduino and PING together

To test the robot I wanted to know that it was going to work with the PING before I set it down with its motors working. By also commenting out the setFace() function which used the LCD, I was able to use another function called Robot.debugprint() to display the distance variable, which would allow me to confirm that the PING was working with the robot and the distance was being calculated.


As the PING was working with the Arduino Robot I could now uncomment the sections of code which control the motor board and draw to the LCD. Now the lines of code which control the motors were included in the sketch again I needed to test everything together.

When the robot was placed down and the sketch was uploaded everything appeared to be working OK. This was until the robot came within distance to an obstacle and had to turn and the robot just wouldn’t move. However, when picked up the wheels moved. It appeared that the motors weren’t receiving enough power. Another problem which needed solving.

Solving the turning problem

I did everything you would at first such as:

  • re-uploading the sketch

  • resetting the boards

  • charging the batteries

However, despite these attempts to fix the apparently 'weak' motors, this still resulted in no success. After spending a lot of time reading the forum it still wasn’t clear why the robot was behaving this way, so I decided to have a look at the code.

I knew that the robot's motors were working fine when running Robot.write() to go straight forward and the only time the motors seemed like they weren’t receiving enough power was when it tried to turn using Robot.turn(). After searching through the code and libraries it didn't look as though there was a way to control the motor speed with Robot.turn().

I managed to prove that there was some kind of issue with Robot.turn() by playing with the code and coming up with similar but simpler alternative using Robot.write and not including the use of the on-board compass. This new code told the robot to turn by sending one motor forwards and the other backwards, delaying, then finally stopping the motors. This would continue to run in the loop so that every time the robot encountered an obstacle it would stop, turn and repeat until there was no obstacle in its way.


With a few changes to both the board and the sketch and after initial frustration, I managed to get the Arduino Robot working with the digital PING ultrasonic distance sensor. Although this was much more time consuming than I initially expected, with perseverance the reward of an obstacle avoiding robot more than makes up for this!

As I said in my previous blog about the Arduino Robot, I think this is a great piece of kit and with so much potential for development. What I’ve done in this project is only something very basic and there is a whole world of possibilities, and I look forward to developing this more in the near future!

Trainee Electronics Engineer, currently studying towards my degree in Electronic Engineering at the University of Hudderfsield. Completed my HND in Electrical & Electronic Engineering from Bradford College 2017. Love to try new things and build interesting projects!
DesignSpark Electrical Logolinkedin