Let's Make Robots!

Making an IR object tracking system

OddBot's picture
Tracks an objects position
AttachmentSize
OBJECT_TRACKER_V1.7.BAS1.89 KB
MPSA13.pdf154.35 KB
MPSA14.pdf43.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.

Object_tracker_small.jpg

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.

IR_sensor_array__small_.jpg

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.

 

IR_tracking_sensor_2.jpgMy 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.

IR_proto.jpg

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.

IR_wrong_0.jpg

 

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.

IR_phototransistor_amplifier_Schematic.jpg

 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.

 

 

IR_LED_array_Schematic.jpgThis 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.

IR_pulse_timer_Schematic.jpg

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.

IR_obstacle_detector2__small_.jpg

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.

IR_obstacle_detector_2_Schematic.jpg

 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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IR_obstacle_detector_3_Schematic.jpgThis 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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vince086's picture
wouldnt it be easyer to have a cluster of IR LEDs in the center and 4 sensors in the corners ?
OddBot's picture
I've done that but you have to be careful about the position of the sensors relative to the leds and the angle. I did not do that with SplatBot MkII because the cannon was in the centre. I am still experimenting.
BiohazardRoboIndustries's picture
I'm wondering what's the gain on both BC547 and darlington.
OddBot's picture

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.

BiohazardRoboIndustries's picture

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?

OddBot's picture

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.

 

BiohazardRoboIndustries's picture

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?

OddBot's picture
The difference is about $110 US. Check the components section for more info.
BiohazardRoboIndustries's picture

Isn't the difference that The array includes more PIR sensors in one?

OddBot's picture
There is more to it than that. The PIR sensors used in motion detection have built in circuitry to eliminate ambiant IR.
fahad's picture

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.....

fahad's picture
does any have made the ir object tracking system ...if yes then plz give me the whole procedure how to make a project step by step how to use the processor and what should i have to burn in the controller chip.plz responce as soon as you can thanks i shall be very thankful to you.......
OddBot's picture

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.

echorobotics's picture

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

OddBot's picture
Thanx but so far I've had limited success in extending the working range beyond about 400mm. I haven't given up yet :)
echorobotics's picture
ive recently see a robot with a camera that tracks instead of IR.  its used visual basic and a simple webcam.  it has a range of a few meters.
OddBot's picture
Yes but that would defeat the purpose of this extremely cheap design that does not require any complex software.
LOLGeek's picture
I think I may have to do something like this with Jasper... Quit giving me ideas lol... :D
hey what are the specs on the IR LEDs that you are using?
OddBot's picture

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. 

which are better for longer distance tracking? say for a motion tracking camera on a 2 axis servo set up.

thanks

mattmitch's picture

you got posted on the make blog!!!

~Matt

OddBot's picture
Great! aww crap, another of my crappy videos. This is why I'm redoubling my effort to improve the quality of my videos. I haven't posted SplatBot MkII for that reason and he was finnished ages ago.
iamdenteddisk's picture

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

 

 

OddBot's picture

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.

rik's picture
without a Dalek reference? For that all you geeks ought to be ..........ed!
OddBot's picture
They must know I haven't fitted the 200MW pulsed plasma, beam weapon yet. (the MkIII fusion power cells won't be invented for another 10years).
Vendetta's picture
what if you got IR leds with a narrower beam angle?
OddBot's picture

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.

Vendetta's picture
Then if you get too long of range, get leds with low beam angle and low mcd rating :D
OddBot's picture

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.

rik's picture

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.

OddBot's picture
Making the intensity of the LEDs change to suit the enviroment, not only for white walls but also to help overcome sunlight. The PWM output directly would be no good as this is an analog system and even filtered to produce an analog output, there is a time delay required for it to stabilise when being turned on and off after callibration. It would not be a lot of time but would slow response time. A serial DAC is probably best. I'll edit this post later with some options for this including suitable schematics and datasheets. I'm waiting for some high intensity IR LEDs to arrive. When they do I'll give this a try.
rik's picture

but your waiting music is reeally killing me!

;-)

OddBot's picture
As long as you die laughing :D
slick's picture

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 

OddBot's picture

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.

crazyraver's picture

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

 

OddBot's picture
That's what I thought at first but all the components in the second circuit are new, not from the first. I also hand picked the transistors in the amplifier to match the gain (hfe range 493-501). The new amplifier is also a different design with lower output impedance. The only things in common are the processor type, cables which I made myself and check ok, the breadboard and the majority of the code.
crazyraver's picture

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

rik's picture

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.

crazyraver's picture

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

Vendetta's picture

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.

crazyraver's picture

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
}
but i think it depends on how many actions you want to perform that depend  on that varible  
 

 

Vendetta's picture
the if, else, ifelse is set up properly will catch any variables automatically whereas the case switches when a variable equals something. Like I said the if, else, ifelse catches all crazy statements.
CaptainTuna's picture
what do you mean by catch?
crazyraver's picture
what he means by catch is trigger or what it should do if nothing elses matches the varible
OddBot's picture
Do you guys realise this node is about hardware? I don't care about the software except as far as getting around the faulty firmware that causes the servo to jitter.

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...