Making an IR object tracking system
| Attachment | Size |
|---|---|
| OBJECT_TRACKER_V1.7.BAS | 1.89 KB |
| MPSA13.pdf | 154.35 KB |
| MPSA14.pdf | 43.7 KB |
In an earlier tutorial on IR object detection sensors I mentioned that they could be used for object tracking. Now I show you how and my progress so far. I've also posted a challenge based on object tracking to squirt pets with a waterpistol. Object tracking with these sensors is more complicated than object detection so I'm going to try and explain it in more detail here including problems I've had as this is still a work in progress. I got the idea for this system after reading Mintvelt's post on "smooth object tracking". Frits also had a hand in inspiring this idea with his Amanda LDR of which this is basically an IR version.
The theory: The method of tracking used here is very simple. The software simply moves the servo until both phototransistors get the same amount of IR. If the object moves to one side then one sensor will get more IR than another and the servo turns to correct the imballance. If you want to track up/down as well as left/right then just make a second unit and mount it vertically instead of horizontally.
![]()
My success: This was my prototype object tracker. It was a bit jerky at first as can be seen in the 2nd video. After Rik installed a warpdrive in my code it bacame quite fast and smooth. Unfortunately I lost the video so you'll have to take my word for it. The improved code is OBJECT_TRACKER_V1.7.BAS in the attachments.
The tracking software reads the ambiant light and then turns on the IR LEDs to read the refected light. It subtracts the ambiant light from the reflected light to stop iR coming from a window causing the tracker to turn towards the light. The inputs are then calibrated to allow for component variation. Adjustment is made to the servo position depending on the difference between the calibrated readings. The main changes to my original software to prevent jerkiness was to turn off the servo between adjustments which is really compensating for the picaxe's dodgy bootstrap code. This was V3 of the firmware.
My failures: After the success of this tracker I decided to make a larger dual axis tracker with greater range! It was a spectacular failure. It had plenty of range but was impossible to callibrate as I had not considered the optical side of the design.

The problem I believe was that light from the LEDs overlapped at different distances depending on where the object (my hand) was relative to the unit. If I calibrated it with my hand 2 meters from it then it really only worked ok with my hand at that distance.
My newest array, with navy blue IR LEDs works better as I've gone back to a single phototransistor for the sensor instead of two in parallel. The idea is that fewer lenses are better. The domed end of a LED or a phototransistor is a lens that focuses the light sent or received. The IR LEDs I'm using have a viewing angle of about 30 degrees. Check you datasheet of both LEDs and phototransistor as it can vary.
This design still has problems. After looking at it shining IR onto a sheet of paper through my camera I relised that once again I was getting light from different LEDs reflecting back to a phototransistor depending on how far away the paper was. You can see the amplifier mounted seperately at the base of the cannon.
So back to the drawing board. First thing I want to change is the way my LEDs and phototransistors are mounted as they are at a fixed position and angle.
In my original prototype, overlapping light wasn't an issue. The diagram below shows why.

In comparison, the diagram of my last design shows where my problem lays. Up close the phototransistor only gets light reflected back from the LEDs next to it but at a greater distance it starts to recieve light from nearby sensors. The best solution I can think of is to have a central, compact light source that reflects back to all the phototransistors.

Mechanical callibration: By adjusting the angle and position of my sensors I should be able to do some of the calibration mechanically which means less math for your processor and a faster response time. It is also better if you can have one single lightsource to eliminate the problem of overlapping light. If you need more than one LED to get more range then cluster them as close as possible in the centre and mount your sensors around the outside facing outward slightly. If your tracker seems to be looking off centre to the object being tracked, try adjusting the angle of the sensors by small increments.
Software callibration: If this is not enough then you will need to calibrate it through software. I did this by disabling the servos and holding my hand at the maximum detection range of the sensors. Using debug to get the readings from the sensors I then divided down the larger numbers so that all readings were the same when the tracker was looking directly at my hand.
New amplifier design: My original amplifier design was based loosly on a one transistor amplifier I was taught at colledge (16 years ago). Since it worked first go I didn't mess with it but really it's not a good design as the original design was for AC signals. I've now simplified it as you can see below.

