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.

Dan, thank you for the extremely detailed explaination of your concept, and I see it is pretty similar to what I had in mind.  I didn't realise before that your 'robotics platform' was the Schrödinger you refer to, so I'm reading that with interest.

The hardware concept is similar too in using low resolution encoders (32 or 64 ticks per revolution is all very well, but you've got to do a lot of processing just to keep a count of the things) but I hope to get more information on direction using a compass module, although I've yet to see how that works out with motors and servos in the vicinity.  Even the the 'left brain - right brain' idea is similar to what I wrote, farming off certain functions to another processor with communication between the two halves of the 'mind'. (I hadn't looked at Schrödinger before -  honest - Obviously great minds think alike #;¬)

My robot will be a good deal smaller than yours.  I'm waiting for one of Chris's tiny tank kits which arrived in NY for JFK airport a week ago so should be here (England) any time now.  Planning on the 28x2 project board with at least one more PCB stacked on top so will be . . . interesting,


Dan, I'd be interested in what you mean by 'fuzzy logic comparisons'.  I'm planning a small tracked robot with ultrasonic sensor and a compass chip and want to do very simple environment mapping by measuring object distances at various angles. I've various ideas to try out but always welcome more food for thought.

(By 'regulated' I meant powering the digital circuitry through an on-board regulator, not with a dangly wire.  Of course the downside of this is you usually need an extra battery cell in there to give a decent voltage overhead #;¬)

This is rather handy, however a question I always like to ask myself when I am using them is "do I really care what the real world distance is?"

If I wish for my robot to react when a set distance away from an object then I sit my robot that distance away and measure the value from the Sharp IR sensor. I then use this raw value in my code, meaning that the microcontroller itself doesn't need to do any conversions. This saves a line of code or two.

It is only when I need to see the value (e.g. being fed to the computer and displayed on screen) that I would convert it to "real world" units such as centimeters in inches - and I would do this conversion on the PC.


We are saying the same thing but in a different way.  As you mentioned, you can get the number for a certain distance by setting an obstacle at that distance. In your case you decided you only needed one number, not the whole range.  In my case, I wanted the whole range so if I want to make a change, or want the robot to do different things based on different distances, then I already have a graph including "all" useable distances. I say all, because once you plot what readings you do take on a graph and fill in the missing parts of the curve, you can interpolate the missing numbers close enough without taking further readings. [i.e. -If I took readings at 5 cm. and 7.5 cm, but decided I wanted the robot to do something at 6 cm. distance, I can look at the graph and quickly interpolate that he should respond to an adjusted reading of 10 (or a raw reading of 155*).


I might decide I want him to read distances precisely, so he "knows" whether he has clearance to go between two objects, without getting stuck because it was too narrow, or ignoring a valid path that he could have taken, because he thought he couldn't make it.

As to why do I care about the real world readings? --because I am human. As you mention, the robot could care less, and using the raw readings simplifies the code. The graph is for the human to look at to help with programming and future changes therein. Not being a Cylon, the raw data just does not register well in my brain. I need to compare it to something I am familiar with.

One last question. You said you would compute the real-world values on the computer and I wondered how you would do this. Unless you plot the points, how would you come up with a formula or other method to make the conversion? Thanks in advance.


You have to remember though, These things were designed to turn faucets on and off ( and sometimes, not very well).  

Afraid I didn't understand that. Turn faucets off and on?  Are you saying that the sensors we use in robots are the same ones in sinks?  If so, I did not know that.  I've always had trouble with those. They never recognise me... --perhaps I do not reflect IR very well, especially after my hands get wet.   :-)   I see other people walk up and the water turns on immediately, but then I put my hands in the same sink and have to wave them around repeatedly before I eventually get a responce. I just get my hands wet and then the water shuts off and sometimes won't turn on again.

I thought the technology was first used by the military in the development of infrared ranging, and later branched out into turning on and off room lighting and other devices, as well as sensor arrays for telescopes, etc. Perhaps you meant the "Sharp" brand in particular? --You could be quite correct; I do not know.

I am certainly glad the robots do not respond as poorly as the sink sensors. Perhaps it relates to what controller they use in a sink? or how poorly the program was written?




I read somewhere once these are the sensors used to flush urinals in the men's room.  I often refer to the IR sensor now as the "urinal sensor".  A lovely thing to tease people about.

"And now my robot is slowly scanning you with his urinal sensor, make no sudden moves...."



Hmmm, Makes me wonder what a urinal sensor would be scanning for on a person...

--looking for splashes?

--checking whether they washed their hands?

--Hmmm, checking if the person is one of the "homeless" people?  Okay, I'm getting too gross; --sorry.  I'm outta here...  (ha ha)


Actually it's a P.I.R. sensor that's used in that sort of sanitary application #;¬)

Interestingly, one of the applications mentioned on the datasheet is 'robot cleaner'.  If I ever need something to clean my robots . . .


Very helpful Dan. If I could suggest, you should put the model of the sensor you did this analysis with. If someone should happen to be using the exact same model then they can reasonably expect to get similar results without needing to take the time to graph it themselves.