Let's Make Robots!

Sharp IR-Sensor Frustrating You?

How to relate the IR-sensor output to measurements you can understand.

You have probably noticed that the "distance" returned by a "Sharp" IR sensor is not in specific units of measure. As the IR sensor approaches an object, (or vice versa) the readings are higher and higher numbers until you get one or two inches away (2 to 10 centimeters).  Any closer and the numbers drop again.

Note: This also relates to a post from a year ago. http://letsmakerobots.com/node/6511


Latest change (28MAR2012): Just fixed some typos.


ADDED (17MAR2012): Now, I am sure you realise that the robot can work with any numbers; it doesn't care that the values are not in centimeters nor inches nor any other standard measurements. The key is that in order to program your μ-controllers for these sensors, you as a human need to understand what the values represent. The easiest way to do that is to translate these odd numbers into standard distances a human can understand.


I will note that these distances will be different for different models of IR sensors.  Consequently, the graph that I present below only works for the exact type of sensor I'm using, (ADDED: Which happens to be a GP2Y0A21YK0F).  Even if you use the exact same model, it may not give the same results, --for instance you may be using a different processor or a different analog-read command.  What you will need to do is make your own graph.  I will explain.

Using a ruler I sat an object at exact distances from the sensor.  I happened to use inches, but you can make your graph using centimeters, instead.  You could set an object at two centimeters away, four centimeters, six centimeters, (etc.) and then run a test program on your microcontroller to get distance measurements from the IR sensor, and display them on the screen.

Make a list of all the distances you checked and the value returned from the sensor.  I took multiple readings, so I could get an average, since the sensor does not always give exactly the same number with each reading.

Now you can use a draw program on the computer screen or simply take a piece of graph paper (or, make a graph, drawing it with a ruler).  Mark off the vertical of the graph in inches (or centimeters) and mark off the horizontal of the graph in numbers, at or above the largest value returned by your sensor. I felt that the higher number coming from shorter distances was a little confusing, so I reversed the numbers so the values increased as distance increased.  It is easy to do this.  Just subtract the returned values from a number larger than the largest one.  For my sensor, I subtracted the returned values from the number 165.  Voilà!  I now had a list of numbers that increased as the distance increased.  I am including the following picture as an example to show you what I mean. My graph may not work for your sensor(s). For instance, I have seen another sharp sensor that return values up over 550, and ones that have a minimum distance of four to six inches. You can mount your sensor back from the edge, so the "too close" readings will never occur.

Even though I did mine in Imperial measurements (inches), I also included centimeters on the right hand side of the graph below, for your convenience.

 (Remember this graph was reversed just because I liked it better that way. -Note the "actual reading"s in the grayed out numbers of the included table.)


ADDED NOTE (19 MAR 2012):

Within my PICAXE programming, I used the values in a subroutine called GetRange

to tell me rough distances to the nearest object the IR sensor sees.

( I used the picaxe SELECT / CASE command to assign distance in inches to b25

and during testing the SERTXD command displayed the value on the PC terminal.)


readadc 1, w8 ` 1 refers to pin A.1 (raw distance comes back stored in w8, but only b16 is pertinent.)
pause 10

case >= 155
b25 = 2 : goto inchset
case >= 135
b25 = 3 : goto inchset
case >= 105
b25 = 4 : goto inchset
case >= 90
b25 = 5 : goto inchset
case >= 75
b25 = 6 : goto inchset
case >= 65
b25 = 7 : goto inchset
case >= 58
b25 = 8 : goto inchset
case >= 53
b25 = 9 : goto inchset
case >= 49
b25 = 10 : goto inchset
case >= 46
b25 = 11 : goto inchset
case >= 43
b25 = 12 : goto inchset
case >= 41
b25 = 13 : goto inchset
case >= 39
b25 = 14 : goto inchset
case >= 37
b25 = 15 : goto inchset
case >= 36
b25 = 16 : goto inchset
case >= 34
b25 = 17 : goto inchset
case >= 32
b25 = 18 : goto inchset
case >= 29
b25 = 19 : goto inchset
case >= 26
b25 = 20 : goto inchset
case >= 23
b25 = 22 : goto inchset
case >= 20
b25 = 24 : goto inchset
case >= 16
b25 = 30 : goto inchset
case >= 14
b25 = 33 : goto inchset
case >= 11
b25 = 36 : goto inchset
else b25 = 999
sertxd("Clear beyond 3 feet ")
     ' beyond 3 feet (about a meter) was far enough away to not matter to the robot.

sertxd("Sensor reads object about ",#b25," inches away.")


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Thank you.

 --And as I noted above, I used the GP2Y0A21YK0F IR-sensor, but in another answer above, I also note that to get the same readings (barring chip manufacturing differences) you would also need to be using the same processor and even the same command. I'm using the picaxe 28X2, which has two read commands for ADC. The ReadAdc command is an 8-bit read (0-255), while ReadAdc10 is ten bits and gives the analog input a digital value between 0 and 1023.

Because of the multitude of different possible combinations is why I said it would be most logical to make one's own graph, simply using this idea as a template to plot the numbers your own installation dictates.

I think the most important thing you have shown us here is that the corelation between what the adc reads and the actual distance is not linear as one would expect. I was a bit slow to realise this.

I know when you expect one thing but it does something else it can be confusing.


Nice one, Dan! Thanks :)

There is a lot of confusion about the indicated IR value and the actual measured distance in i.e centimeters.

Thank you for sharing this data with us and clarifying this issue.