The phottransistor and amplification diode form a simple darlington transistor. The 2Kresistor was chosen as the datasheets suggested that the BC549 has the most gain with about 2mA flowing through it. The resistors could be anything from about 1K through to 10K. I would not go less than 1K because you would only waste power. More than 10K could affect the accuracy of the processors ADC due to it's input impedance. More sensitivity could be obtained using your ADC in 10bit mode but I think 8bit should be adequate and simplifies the maths.
Below is the LED array driver circuit. It is very simple and could easily be made with a NPN transistor instead of a FET with no change to component values.
This is what I used with my last design. The current is limmited to about 50mA per LED so that I didn't have to worry about damaging the LEDs if they stayed on too long due to a fault in the software while debugging.
Boosting range: So far I have used more LEDs to increase range but this has caused troubles with callibration when the LEDs were not clustered together. The LEDs I've used do have a peak current rating of 1.2A but at this intesity they could be damaged if left on for more than 100uS. I would probably use a 555 timer to control the pulse if I resort to that method of increasing range as this would protect the LEDs from faulty code. The biggest problem with this idea is that the LEDs can only be on for about 100uS. I don't think this will be enough time for the processor to read 4 ADC inputs. I can get a 2.4W IRLED that will handle 1A continuous current but that will cost me $30 AUD plus P&H. At this stage I've ordered some High intensity IR LEDs that will handle 100mA continuous. Because I'm only going to have them on long enough to read my ADC inputs I can possibly push that to 200mA or more as long as the dutycycle is low enough.
Hardware protection: This is a circuit I've designed to protect the IR LEDs if you want to push them to their limit.

This uses a 555 timer to control the timing of the pulse to my IR LEDs. With the component values shown it should pulse the LEDs for just under 100uS and then canot be retriggered for at least 200uS. This means that the LEDs cannot be damaged even if the signal from the processor stays high due to a fault in the code. In this circuit, the computer triggers a pulse by pulling pin 2 which is held high by a 100K resistor down below 2/3rds of the 5V supply. This will only happen if the 1uF timing capacitor is suitably discharged which needs at least 200uS to occur. Once triggered, pin 3 goes high. This turns on the FET to power the LEDs and begins charging the timing capacitor via a diode and the 1K3 resistor. At this point the processor can no longer trigger a pulse. Once the timing capacitor and thus pin 6 exceeds 2/3 of the 5V supply, the 555 timer changes pin 3 to a low state. The LEDs are turned off and the timing capacitor discharges by the 2K7 resistor and it's diode. After aprox. 200uS the timing capacitor should have discharged back below 1/3rd of the 5V supply and the circuit is now ready to be triggered again.
This circuit is not essential. The picaxe basic language for example has a pulsout command that can send out a pulse in multiples of 10us with a 4MHz clock. One reason you might choose to use a circuit like this, even with good code is that if an interupt occurs during a pulseout then it could cause the LEDs to be on longer than normal.
Udate: 19-1-2009
I've been experimenting with improving the sensitivity of the IR detector using a high gain darlington transistor MSPA13 which has a gain of 5000+. The BC549 only had a gain of between 200-800 depending on the individual transistor. Below is a picture of my test platform. There is a MPSA14 that has a hfe of 10000. That should be better again. These transistors can be obtained world wide from Futurlec. The MPSA13 cost 14c US and the MPSA14 is only 6c US at the time of this update.
This is a 14M with my new detection circuit on an analog input. The maximum current through the IR LED is only 25mA although the multimeter registers less than 10mA total current draw since the LED is only on very briefly. Using this setup and using the readadc10 command to maximise sensitivity the picaxe could detect the wall from about 1 meter and my hand from about 400mm. This is running on a 3.7V LiPo battery (on the right) from a toy helicopter as I'm looking at using this circuit in a micro wall racer.It would be more sensitive on 5V.
Below is the schematic for the new IR detection circuit.

I tried several resistors to increase gain. With a 100 ohm resistor I got less range but I also got less range with a 470 ohm resistor. The 220 ohms could probably be fine tuned better but was good enough for this experiment.
This is a version you may want to try as it's gain can be adjusted by the 500 ohm trimpot allowing it to be callibrated easily.




