Ultrasonic motion tracker

B

bulldog

New Member
Hi All.

I'm building a "Head" that can track movement left to right and vice verser.

The hardware:
2x SRF05 u/sonic sensors.
1x servo with the guts ripped out and stop filed off.
1x Picaxe 18A
1x axe033 lcd module (just so i can see what the u/sonics are doing)
1x 555 h-bridge (credit crunch and all that you know. All i had were 555's so i had to make a plan)
http://www.electronicsforu.com/EFYLinux/circuit/sep2004/CI-02-DC_Motor.pdf

The problem:
It sort of works, tracking me as i walk past (at about 0.0001 km/ph just faster that a snail at full tilt) it at about a distance of about a meter, very jerky and won't keep still even when i come to a complete stop. more often than not it will get tired of me just standing still and just head off to track .....well i just don't know what!!. the other problem is that it only for a few miniutes then it locks up and will do nothing more.

My thoughts:
For what their worth, i think that the gearing on the servo is not fine enough therefore with every pulse of the motor it moves just off the target and has to start all over again. This becomes a vicious cycle untill it misses the target colmpetely and foucses on the next nearest thing, even then it does not keep still.
I think that the biggest problem is with the code. Here's what i've got so far, i know that there's a mistake in it but i just can't see it.

PLEEEEEEEEASE can anyone help.

symbol trig = 0
symbol echo = 0

symbol trig1 = 1
symbol echo1 = 1

symbol range = w1
symbol range1 = w2

main:
pulsout trig1,2
pulsin echo1,1,range1
let range1 = range1 * 10 / 58
pause 10
serout 3,N2400,(254,192,"range ",#range," ")
pause 10
pulsout trig,2
pulsin echo,1,range
let range = range * 10 / 58
pause 10
serout 3,N2400,(254,128,"range1 ",#range1," ")
pause 10
if range < range1 then gosub cw
if range1 < range then gosub ccw
goto main

cw:
toggle 5
goto main

ccw:
toggle 4
goto main


p.s the u/sonics are about 5cm apart.

thanks
bulldog
 
Last edited:
E

eclectic

Moderator
Bulldog.

A quick thought :
Code: 
if range < range1 then gosub cw
if range1 < range then gosub ccw
goto main

cw:
toggle 5
goto main

ccw:
toggle 4
goto main
Do you mean GOTO, rather than gosub?

Gosub without the "return" could seriously confuse the Picaxe.

It would help if you posted the FULL program and the circuit.
For example, what do the toggle commands do?

e
 
Last edited:
W

Wrenow

Senior Member
Bulldog,

Besides the gosub/goto syntax issue, I am curious as to why you gutted the servo and used a different circuit. By "filing the top," but your other comment about the gearing I am assuming you mean you removed the physical stop, but left the gearing?

Are you trying to track for 360 degrees continually as you walk around? If it is a head, you would think it would have a limited range of motion and a regular servo with its positioning integrated electronics would work OK. Without some type of positioning sensor to report position (which the servo has, internally), I am having trouble figuring out what use this would be in a system other than just physically following someone with the head. Or are you never going to want to know where the head is facing?

Regardless, looking at your 555 timer bridge, it seems to be a tad coarse. According to the link you gave, it only acts every 500ms, while stock servos update position every 20ms.

If you want to go the 360 degree rotation route, you might consider using a Vex Robotics motor (basically a continuous rotation servo with an ESC or Electronic Speed Controller built in) which would give you much finer control of the speed in both directions.

Or, if you do not need 360 degrees continuous rotation, just use an unmodified servo (some new models go 180 or even almost 360 degrees, and some sail-winch servos actually go more than 720 degrees).

Another thing to consider, if you have not - how physically close are the sensors? Too close might be difficult to differentiate, too far may cause an awful lot of spurious readings depending on room layout and the range of your ultrosonic sensors. I have no clue what the optimum spread would be for your application, though.

Cheers,

Wreno
 
B

bulldog

New Member
eclectic,Wrenow

Thanks for the comeback guys.

eclectic:
thanks for the correction on "gosub". to be honest i used toggle to try and slow the whole thing down, initially i used "high 5&4" in cw and ccw but it caused the head to swing wildly about such that the reading on the lcd froze.
p.s this is the whole programme...circuit will follow.

Wrenow:
The servo i had was an old one out of an r/c car previous owner applied 12v to it to see what would happen, thankfully the motor was ok.
just to put you all in the picture, the head is for a display during parents evenings (i work at a school) that will have a webcam in it with the image displayed on an interactive white board. it will rotate just about 360deg but have a leaf switch to set both cw and ccw limits. I is a project that i'd like the 6 formers to do but i need to get my head round it before i let them loose on it.
however it looks like i will need to spend a bit of money on it if i'm going to succeed.
Thanks for the info on all the different types of servo that are available i didn't know that there was such a variety.
p.s i want the head to only activate when the target is about a meter and a half away.

Thanks for the help i'll keep you posted
 
M

MFB

Senior Member
feedback?

How have you mounted the sensor on the servo? You may be getting micro phonic feedback between the gearbox and the sensor or electronic noise from the servomotor. Is it too late to consider a change from an ultra sonic to a PIR sensor?
 
B

bulldog

New Member
D

Dippy

Moderator
Nice project, but I can't see in your code how it determines direction of the target passing across in front of it..? Or is it assuming one-way traffic?
It does two quick samples and if A>B then pan left - or vice-versa. How does that tell you direction if the sensors are stationary... or is it moving as in scanning? I may have missed that, oops.
And if you move towards it (or away from it) then it'll pop into cw: or ccw: won't it?

Also, due to the variations in the distance measurement does it always show exactly the same distance if you stand still?
I realise your "let range1 etc" equation will reduce variations at a constant range but is it enough?
Bearing in mind as you walk then various parts of your anatomy jiggle.
Should the pauses be longer to allow significant movement of target?

I really can't see any benefit in using the suggested PIR, which has a digital output. Slow to respond, wide-angle and on/off.
If, however, you did some analogue PIR stuff then I could see the benefit.
 
D

Dippy

Moderator
Oh, I've just had a re-read. 2 sensors. At slightly different angles I guess. Bearing in mind the 'spread' of a U/S sensor is it angled enough?
 
B

bulldog

New Member
i must be honest i had not gone as far as what would happen if the head was for example pointing left and a target came in from the right.
As a quick thought maybe 2 possibly 3 PIRs' positioned such that they were static and covering all approach routes.
Active when the u/s are inactive for a predetermined time and inactive when the u/s are active until they are inactive.

So i think it could run something like this:

u/s inactive

PIR (a,b,c) active

target approach at PIR b

u/s come alive and move to position b (thanks Wrenow for the servo info I&#8217;ve managed to
convince the minister of finance my plan for
world domination rests with this purchase)
PIR inactive

u/s then do nothing till target comes within predetermined range (if range <= X)

target comes into range, the closest u/s pulls the servo for its&#8217; benefit forcing the other u/s to do the same until equilibrium is achieved (I can see a possible problem here, 2 u/s fighting over who gets a better look)

target moves , u/s fighting causes servo to &#8220;track&#8221; target

targets out of range or no targets at all for predetermined time

PIRs&#8217; active

Just a quick question about PIRs' can you get some that have an analogue output.
I was even thinking of maybe useing ir sensors with a single pulsed ir source.
 
B

bulldog

New Member
BeanieBots
i like the cmucam but in this case the main aim is for our 6 formers to get used to input-processor-output relationship.Also the relationship of software with hardware. These days you need a bit of whizz-whizz bang bang to keep their attention away from texting their next bowel movements to their girl friends. So when i pitched this project to them they came up with some rather bizzare alternative uses for the head, one i particularly liked was to shoot ping pong balls at cats that enter your garden to leave you little parcels on your lawn.
 
B

BeanieBots

Moderator
Thinking about this a little more, it is a very similar analogy to how I make robots find the largest open space and steer towards it avoiding obstacles. It is the same problem except your obstacles move while the 'robot' stays still and you want to 'steer' towards the obstacle instead of away from it.

I find using IR range finders the easiest way of doing it. They are also cheaper and easier to use than US sensors.

The method used has the horrible description of "vector forces" but it is quite simple really. You can either have a single sensor which sweeps or use two or more sensors which are fixed. Either way, you end up with a "map" of angle and distance. Each segment of the map then contributes a vector which is a virtual force applied to where your head points.

Hope that makes sense. It's easier than it first sounds.
 
B

bulldog

New Member
BeanieBots.

I had a look at the ir range finder... if using two of them do you use the difference between the two to decide what direction the servo would turn.
 
B

BeanieBots

Moderator
bulldog said:
BeanieBots.

I had a look at the ir range finder... if using two of them do you use the difference between the two to decide what direction the servo would turn.
Click to expand...
Yes, that's pretty much it for a basic two sensor arrangement.
Use the analogy of a robot whos mission is to go down the center of a corridor.
The simplest sensor would be two range finders one each side looking out at 45deg. If one sees an 'object' closer than the other, then steer away from that sensor. You need to reverse that to track and 'steer' towards the object.
 
B

boriz

Senior Member
Couple of possible problems:

555&#8217;s only source/sink a maximum of 200mA. This is not enough to drive a standard RC servo motor. You should provide upto 1A for it to work properly.

Code: 
if range < range1 then gosub cw
if range1 < range then gosub ccw
goto main

cw:
toggle 5
goto main

ccw:
toggle 4
goto main
There seems to be no facility for stopping the servo when it has successfully tracked to the target and the ranges are similar. Try something like this (Pseudo code):

Code: 
Do
   /*do range readings*/
   low cw_pin:low_ccw_pin
   Diff=range-range1+30000
   If  diff<29990 then
      High cw_pin
   elseif diff>30010 then
      high ccw_pin
   endif
loop
This allows for a range difference within 20 to stop the head. Adjust this value to suit. PIR sensors only detect motion, and only warm objects. This could be a problem. US rangers should be ideal for this app. Just don&#8217;t operate them at the same time so they can&#8217;t interfere with each other. The +30000 is a frig because PICAXEs can&#8217;t use &#8211;ve numbers.
 
Last edited:
B

bulldog

New Member
Boriz
The code that you have is completely unfirmilar to me as i'm still a simpleton please could you explain it out for me. Part of me just wants to copy it out and fiddle with it till it works but that not the way i work
 
B

boriz

Senior Member
Assuming that’s not sarcasm, here’s a fuller explanation.

Code: 
Do   ;start of main loop
   /*do range readings*/   ;get range info from both US detectors
   low cw_pin:low_ccw_pin   ;switch the motor off, head is stationary
   Diff=range-range1+30000   ;establish the difference in range
   If  diff<29990 then   ;if the difference favours clockwise
      High cw_pin   ;switch motor to clockwise
   elseif diff>30010 then   ;if the difference favours counter-clockwise
      high ccw_pin   ;switch motor to counter-clockwise
   endif
loop   ;repeat
The tiny delay between switching the motor off, and switching it to turn CW or CCW will have little effect due to mechanical inertia. So the movement should be smooth until it tracks to target. It was intended as Pseudo Code so that you can write your own version. On review, it would probably perform a little better with the ‘switch motor off command’ moved as close as possible to the ‘switch motor on’ commands, and to add a small pause at the end of the loop. Thus:

Code: 
Do
   /*do range readings*/
   Diff=range-range1+30000
   low cw_pin:low_ccw_pin
   If  diff<29990 then
      High cw_pin
   elseif diff>30010 then
      high ccw_pin
   endif
   pause 100
loop
Possibly a better version, that does not turn the motor off at all until it has finished tracking would be something like this:

Code: 
Do
   /*do range readings*/
   Diff=range-range1+30000
   If  diff<29990 then
      Low ccw_pin   ;stop any CCW movement
      High cw_pin   ;start CW movement
   elseif diff>30010 then
      low cw_pin   ;stop any CW movement
      high ccw_pin   ;start CCW movement
   else
         low cw_pin:low_ccw_pin   ;stop all movement
   endif
loop
In this version, the ‘motor off’ commands are only executed if neither of the other ‘motor on’ commands are executed.

PICAXE cannot express negative numbers. For a byte variable, if you add 1 to 255 you get 0, if you subtract 1 from 0, you get 255. Similarly for a word variable, if you add 1 to 65535 you get 0, if you subtract 1 from 0 you get 65535. It’s called overflow.

The traditional frig for this is to create a virtual zero in the middle of the variables range and do your maths around that. 127 is in the middle for a byte variable, 32767 is in the middle for a word variable.

For accuracy, and allowing equal +ve and –ve excursions from the virtual zero, the 30000 I used above should really be 32767, but 30000 is easier to type and will probably make no difference in this application.

So using +30000 to simulate a virtual zero, after one range has been subtracted from the other, if the result is <30000 then the it’s virtual negative. If the result is >30000 then it’s virtual positive. In this case, negative means the CW sensor has detected a lower range that the CCW sensor requiring the motor to turn the head CW.

The reason I use <29990 and >30010 in the test, rather than <30000 and >30000 is to defeat continual ‘seeking’ behaviour (a common problem in this sort of app) even after the head is pointing at the target. This allows the motor to remain off, even when the range readings differ, but only when they differ by a small amount. In this case + or – 10, but you should adjust this range by experiment.

Note: The sensors should be placed so that their detection zones overlap a little in the middle. So that when it has successfully tracked to the target, BOTH the sensors are reading the distance to the target.

The code as described does not limit the active range to 2m as you would like, but it’s easy to add. Over to you.
 
Last edited:
M

MPep

Senior Member
Bulldog,

What an interesting project.
To use IR, why not use a piece of card between them.
This way, if coming from the centre (head-on) no difference exits and the head is already pointing towards you.
If you enter its 'vision' from the left, the right IR sensor cannot see you, but the left can. Now turn the head left until an equillibrium is reached.

In other words you need to create a blind-spot for each sensor. An optical form of Hysteresis basically.
 
B

bulldog

New Member
Boriz.
Thanks for the explanation, in so far as the code is concerned i am operating at the very limit of my experience and appreciate the help...We've got a holiday planned for the next couple of weeks so i'll speak to you when we get back.
 
B

bulldog

New Member
MPep.
I've had that problem when i built a photovore, so i cut a pen barrel in half slipped them over the phototransistors and it stopped thr photovore from behaving like a pitbull on speed.
 
You must log in or register to reply here.
Top