IR technology has been around for quite a few years. A whole bunch of elements used in chip and LED fabrication turn out to be remarkably good at detecting infrared (IR) wavelengths. The number of uses has increased steadily, and continues to be refined. However, there are a few well-understood IR sensor technologies that work well in robot designs, with little additional setup.
IR actually covers a remarkably wide part of the spectrum, and some devices are better at detecting some parts of that spectrum better than others. Other parts of the same spectrum turn out to be ideal for IR LED emitters and detectors.
Here, we're going to discuss the following sensor types.
Heat sensors are simply IR sensors sensitive to longer wavelength IR radiation. In fact, heat is just that - IR radiation, by definition!
Most typical heat (or pyroelectric) sensors are very simple devices, able to detect heat at various distances. Their output tends to be digital in nature - i.e. their output(s) are active when heat has been detected, or inactive otherwise. Some sensors are divided into two separate but side-by-side sensor areas, giving the ability to detect movement of a heat source as it moves from one sensor area to the other. This is how PIR (passive IR) sensors work.
As you can see, the signal produced by a traditional pyro sensor needs a little bit of work to produce a useable signal - typically a small op-amp (to amplify the detection signal to a usable level) followed by a comparator to effect a go/no go digital result. However, many modern pyro sensors now include the associated circuitry and their output is sufficient to directly drive the input of a microprocessor.
You do need to check the datasheet for the sensor you want to use to determine if you need to provide your own signal conditioning or not.
Most pyro sensors require some kind of lens arrangement to help focus the IR wavelengths onto the sensor area. Many can be used without a lens, but they tend to have low general sensitivity and no directionality. The heat source also needs to be quite strong (both hot and large) in order for them to work.
You can easily increase the range and sensitivity by using simple glass lenses to focus the IR waves more precisely. However, don't be tempted to use cheap plastic lenses, as these tend to block IR wavelengths quite dramatically! You'll also find that by using lenses, you can even detect people's heat signatures through a brick wall. I used to work in an electronics shop that had repeated false alarms, until we realised that people walking past the rear wall, and even car headlights from cars parked behind the store, could set off the sensor! So they're definitely quite sensitive devices!
It's absolutely possible, using the right lenses, to get a simple $2 PIR sensor to work at a distance of 70m or more. Of course, as the range (and resolution) increases, the area covered by the sensor decreases. So you do need to select a lens combination that works for your particular needs.
Many modern pyro sensors come with an integrated lens or lens sets, so you can experimentally determine the optimum configuration for your robot. If you can find a pyro sensor with integrated signal conditioning AND a good lens, you may have a one-part solution right there.
There's one other type of IR sensor, which is usually used in combination with an IR LED light source. This is the IR photodetector or phototransistor.
Phototransistors react to a much narrower IR spectrum than pyro sensors. In fact, you generally have to select a particular LED emitter/detector pair in order for them to work correctly. Many different manufacturers produce both emitter and detector in a single, easy-to-use package. These packages can work by reflection (the emitter and detector are side-by-side), or by transmission. In the latter case, the emitter is on one side of the package and the detector is on the other, with a slot or cutout between them. A metal or paper slotted disk is inserted between them, and as this rotates, the detector outputs a series of pulses corresponding to the pattern of blocking and transmission through the slots in the disk. This is how all mouses work, although some high-resolution mice don't use disks with slots, but instead use a pattern printed directly on the mouse's ball.
Because the phototransistor reacts to light so quickly, it can be used instead of a traditional CdS (Cadmium Sulphide) photocell. It tends to have a much narrower light response than a photocell, and reacts many thousands of times more quickly to the same light changes.
Here are two examples of detectors, a reflective sensor on the left and a transmission sensor on the right.
The advantage of a photodetector (compared with a pyro sensor) is that the photodetector is many thousands of times faster in responding to IR wavelengths than the pyro sensor. This allows the use of these in very small, fast detector units that are mounted on the spindles of electric motors, to produce a series of pulses as the motor rotates. This functionality is called an optical encoder.
Optical encoders are the lifeblood of most robots. They allow the CPU to be informed when, and by how much, the motor is turning, which can then be used to calculate the distance travelled (this is called odometry). The more pulses per revolution, the higher the resolution, but of course the more work the CPU has to do to keep up with the pulse train! If, like Rocky, you have one encoder per wheel, you'll need to limit your pulse count to ensure the CPU has enough time to do all the rest of the work! The latest version of Rocky bypasses the CPU altogether, and the encoders are each directly connected to a 32-bit counter, which gives an overflow distance of about 2km!
The higher the number of encoder segments, the shorter the distance the wheel needs to revolve for each pulse count, which leads to fewer odometry errors. Most such errors are caused by slippage - the wheels don't have perfect grip on all surfaces, so the wheel rotates more than the robot travels. Even though it's a tiny error each time this happens, the errors add up geometrically over time. So the longer the robot travels, the more errors it accumulates, until it can be out by ten percent - or more!
Obstacles also add to the errors, even small obstacles - if the wheel doesn't get stuck outright, it has to travel further - up, over, and down the other side of the obstacle - while the other wheels travel a shorter distance over the flat surface.
Smaller wheels are much worse in terms of accuracy for long travel distances, since the contact area (the part of the tyre in contact with the actual surface) is much smaller; and small wheels have far more problems with obstacles. Even small cables (less than 5mm in diameter, or even single wires) are enough to add a few percentage points to the odometry error each time! Wider, larger diameter wheels are better in this respect, all things being equal, and they allow the robot to navigate in a straight line with fewer errors. However, larger (and especially wider) wheels slip more when turning, which adds to the odometry errors there!
Softer tyre compounds will help greatly, but too soft compounds simply allow the wheel to 'float', and the soft compound 'squishes' around and leads to more errors. But if the tyre compound is too hard, it will have poor grip on all surfaces, and the errors will accumulate there too!
The best compound is one that you can slightly mark with your thumbnail, but which returns to a smooth surface after a second or two. Foam rubber compounds, which are light, cheap, and popular, are probably the worst in most regards. True rubber, slightly sticky, is a great solution to the problem, but it can be difficult to obtain for your selected wheels.
To calculate the odometric distane (the distance traveled per pulse or per n pulses), simply multiply the wheel (and tyre!) diameter by pi, and divide that by the number of black encoder marks.
In Rocky's case, the wheels are 55.88mm diameter (yes, the decimal points are important!), which gives a calculated circumference of 175.55219748 mm. Dividing this by 64 (the number of encoder 'stripes') gives us *approximately* 2.743mm distance traveled per pulse. See? Easy enough!
Why are the decimal points so important? In fact, why is measuring wheel diameter important again? Let's look at some examples using Rocky and see what happens as we fudge the figures.
per pulse (mm)
|Pulses per metre||Actual Travel
Now, none of those figures sound like a hell of a lot of error, right? Most car speedometers are around +/- 5% (analogue or digital), so what's a worst-case scenario of 1.6% between friends? After all, we're only talking about a few millimetres, right?
Let's look at that worst-case scenario. If your wheel diameter is 55.88mm, but you incorrectly measure it as 55mm exactly, then when your robot thinks it's traveled a metre, in reality it's actually traveled 16mm further (370.4 calculated pulses per metre, times the actual distance per pulse of 2.743mm).
So if you were to try and navigate the perimeter of a 5 x 5 metre square, you would end up not on the spot you started from, but over 30cm away from that point. And this doesn't take into account wheel manufacturing tolerances, steering bias, turning (heading) errors, and so on.
And this is for a measurement error of just 0.88mm. If you're trying to measure really large wheels (like trolley tyres), the error could easily be significantly greater. So measure twice, calculate, and test, test, test.
So while this robot is running, it's always traveling just a little bit further than estimated, and the error keeps on accumulating, and the robot runs into things it shouldn't (which is bad, but that's what proximity sensors and ultrasonics and GPS is for!) Well, yes and no...
GPS won't help if you're indoors - the best you can hope for with GPS is +/- 10 metres - on a good day, in the country, with no clouds and no metal in the building or its surrounds! More typically, GPS will resolve down to +/- 50 metres (if you have the time to average dozens of readings and throw away the wildest ones that say you're in the ocean) , and that's enough to put you not just in the wrong room, but in the duck pond!
This is the primary reason "sensor fusion" was developed. Please check out the Sensors Main page for more information on narrowing sensor errors. However, sensor fusion is only as accurate as the most accurate sensor - and odometry is not as accurate as you'd imagine. Hopefully these bits of information will help to minimise any problems you might have.
If your robot is designed to run and keep running, the longer it runs, the more the error increases. So even going backwards and forwards over a straight distance, your errors, as they accumulate, mean you'll think you're somewhere you're not - and that's about as bad as it gets for a robot.
Now, nobody in their right mind is going to do some rough calculations and assume their robot will work the way they figure it on paper - there are always gremlins you'll need to work out by trial and error, in addition to calculations. Testing's the key here - and don't just test in one direction - test both forward and back, and test repeatedly, in hot weather and cold, moisture and dry conditions. One of the best tests of encoder accuracy is to perform a square-turn - mark out a 5m x 5m square on a large concrete or other flat surface with similar traction to your robot's designed use, start it off in one corner and get it to follow the square back to the starting point. Then test it in the other direction! This will show up heading errors, steering bias, and odometry, all in one test.
Maybe a sumo-bot or a bumper-bot can get away without doing some encoder calculations, but if you've invested significant time and learning (and money!) in your creation, you do need to know where some of the pitfalls are!
We'll treat both types of encoder (reflective and transmissive) as one type, since that simplifies discussion quite a bit!
You aren't limited to using optical encoders as wheel revolution counters. By adding a second detector offset from the first by half a "step", you can tell which direction the wheel is turning! This is called a "quadrature encoder", and many modern microprocessors are kitted out to automagically handle this kind of encoder, with a counter and a sign bit to indicate direction.
To add an encoder to an existing motor is almost as expensive as (or more expensive than) buying the motor with the encoder already attached. Some manufacturers do produce encoder kits that slip over the shaft of an existing motor - but these can easily cost over $250 each!
A much more satisfying way of achieving the same effect is to make your own encoder. It's not nearly as difficult as it sounds!
You can opt for either the reflective or transmissive option, but it's quite a lot simpler to go with the reflective encoder. This is because using a transmission encoder requires some pretty good cutting and mounting skills, which can make that a very frustrating process. And then you still have to figure out a way to mount a transmissive encoder wheel itself, no mean feat! Plus, it has to be mounted very precisely, as does the detector, or you'll risk contact between the encoder and the sensor. Finally, it means having access to a fairly long axle, and the ability to precisely mount the encoder disk on the axle pretty much perfectly (to minimise vibrations and so on).
By far the simplest and most reliable means of doing this is to find an encoder pattern with the right number of segments, printing that off, then mounting that to the inside of the wheels you want to monitor. Then you can place a reflective transmitter/detector pointing at the encoder disk, and hey presto! you're up and running.
To assist in making encoders, whether reflective or see-through, I've found this encoder-printing file a very handy utility. It's a postscript file which you can edit in any text editor to change some simple variables. By making a couple of very simple changes, you can control the inner and outer diameter, the number of segments, and the overall diameter to suit any requirement, all at full laser-printer resolution.
A sample output file generated by encoderdisk.ps. This example is for Rocky's wheel rims.
Here are some examples of the use of the file. In most cases, only one line of code (segments) needs to be edited! If you'd like to see some higher-resolution examples, click on the images below. But please note, the 360-segment sample is only available at 2400dpi resolution!
|Rocky's 64-segment disk
(Filesize : 1.6Mb)
(Filesize : 1.6Mb)
(Filesize : 1.6Mb)
|12 segments plus quadrature
(Filesize : 1.6Mb)
|Closeup of 360 segments
(Filesize : 102Mb)
If you have access to Adobe Photoshop, you can edit the .ps file in a text editor, save it, and open it in PS. You can print it directly from there, or save it and send it to a printshop for printing on metal or mylar for non-reflective encoders.
Other mainstream painting and drawing applications may also work, but I've only tested it with PS. All versions of Photoshop should work, as should GhostScript and other postscript renderers.
However, you need to be aware that for a segment count of more than about 100, you'll need either a very large wheel diameter, or the ability to print at very high (>900 dpi) resolutions. At these high definitions, even laser printers will have difficulty printing a clear result. (One way around this is to limit the internal diameter of the segments).
A third use for IR transmission is the use of remote control transcievers. These are usually a microprocessor-controlled transmitter which you hold, and a matching receiver that decodes each button press and presents it to the robot's microprocessor for further actions.
A typical IR remote control receiver/decoder IC package. Note that in addition to the power pins, there is a third signal output pin.
Most modern encoded receivers are fully integrated, which means you no longer have to build phase-locked loops (PLLs) or signal conditioners and trailing encoders. It's all in a single 3-pin device, which generally works from any "universal" remote controller. You can also build your own (which is a heck of a lot more fun, but quite a lot of work).
You can use the remote control decoder to send simple movement or control commands to your robot; unless you also build a second transmitter on the robot, this is usually only a one-way communication option.
RC capabilities can be very handy for testing various sensors and motors and control circuits before starting to write code for them. That way, you can test the operation of servos, LEDs, sounders, and various other outputs without having to debug source code. Of course, you still have to write some code to control each output, but you can learn more quickly by sending predefined commands to various outputs than trying to figure out where in the code your commands are being parsed or sensed incorrectly!
Plus, it's fun seeing parts of your robot work before you get bogged down in coding!
Finally, we'll discuss distance-sensing or proximity IR sensors. (You'll see a little later on why they aren't usually called "distance" or "measurement" sensors by the manufacturers.) These are fairly new on the market (there was no such thing when I started designing Rocky in June 2000!), and can be used instead of, or in combination with, ultrasonic sensors, to determine object distances around your robot.
The typical IR proximity sensor (IRPS) looks a lot like a reflective encoder transmitter/receiver, but usually the transmitter LED and receiver transistor are well-recessed to avoid "spillover" (where some light 'leaks' from the emitter to the detector).
A fairly typical IRPS (infrared proximity sensor), made by Sharp
These work by transmitting an encoded IR beam, and measuring the amount of light returning to the detector. Of course, the amount of light reflected from a surface not only depends on the distance to the surface, but also how reflective the surface is. A black velvet surface reflects less than 10% of the light falling on it, in comparison to a typical wall (30-60%) or piece of white paper (90%). So all these factors have to be taken into account when calculating the distance. This is why manufacturers call these devices 'proximity' sensors instead of 'distance measuring' sensors!
Light travels at, well, the speed of light (299,792.458 km/S). For comparison, ultrasonics, which use sound waves, travel at just 0.3432 km/S!
So to measure a small distance with TOF measurements using light, like 1 metre (a typical distance for most IRPS), the circuitry has to be able to resolve down to 3.3nS (nanoseconds, 1 billionth of a second). To measure a more useful minimum distance such as, say, 5cm, that resolution has be down to 165 pS (picoseconds, 165 thousand billionths of a second!). That's far beyond what current electronics can cope with, given that a typical CPU clock period is between 50,000 and 1,000,000 pS!
When you think about it, the circuit to and from the microprocessor would usually be longer than the distance being measured, so any electronic means of starting, stopping, and sensing an electrical signal is also limited by the speed of light. (More accurately, it's the speed of electron movement in copper, which is a factor of ten times slower than the speed of light in air!)
So instead of measuring the unmeasurable, manufacturers measure either the amount of light reflected, which is inversely proportional to the distance, or they measure the angle of reflection, which requires extremely expensive and delicate sensors.
Laser measuring systems are much more accurate than IR or ultrasonic measurements, since they measure the phase difference between a precisely modulated light beam and its reflection. However, the calculations needed to convert the phase relationship of light modulated by up to 5 different frequencies simultaneously are staggering. This puts laser distance measuring sensors in the thousands of dollars price bracket. However, they can typically measure distances from less than a metre to many tens of metres, down to a resolution of a few millimetres. If you need that resolution and range, laser DMEs are the only way to go!
As I mentioned earlier, IRPS suffer from reflectance issues. Smooth, light-coloured surfaces surfaces reflect more light back to the sensor, so they appear closer than they really are. On the other hand, dark, non-reflective, or rough surfaces don't return as much light, so they appear further away than they really are. That's a bad mistake to make when your robot is navigating its way around using just IRPS! If your robot is navigating in a very light, reflective environment, it will think the walls and objects are closer than they really are, and may get stuck in an area where it's actually quite safe to move! And if it's navigating in a dark, dirty area, it risks bumping into objects that it thinks are further away than they actually are!
Since there's no simple, reliable way of determining what kind of a surface an obstacle has, the robot must rely on sensor fusion. That's why it's always best to combine distance measuring sensors - using ultrasonics together with IRPS to "average out" the errors between the two types of measurement. And then use bump sensors for a last-resort emergency.
There are also many, many designs out there on the internet using unmodulated IR sensors. That's always a bad mistake to make, since then the ambient light will totally confuse the robot - if your robot is navigating around fine, then somebody turns the lights off, get ready for some collisions. You can minimise this by also including an ambient light sensor on your robot. Then you can recalibrate the IR sensors based on the amount of light reported by the ambient sensor. Of course, this only works if the area the robot is working in is uniformly illuminated, AND the ambient light sensor is pointing in the same direction as the IR sensor. This can also be confused by fluorescent lighting, which flickers at the mains frequency.
So the answer is to ensure you use a modulated light source to eliminate problems with ambient light. Typically, a high frequency modulation, like 38kHz, is sufficient to eliminate ambient light. This frequency range also means you can use sensors and emitters designed for remote control, since that's close to the frequencies used in those devices.
Otherwise, cough up $25 and get a commercial sensor, and you don't have to worry about any of that!
Hopefully this gives you enough information to help you decide where, and what kind, of IR sensors to use.
Please also check out our pages on contact and ultrasonic sensors, where you can learn how to use those devices, and what to expect when you do!
At this build point, apart from the 4 wheel encoders, Rocky doesn't use other IR sensing of any kind.
Eventually, I'll add IR distance sensors to back up the sonar ranging, power budget permitting.