@ Sun, 2009-04-12 21:25
wouldnt it be easyer to have
@ Mon, 2009-04-13 00:15
I've done that but you have
@ Sat, 2009-04-11 22:58
The gain?
@ Sun, 2009-04-12 01:48
Transistors don't come at a
Transistors don't come at a precise gain, for example a BC547 depending on the suffix can have a gain from about 100-800.
The gain is called hfe in the data sheets. Many multimeters can measure this. I used this ability to try and match my transistors so that their gain was roughly the same (about 490).
The MPSA13 claims to have a hfe of 5000 min. Can be as high as 10000. The MPSA14 has a min. hfe of 10000.
I have found that too much gain / sensitivity is a bad thing as the sensors pick up too much in the background. Same happens if your IR is too bright.
I will be building a new version soon that will hopefully iron out some of these problems.
@ Sun, 2009-04-12 08:40
Can be more usefull make IR
Can be more usefull make IR flash at some frequency and use an RC circuit to pick from the photodiode only the same freq. or use an integrated IR Receiver, maybe a 38Khz. I've got a boe-bot, and at the 38Khz he sense about 60cm far.
I don't understand why is bad if IR shine too bright.
I'm studing Your "Making an IR object tracking system": the eight IR Emitters are used like an IR flash light?
@ Sun, 2009-04-12 09:03
When I increase the range by
When I increase the range by increasing the brightness or the sensitivity then the tracker gets confused by all the background. Because the wall of my flat are white, it detects them better than my hand which doesn't reflect IR as well. You can use modulated IR but the goal of this project was to keep it simple and cheap.
I'm trying to use PIR sensors now as they will pick up body heat. The Cow God has a setup like this on BullyBot using a thermal array but it is expensive.
@ Sun, 2009-04-12 13:00
So modulated are better but
So modulated are better but cheap, isn't it?
Yes, I've thinked about PIR too, but I don't know them well.
And for IR Receivers like http://www.parallax.com/Store/Sensors/ColorLight/tabid/175/CategoryID/50/List/0/Level/a/ProductID/177/Default.aspx?SortField=ProductName%2cProductName? They are expensive but work good.
What is the difference between PIR sensor and PIR sensor Array?
@ Sun, 2009-04-12 13:11
The difference is about $110
@ Sun, 2009-04-12 16:42
Isn't the difference that
Isn't the difference that The array includes more PIR sensors in one?
@ Mon, 2009-04-13 00:17
There is more to it than
@ Thu, 2009-04-02 21:14
maybe this is helpful
u can find some very powerful and cheap IR LEDs here:
http://octopart.com/packaging--Bag/search?q=infrared
if thats not enough than u can find whopping 10mm IR LEDs here:
http://www.globalspec.com/FeaturedProducts/Detail/High_Power_IR_LED/44686/0
also consider illuminator panels instead of leds
http://www.save-on-security.com/Infrared-Illuminators-130/JF-IL04--High-Power-Indoor-180-Degree--Wide-Angle-Illuminator-90-IR-LEDs.html
i have also find these projects similar to urs, maybe they are of some help for beginers here
http://www.phanderson.com/picaxe/ir_1.html
http://www.seattlerobotics.org/guide/infrared.html
http://meandmyrobots.blogspot.com/2008/02/how-to-make-ir-object-detection-system.html
@ Sat, 2009-03-21 15:41
have you make the project
have you make the project related to ir object tracking system.
plz advise me how to make this and plz step by step explain thanks ...reply me today ....i shall be gradful to you.....
@ Sat, 2009-03-21 15:32
regarding to circuit diagram step by step
@ Sun, 2009-03-22 03:09
If you look at the
If you look at the attachments at the top you will see the software used in one test but it will be of limited use as it needs to be calibrated to your hardware.
The tracking system works like a line follower except that it follows a reflection from an object rather than a line on the ground.
You will need to build the hardware and experiment with it.
@ Fri, 2009-02-20 06:32
Too bad I'm only an amature
Yeah, that looks awesome. I've wanted to do that for a while, but I don't know any programming languages. I'll do this when I learn PBASIC or Picaxe.
Better than most trackers I see though, nice work.
-e
@ Fri, 2009-02-20 08:06
Thanx but so far I've had
@ Wed, 2009-02-25 02:39
ive recently see a robot
@ Wed, 2009-02-25 02:42
Yes but that would defeat
@ Thu, 2009-01-29 09:06
ut oh...
@ Thu, 2009-01-29 08:51
which ir led?
@ Fri, 2009-01-30 05:37
Sorry I took so long getting back to you
I've been busy with so many half finished robots.
I'm experimenting with three different IR LEDs, the clear IR LEDS are from futurlec.
The blue LEDs in my earlier experiments including the prototype are from Jaycar.
And recently I'm trying a Vishay TSLA5100 from Farnell.
Aside from power, the TSLA5100 also has a narrow beam at 10degrees.
@ Fri, 2009-01-30 06:06
which are better for longer
which are better for longer distance tracking? say for a motion tracking camera on a 2 axis servo set up.
thanks
@ Thu, 2009-01-22 00:23
congrats !!!
you got posted on the make blog!!!
~Matt
@ Thu, 2009-01-22 00:42
Thanks Matt :)
@ Wed, 2009-01-21 23:49
Failure?
I dont think the experiment in the first video is such a failure oddbot, it apears the robot is atempting to track further down your arm in the video and perhaps this also accounts for the jerky servo too.
That suggest by effect "periphial vission" perhaps by the parabolic effect of the lens inside the phototransister and as long as it can isolate you from the walls. This is a good thing and could be usefull as is for object detection.
Maybe even without tracking by servo, then also like in the second video for object tracking.
Perhaps also sonar added to the project too for proximity checking or just using the ADC to check the value of IR reflected as you are doing now. but that points to the problem of jerky servo being totaly a Software issue or not at all but by the focal point moving across the parabola lens into its tranciver point like a splash of light at first takes a second to register before you can see.
What you have done to this point is "utterly brilliant" please understand that, but some good old fashion criticizem will help you compleatly perfect this device you have concieved of, but only if you allow it to do that..
iamdenteddisk@yahoo.com
@ Thu, 2009-01-22 00:14
I don't mind critisism, nor
I don't mind critisism, nor is IR the only option, sonar would be better in many ways except expense. The reason I've posted this before it is working perfectly is so that others can experiment as well and perhaps come up with something better or new all together. What I'm finding is that the problem is more complex than circuitry and software, the optical setup is more complex than I though. My prototype ended up working very well because it was simple. Once I tried to improve range by adding extra IR LEDs and sensors, I added complexity to the optical design.
I now have some high intensity, narrow angle (10 degrees) IR LEDs as used in remotes. I'm hoping this will solve a lot of problems by increasing range while using a single light source.
@ Mon, 2009-01-19 23:39
Four days now
@ Tue, 2009-01-20 03:24
Exxterrminnate!!
@ Fri, 2009-01-16 04:32
what if you got IR leds with
@ Fri, 2009-01-16 06:05
That will help with range
That will help with range, some IR LEDs for remotes have a 10degree angle. One thing I've found is you can have too much range. Because my hand is less reflective than the white wall behind me it see's my hand as a shadow and looks away from me towards the brighter wall even though it's further away.
Even if you don't have white walls, too much range will mean more clutter and the processor will have problems telling what to lock onto.
@ Fri, 2009-01-16 17:46
Then if you get too long of
@ Sat, 2009-01-17 02:47
That's what I started with in the prototype
The trick is to get a usefull amount of range. Admittedly IR at 940nm is starting to look less promising as a means of object tracking. Ultrasonic would work better as it does not get affected by daylight or colour. expense is the problem there. 4 of the EZ1 maxbotic sensors would cost me about $200 AUD (aprox. $135 US).
I've now got 4 PIR sensors that work on body heat (5-14um). Since it's pets that I want to hunt this may be the most accurate sensor and they only cost $1.90 (US) each. As a bonus they use a lot less power than all those LEDs.
@ Sat, 2009-01-17 00:12
auto calibration?
Would it be feasible to make the sensor auto calibrate with each transmission/reading iteration?
Start sending IR (throttled by pwm) at low intensity until the detector reaches a certain threshold. Then take the pwm value as a measure of distance directly, or rather as a measure of reflectiveness. Then blast away with full duty cycles and take another measurement.
Or something like that. I am not very sharp anymore, this late at night.
@ Sat, 2009-01-17 02:27
That is a good idea!
@ Sat, 2009-01-17 14:15
I'll hold
but your waiting music is reeally killing me!
;-)
@ Sat, 2009-01-17 14:18
As long as you die laughing
@ Fri, 2009-01-16 01:53
I had an idea!
I had an idea that i am going to try that might fix the overlap problem, group all of your LEDs in the center of the PCB (or just one uber bright one) getting supplies tomorrow working on it over the weekend
@ Fri, 2009-01-16 02:15
Yes, I mentioned that in the
Yes, I mentioned that in the mechanical callibration section.
Since then I have discovered a strange problem. With both the big clunky array and this new smaller one I get one ADC input with far more gain than the others at close range but normal gain further out. The top and bottom inputs also seem to have less gain then the left and right. This is the raw ADC readings prior to software callibration.
The thing is that each sensor board is a different design with new parts and different amplifier designs. I even tried changing the picaxe 28X1. This pattern is easy enough to correct for in software except for the left input. It's gain seems to change halfway through the range. This isn't a code problem as the same code is used for each input.
If worse comes to worse then I'll have to adjust the code to change the calibration multiplier depending on the input value but I'd rather track the problem down as it appears to be the reason for my problems. I didn't have this problem with the prototype and a 40X1 so I suspect either the breadboard or a hardware/bootstrap code bug with the 28X1.
@ Fri, 2009-01-16 03:23
is the it may be one compont
is the it may be one compont that went bad or is going bad, are detectors alll from one manufacture if not maybe the that one just doenst have the same specs as the rest
good luck tracking issue
@ Fri, 2009-01-16 03:39
That's what I thought at
@ Fri, 2009-01-16 04:47
lets say you test each
lets say you test each detector with the same ADC pin, to see if it lies within the detector circuit, if you get normal values from the same pin with all the detectors then test each pin to see which one is giving the issue it might help isolate the problem, at least thats what i would do to test it futher
@ Thu, 2009-01-15 22:45
clap clap clap
Good work Oddbot! Now go and catch up on your sleeping.
Fellow writers/builders take note: we need to read about failures as well as successes.
@ Thu, 2009-01-15 05:16
i see in the code that you
i see in the code that you use "if else" for your logic , would a "switch case" logic be better for tracking tho? i havent tried switch case with tracking due to the lack of funcional servos
@ Thu, 2009-01-15 07:05
Lets say you have a basic if
Lets say you have a basic if statement:
if(blah)
else blah
You then would have a else statement for the other parameters. If you put in a if else inthere too you catch any varibles not used by if or the else.
@ Thu, 2009-01-15 07:30
tru but i think you will
tru but i think you will have more flexible flow if you use
switch (var) {case 1:
//do something when var == 1
break;
// break is optional
case 2:
//do something when var == 2
break;
default:
// if nothing else matches, do the default
// default is optional
}
@ Fri, 2009-01-16 04:29
the if, else, ifelse is set
@ Tue, 2009-01-20 12:29
what do you mean by catch?
@ Tue, 2009-01-20 18:12
what he means by catch is
@ Wed, 2009-01-21 04:39
Do you guys realise this
@ Wed, 2009-01-21 20:03
With all due respect
I think, though misguided, they are trying to help with your code's response time via optimization.
Anyhoo, from a look at the video, I'd say response time isn't the jitter issue. I think it's actually over-sensitivity that's the issue. I'd wager it's less jittery if you use white circle of cardboard at a consistent angle to the sensors. If that's the case, then your software needs some smoothing logic.
I sincerely believe that's your jitter issue. It's reacting to every movement that it perceives (e.g the shadows between your fingers), rather than deciding if there's actual motion going on. I think you need a sliding average of say the last 5 (or 3 or 20, I don't know how fast your loop is) readings from the sensors to see if there's a trend toward a direction and decide your motion from that. It'll cause some lag, but I don't think too much.
I don't think you have faulty firmware, I think you've got firmware that's doing what you tell it too. :)
Good luck! Great Project! I've learned a lot...