Servo documentation

[f2cf1g]

Hi. I'm having my first attempt at controlling a servo from an 08M2. I understand the correct approach is to issue an initial servo command to initialise and then perform subsequent positioning with servopos. Manual 2 tells me that servo only works on port B on M2 parts. Manual 1 tells me that the IO pins on an 08M2 are all port C. Does this mean that servo does not work on an 08M2 and, if so, what is the impact of omitting the command. The servopos documentation makes no mention of a restriction to port B so am I correct in deducing that it works on an 08M2? Or do servo/servopos only work on those pins described in Manual 1 as supporting pwm? Thanks in advance for any light you can shed.
Regards
Roy

 

[Goeytex]

The manual is confusing.
Servo is supported on the 08M2. You can use pins C.0, C.1, C2, & C.4. It is NOT restricted to PWM pins.
The confusion arises because the O8M2 does not differentiate between PortC and PortB. In other words,
even though the pins are officially numbered C.0 to C.5. the compiler will also accept B.0 to B.5.

If in doubt as to whether a command is supported you can always use the simulator or syntax checker
built in to the Program Editor. Simply select the Correct Picaxe in Options. Then enter the command
and click on syntax. You do not need an actual chip.

 

[f2cf1g]

Thanks for the explanation Goeytex, I'll have to look for some other explanation for servo jitter.

 

[JimPerry]

http://www.picaxeforum.co.uk/showthread.php?21906-Robot-servo-jitters-in-08m2-and-not-on-08m&highlight=servo+jitter explains jitter

 

[westaust55]

For the 08M2, PortB and PortC have the same meaning / are one and the same.

PICAXE Manual 2 for the SERVOPOS command (P213 in manual v7.9) in teh second paragraph under the information: subheading mentions using the SERVOPOS commandto aviod jitter.

 

[f2cf1g]

Thanks Jim for the link. I had browsed the forum for info on jitter and I do use servo and servopos as recommended. I had overlooked the recommendation from Technical re the length of pause: I was not aware that a pause was required at all. I added one hoping that would be the solution but no change. I've put my DPScope on the servo pulse train and I'm fairly sure the jitter is caused by anomolous pulse lengths being generated, sometimes too short, sometimes too long. I was interested to hear that the 08M and M2 behaved differently. I would try an 08M but the program uses M2 facilities and I'm loath to start hacking it around. Hmmmm.

 

[Goeytex]

Servo wants exclusive use of the timer. Any other commands in the program that use the timer can cause glitches/jitter.

If you post your program maybe we can sort it out.

 

[f2cf1g]

Right, some progress! I have written a couple of short test programs and these show up the problem quite clearly. The first simply cycles the servo between two positions with a dwell after each to allow time for the jitter to manifest itself if present. In fact, there is no jitter, the servo is solid.

#picaxe 08M2
        high C.2
	pause 1000
	b12 = 150
	servo  C.1,b12
	pause 20
main:
	b12 = 150
	servopos C.1,b12
	pause 10000
	b12 = 200
	servopos C.1,b12
	pause 10000
	goto main

The second version is similar to the first, but after each dwell it waits on the press of a button (the application is a free flight model timer so there is quite a lot of button pressing in the full application). During the long pause the servo is solid, as with the first program. However, when it reaches the wait loop the jitter starts. After the button press and subsequent move, the servo is again solid during the other dwell and the cycle repeats. So the wait loop seems to be causing the jitter, which occurs according to some sort of pattern every 2 or 3 seconds.

#picaxe 08M2
	high C.2
	pause 1000
	b12 = 150
	servo  C.1,b12
	pause 20
main:
	b12 = 150
	servopos C.1,b12
	pause 10000
but1:
	if pinC.3 = 0 then goto but1
	b12 = 200
	servopos C.1,b12
	pause 10000
but2:
	if pinC.3 = 0 then goto but2
	pause 1000
	goto main

Is it necessary to break this loop into parts, and if so, what is the best way to do it? If not, any ideas?

Roy

BTW the high C.2 is normally used to switch the servo power on but I have bypassed the FET to eliminate that as a potential cause in the above tests.

 

[boriz]

Do you have a 'scope?

 

[boriz]

Specifically, can you observe two signals with a CRO?. The power to the servo and the signal to the servo. Any lumps or spikes associated with the jitter?

I assume your ground connection is good, your power supply is up to the job, and the Picaxe is appropriately decoupled.

 

[f2cf1g]

Hello Boriz
Yes I have a DPScope and I have been using it extensively. I have been monitoring the servo power and pulse train. The voltage does change when the servo moves and there is a small amount of noise on the power line (can't see any very fast spikes of course). My feeling is that it's not the power, I have already put a 4.7mF capacitor across the PICAXE to cure brown out which was causing the PICAXE to reset, that is no longer a problem. The current problem is identical whether running from 4 x AA NiMh or 70mAh 20C Lipo. I have also tried running the PICAXE off a regulator effectively separating the supplies, no improvement. The test program results suggest to me that having the program stuck in a tight loop is provoking the firmware into something unfortunate.
Roy

 

[hippy]

The test program results suggest to me that having the program stuck in a tight loop is provoking the firmware into something unfortunate.

That would seem to be likely -

WaitForPush:
If pinX.Y = 0 Then WaitForPush

That will be repeatedly reading the portX pins and handling the command itself. When it comes time to handle the servo pulse there's a good chance the PICAXE is accessing the portX or doing something else so it cannot issue the servo pulse exactly when it should.

Add a pause between the label and the IF and that should improve things, reduce the chance of jitter.

 

[f2cf1g]

Hippy, I had already tried this. I added time until the symptoms disappeared in the test program at 20mS (coincidence?). I have put it into the application as well and it seems to have improved things considerably (though the program loop there has a lot more instructions in it so the improvement is unexpected). It occurs to me that, being a timing issue, the occurrence can never be reduced to zero. It seems to affect the pulse width as well as the repetition interval. Is there any other way to diminish these effects?

 

[hippy]

It occurs to me that, being a timing issue, the occurrence can never be reduced to zero ... Is there any other way to diminish these effects?

You could perhaps monitor the servo pulse being generated, ensure the PICAXE is always in a pause when a servo pulse is due to occur.

You could use a second PICAXE to generate the actual servo pulses which takes the position from the latest data sent to it using high-speed background serial receive, or use some other dedicated servo handler which can be updated from the PICAXE.

As servos are usually fairly tolerant to varying frame rates you can use PULSOUT to generate the servo pulses then control the timebase yourself or have the timebase come from an external source.

PULSOUT does seem to be the favoured technique for solid servo control and there are further discussions on the forum and probably other ideas as well.

 

[f2cf1g]

Are pwmout or hpwm alternatives to servo/servopos and are they less prone to jitter? From Manual 2 pwmout looks similar to servopos so presumable has the same characteristics but maybe not so hpwm.

 

[hippy]

Theoretically PWMOUT and/or HPWM could be used to generate a hardware servo control signal but in practice it doesn't work well as the minimum PWM frequency is too high, won't go down to the normal 50Hz / 20ms frame rate without dropping the PICAXE operating speed. Also the pulse width resolution you could achieve is probably less than desirable.