servo noise problems

waldy

New Member
Hi

I've published a camera panorama robot rig at:
http://www.instructables.com/id/Camera-Panorama-robot-head-panograph/

This has two servo's controlled by the AXE024 servo board. I have some timing issues that I need to resolve.

The servo board literature states that servo noise could cause erratic behaviour & I'm seeing that.

In my code I'm moving the camera to 30 discrete locations, 5 in the x axis & 4 in the y axes. two servo motors position the camera. In my code, I was hoping to put a pause in before giving the instruction to fire the camera shutter (pause to allow the camera to steady after moving). So, if I place the pause before firing the shutter, the circuit behaves erratically. The first shutter does not fire, then subsequently the shutter fires immediatley after a move. It seems to me that the servo's operating affect the internal clocking of he picaxe?

I understand the AXE024 has certain ways to reduce noise: diode protecting the picaxe from supply line with servo's. Two tant caps to reduce the effect of servo loading. decoupling caps (100nF) on supply line to picaxe & across supply pins of servo's. I have added some ferrite coils to reduce HF noise also.

Any help or thoughts appreciated. I've enclosed my code below:


symbol servo_delay = 60 'recommended delay between servo movements
symbol top = 160 'max y position
symbol bottom =220 'min y position
symbol left = 180 'min x position
symbol right = 100 'max x position
symbol vstep = 20 'vertical increments
symbol hstep = 20 'horizontal increments
symbol pic_delay = 100
symbol camera_steady_delay = 4000 'delay to steady camera after movement

main:
GOSUB Init
for b2 = top to bottom step vstep
for b1 = right to left step hstep
servo 1,b1
pause servo_delay
GOSUB take_picture
pause camera_steady_delay
next b1
servo 2,b2
pause servo_delay
next b2
end

take_picture:
high 4
pause 30
low 4
return

Init:
servo 2,top
low 4
return
 

BeanieBots

Moderator
The code as you currently have it waits for 60mS after the servo command, then takes a picture, then waits for 4 seconds before moving off again.

If you swap over the two lines (which I think is what you wanted)
GOSUB take_picture
pause camera_steady_delay

what actually (in detail) goes wrong?
It sounds like you have all the obvious things to suppress any electrical noise and there does not appear to be any eveidence of the PICAXE resetting so I'm not too sure what your actual problem is. More detail please. Can you describe "erratic" more precisely.
The code you have posted WILL behave the way you explain.
Please post the code which you WANT but does not work as expected.
 
Last edited:

waldy

New Member
Hi,

With the code I have supplied, the camera fires pretty much immediately after the camera has moved, then a pause before moving and firing again. At lease the camera fires after each move.

If, as I would like, I swap the two lines round to
pause camera_steady_delay
GOSUB take_picture

the camera doesn't fire in the first position, camera moves, camera fires less than a second after the move.

By erratic, I think I mean doesn't work as expected from the code

I'd expect:

Initialise
loop
pause
camera fire
move camera

That 4 second pause seems to happen
 

BeanieBots

Moderator
To me, "erratic" means 'differently every time.
Does your code (the way you want it) do the same thing everytime?
Does it miss the first trigger EVERY time?
Is the 4 second delay short EVERY time?
Is it short by the same amount everytime or does it appear random?
 

waldy

New Member
To me, "erratic" means 'differently every time.
Sorry, been a long day. Better to say that it works unexpectedly, but the same every time

Does your code (the way you want it) do the same thing everytime? yes
Does it miss the first trigger EVERY time? yes
Is the 4 second delay short EVERY time? yes
Is it short by the same amount everytime or does it appear random? same every time < 1 second

In fact I've measured the total delay between camera movements, ignoring camera shutter & it's about 4 seconds.

In the last position two shots are fired
 

BeanieBots

Moderator
Your answers make me think that nothing is wrong and you do not suffer noise issues.
I think it is your code and/or hardware logic.
Might be a good idea to post your circuit.

For the missed first picture, this could be your logic.
What happens if you change the take_picture to:-

take_picture:
low 4
pause 30
high 4
return (EDIT: also change init: to HIGH 4)

As for the short pause, I've not experienced any problems mixing pauses with servo commands so I don't think there is an issue and if it was noise related, I would expect ERRATIC behaviour. Your circuit is behaving very consistantly.
This VERY STRONGLY suggets code or hardware DESIGN error.

It might even still boil down to inverted logic which the above test (or your circuit) will disclose. However, don't forget that the servo takes time to travel. The command does not wait until it's finished moving. It tells the servo where to go and then processes the next command while the servo moves.
 
Last edited:

boriz

Senior Member
It takes time for the servo to move from A to B. Longer than 60mS! The SERVO command is NOT a blocking command. That is, there is no pause or delay in the program when the command is issued. And once the command is issued it will continue moving, even during a WAIT or PAUSE, until it reaches its destination.

