More Servo Woes

[aratti]

Tray this it should help.

positive:
	While B0 <> XPRESET
	B0=B0+1
        PULSOUT SERVOY, B0
	PAUSE 20
	gosub servomove
	wend

goto main



negative:
	While B0<>xpreset
	B0=B0-1
        PULSOUT SERVOY, B0
	PAUSE 20
	gosub servomove
	wend

goto main

Al.

[chrisshortys]

Nope this results in the servo panning uncontrolled trying to pass its limits. I havnt ever used a while loop before but assumed the piece of code you gave me should of fitted in where my current for loops where.

If so i shall have a play tommorow and see what i can come up with

[Archangel]

Hi Chris,
I have only a little experience with servos, and do not have my computer at hand, but the best I remember, if I sent a number to my servo it executed fully before accepting a new value, so I am thinking if you send a count to the servo something like 1500, 1510, 1520 . . . to cause movement you can snuggle an interrupt between the numbers.
EDIT: after reading your code, looks like pretty much what you are doing. I'm empty.

Now the problem I am having is the FOR loop doesnt seem to be interuptable. So the servo will only respond to a new input once it has reached its current destination. I want to find a way to have the servo change direction before it reaches its end destination.

I see no interrupt in your code, Why would you be able to stop it? I never have been able to hijack the count variable in a for next loop, you might try using an interrupt routine and clearing the variable in there, I do not know if it will work though.

The second issue i have is the programe seems to freeze at times. The LCD does not update and the programe does not recognise any change in input for a while before suddenly snapping back into life.

Could be latency, could be Breadboard issues where stray capacitance stops the oscillator, could be power supply causing PIC brownout reset, I see no config statement so I assume you are using default config, . . . could be GOTO MAIN at the end of servomove when you used gosub to get there, causing a stack overflow, and eventual reset. . . . On closer inspection looks like you have a return and goto main in there . . . I don't know how that would affect operation if at all since theoretically the code should never go past the return, but who knows? Computers (and PICs) are stupid, but not sloppy, they only do what you tell them to do, whether intentionally or not.
Keep us posted, I would like to see your Final Cut, looks like it would make a cool VR control for a camera in an RC heli.

[Acetronics2]

Hi, Chris

A servomotor has it's own signal limitations ...

from 800 to 2200 µs pulse ( STD ) ... so unpredictable behaviour can occur outside those limits ...

ADCIN 0, B2				' Reads in the PORT A.0 ADC AND STORES THE VALUE IN B2
ADCIN 1, B3				' READS IN THE PORT a.1 ADC AND STORES THE VALUE IN B3

XPRESET	=	B2 + 50

your accelerometer is an analog one, Ok ... but ADCIN can give a result between 0 and 256 ...

so, the servo signal range is not guaranteed to be in the " valid" range.

Now , you read Twice the accelerometer in one cycle ... not really a problem, but it's not compulsory here.

BTW ... Which Pic and Accelerometer do you use ???

Alain

[chrisshortys]

Thanks for all the replies i shall try and go through them now

your accelerometer is an analog one, Ok ... but ADCIN can give a result between 0 and 256 ...

so, the servo signal range is not guaranteed to be in the " valid" range.

BTW ... Which Pic and Accelerometer do you use ???

Alain

Firstly i understand that the ACDIN can give the range from 0-256 how ever the accelerometer is not capable of giving a value of 0-5v, I can't remember the exact voltages as theyre at work but the values i receive on the ACDIN when moving from one limit to the other are 45-128. This is the reason i add a value to the number to try and keep the server centeral(yes i know its not the correct value yet :P ).

The Pic I am using is a 16f876A
and the accelerometer is a prototyping board which i brought from sure electronics http://cgi.ebay.co.uk/3-Axis-low-g-A...1%7C240%3A1318

Hi Chris,
I have only a little experience with servos, and do not have my computer at hand, but the best I remember, if I sent a number to my servo it executed fully before accepting a new value, so I am thinking if you send a count to the servo something like 1500, 1510, 1520 . . . to cause movement you can snuggle an interrupt between the numbers.
EDIT: after reading your code, looks like pretty much what you are doing. I'm empty.

I see no interrupt in your code, Why would you be able to stop it? I never have been able to hijack the count variable in a for next loop, you might try using an interrupt routine and clearing the variable in there, I do not know if it will work though.


Could be latency, could be Breadboard issues where stray capacitance stops the oscillator, could be power supply causing PIC brownout reset, I see no config statement so I assume you are using default config, . . . could be GOTO MAIN at the end of servomove when you used gosub to get there, causing a stack overflow, and eventual reset. . . . On closer inspection looks like you have a return and goto main in there . . . I don't know how that would affect operation if at all since theoretically the code should never go past the return, but who knows? Computers (and PICs) are stupid, but not sloppy, they only do what you tell them to do, whether intentionally or not.
Keep us posted, I would like to see your Final Cut, looks like it would make a cool VR control for a camera in an RC heli.

Yer i think that is the problem the FOR loop is not very interuptable. Thats somthing im going to change once i get time to play with it again.
Shouldnt be a problem with latency as i only ever use veroboard though i havnt placed any capacitors across the crystal so i shall do that asap to see if that helps.
Power supply wise i have tried the circuit on several different powersupplies both at work and at home, the only issue i had there was i had the current limiter at around 100 mA and the servo seems to draw a considerable amount to trip that on its first start up! But hat has now been rectified with a 470 uF across the power rails next to the servo and upping the current limiter.

I shall lso try removing the goto main which was left in from a older attempt but i cant see that command even being looked at but its worth a try!

Orriginally i had planned to make a Pan-Tilt head for a camera but im now looking at making this into a robotic arm kind of setup with possibly strain gauges to detect a hand closing..... i dont know that somthing for later

[Acetronics2]

Hi, Chris

Ok for MMA7260 ... I've got a bunch here , from Elektor magazine. ...


let's then suppose servo pulse kept into the "valid range"

Now, nothing "strange" in the program ... may be you left MMA sensitivy range selecting aside, for the moment.

I'd just recommend you to add :

LOW Servoxyz

just before

PULSOUT Servoxyz

Just to be sure the pulse will be positive. ( not only a view of mind !!! )



Next step to check ... the supply.

Of course, for tests you better use a separate battery for servo powering.

Here you could begin to find success ...

Alain

PS: http://itp.nyu.edu/physcomp/sensors/Reports/MMA7260Q

[chrisshortys]

Well i carried on with some work before checking back to this forum and i have a much more effective code now although i shall try some of the comments you made last Ace

Ive gone back to using a FOR loop but i have put in a maths calculation so that the servo was nt moving the whole way to the next destination but a 4th of the way before checking the data again. So now i have a fairly responsive system for one servo which seems to keep track pritty well with no more hang ups!

The next thing I intend to address is the speed of the panning of the servo. I intend to have the servo move more quickly when there is a larger change in the accelerometer the faster the servo moves.

If anyone would like to see the code just ask but beware its quite messy atm