You want something like this:

Code:
&#8216;PSEUDO CODE
do
   Issue one servo command to start the movement
   Wait sufficient time for the servo to reach its destination position and stop (and settle)
   Take photo
Loop

I would experiment with the &#8216;waiting for servo to arrive and settle&#8217; delay to find the optimum, but start at around 800mS and reduce it bit by bit until you start to see camera shake on the pictures*, then increase it back up a little (say +200mS to give yourself a small margin).

(*Because the shutter opens before the servo has settled)

There may also be a camera lag as it focuses, calculates exposure etc, which can also be accounted for in the same &#8216;wait for servo&#8217; delay.
 
Last edited:

boriz

Senior Member
Oh yes. One more thing....

I have found by experimentation that servos can get a little jittery/shaky/twitchy because of noise on the signal line (Picaxe SERVO pin). I have also found that setting that output to LOW can stop it. Experiment :)
 

waldy

New Member
Thanks both, I hadn't considered the servo move time whilst the program continuing during movement. Also I'll try inverting the take_picture pulse too.

Thanks also for the servo 'twitching' comment. I had noticed one of the servo's doing that occasionally. I'll try your suggestion.


I don't have a circuit drawn yet. Broadly, its a picaxe servo controller board with two of the servo's outputs connected (x and y axes movement servo's) The third pcb servo output I've wired using a mini usb cable which is plugged into my Canon G9 (+'ve to signal pin , black to ground) Canon G9 is loaded with CHDK alternative firmware (SDM variant).I'll post a diagram when I get access to VISIO.

ps I can't try these out till Thursday, but some good things to try then. I'm also glad to hear BeanieBots has had success with servo's & pauses, encourages me :)
 
Last edited:

boriz

Senior Member
Apologies. I made a mistake (Senior moment). You need to set the pin HIGH to prevent servo-twitch, not LOW.
 

waldy

New Member
Good news to report. Adding delays in for servo movement & enough time for the camera to be ready to take the next shot has cured all ill's. Thanks all.:D

Still got a little issue with one of the servo's twitching. I tried setting this servo to High whilst the other was moving, however, the servo tension is lost & gravity moves the camera. Any other way of holding a servo's position without it twitching?

regards

Waldy
 

boriz

Senior Member
If the servo is having to ‘work’ to hold the camera still, then you will rarely get a clean picture. A servo pushes in pulses. Best solution is to redesign the mount so that the cameras centre of gravity is directly over the servo output shaft, or (easier) use a counter weight.
 

waldy

New Member
Hi, the camera moves in two axes. In the x or horizontal axes, the camera is right over the center of gravity & this servo doesn't twitch (as far as I can tell)
The other one is perpendicular and the one I have problem with.

Counterweights would be tricky. The weight required would vary with the inclination of the camera

regards

Waldy
 

BeanieBots

Moderator
There are servos and there are servos.
You get what you pay for.
Two servo which look very similar may vary in price from around £5 to £50.
The 'cheap' ones do tend to 'twitch' when a force is applied.

You can either reduce the load as already described or invest in a better quality servo. If you have a local RC hobby store, have a chat with them and they can advise on better alternatives for your application.

If your servo moves back when the pulses are removed you are probably over-loading it anyway, especially if it is a cheap low torque type.

My advice would be to do both.
Reduce the loading AND get a better servo.

A servo which is allowed to chatter for any lenght of time will rapidly wear out both it's gears and it's position pot resulting in an ever increasing magnitude of 'chatter' ultimately resulting in complete loss of control.
 

waldy

New Member
Thanks for the advice, perhaps use a lighter camera! Seems to work quite well apart from occasional twitching of y servo
 

BeanieBots

Moderator
If you can't add weights to reduce the required torque, maybe some well positioned springs would do it?
Sounds like you are only just 'over' so only a little 'help' from a spring might cure the issue.
 

boriz

Senior Member
“...Counterweights would be tricky. The weight required would vary with the inclination of the camera...”

Can’t quite picture this. Could you post a photograph of your setup?
 

mikie_121

Member
Hey. when i used servos i didn't use the 'servo' command because it was unreliable with more than 1 servo (I tried using an 18X and a 40X1). I watched the pulses on a Digital oscilloscope and they were not regularly spaced.
So in the end i used 'pulsout' commands with carefully placed 'pauses' and it all worked perfectly. The more often you send a pulse the higher the servo torque will be and that may fix your shudder. Hobby servos will handle a wide range of timing variations with 20ms being the 'standard' period. Mine worked well with a 10ms period.
 

BeanieBots

Moderator
Using a different frame rate with pulsout instead of servo (as suggested by mikie_121) is worth a try. I used it to great effect to give more torque on the center leg of my Hexapod. However, be aware that not ALL servos will let you do that. The 28X2 PICAXE includes a feature for alternate frame rates whilst still using the background servo command.
 
Top