"servo" vs "pulsout"

goom

Senior Member
In the process of designing a device to increase the travel of a hobby servo, I discovered that the servo and pulsout commands do not seem to give the same position information to the servo.
I would have expected the following examples to give the same result:

for b2=0 to 150
pulsout 1,200
pause 19
next b2

and

servo 1,200

The difference is about 10° of rotation. I am using a -08M.
It is important in my code since I use both commands. During setup and normal operation I read the input pulse from the receiver, scale it, and then output to the servo. In the event of a loss of radio signal, I send the servo to a predefined position (as dictated by the user during setup), but can no longer use pulsout since there is no syncronising pulse. Instead I use servo (and subsequent servopos) to move to the failsafe position.
I can't do much in code to try and scale one or the other to make them match since I am down to only 3 bytes of unused program memory.

Any ideas, suggestions or explanations?
 

BeanieBots

Moderator
Which firmware verison of the 08M.
I've not noticed this effect but I've not done much servo work with 08Ms and mine are quite old now.

I don't understand why you need to be using pulsout when servopos is available. The only reason for using pulsout instead of "servo" was for rapid position updates which caused problems when the servo command was re-issued. The recent introduction of servopos command gets around this problem.
Maybe I've missed something in what you are doing?
 

Technical

Technical Support
Staff member
Due to interrupt timing differences there may be a bit of difference between the two commands on the M series chips - most people use just one method or the other and so don't notice!

The only real workaround here is to scale a bit - for instance subtract a fixed value (e.g. 5) from the servopos value.
 

Andrew Cowan

Senior Member
I've made failsafes before, just using the servopos command. The below code is showing the structure - it doesn't include pin numbers etc.

Code:
init:
servo 150
main:
pulsin w1
if w1=0 then fail
servopos w1
goto main

fail:
servopos 150
pulsin w1
if w1>0 then main
got fail
A
 

westaust55

Moderator
got fail ==> goto fail

I have not used SERVO's to date but about to play:)

Would the failsafe not be better to look for out of range such as < 75 and/or > 225 ? :confused:
 

BeanieBots

Moderator
Would the failsafe not be better to look for out of range such as < 75 and/or > 225 ? :confused:
Yes, it would.

Further more, I often put in a count within the failsafe routine to check for X number of 'good' pulses before returning to 'normal' mode.
It is actually very rare to simply have 'good' pulses or 'no' pulses. Problems are more often caused by local interferance (peolple driving tanks on air-band frequencies) or out-of-range range issues which results in erratic pulses being received.
 

Wrenow

Senior Member
I don't understand why you need to be using pulsout when servopos is available. The only reason for using pulsout instead of "servo" was for rapid position updates which caused problems when the servo command was re-issued. The recent introduction of servopos command gets around this problem.
Maybe I've missed something in what you are doing?
BB - when you are reading a hobby R/C RX signal, you can rely on the frame timing (the about 20ms pause between pulses) from the RX, when you do the pulsin, to handle the frame. You have no need for the background frame timing. So, using a pulsin to read the inputs you want to use, doing whatever maths or massaging you need, and then doing a pulsout is often simpler and avoids some timing conflicts.

You do want to remember to read multiple pulsins in the sequence output by the RX, or you will be skipping frames. Also, some of the newer RXs (like the 2.4gHz Spektrum DSM2 series) output all servo pulses simultaneously, making this a bit more of an issue if you are wanting to read multiple inputs simultaneously. :eek:

Interestingly some of these, like the Spektrum DSM2, are sending a serial signal over the RF link instead of a simple pulse train, and are then decoding the serial data with a uController build in to the RX. Hnowing this, and getting the protocol for the data, allows hackers to work with the raw serial data stream using a third party receiver, like a Zigbee or Xbee. I believe there are some threads on how to do this on either RCGroups or RCUniverse.

Cheers,

Wreno
 

BeanieBots

Moderator
Then use a simple pause 20 (or similar) to keep a consistent frame rate and carry on using pulsout within the failsafe routine.

Wrenow, thanks for the RCgroups tips on 2.4Ghz raw data protocol.
Not been there for a while, must have dig around again.
 

goom

Senior Member
Many thanks for all of the replies.
Technical's response certainly explains my observations. Since I only have 3 bytes of code space left, I may not be able to scale to get pulsout and servo commands to give the same servo position.
I probably could re-code to use only sero/servopos, but it is so much simpler to syncronise and give immediate updated outputs using pulsout (as Wreno pointed out). Using pulsout in the failsafe routine would not work since a total loss of signal means waiting 0,65536 seconds for the timeout, during which time there would be nothing going to the servo.
I do use a range check to trigger the failsafe (>75 and <225). I initially did check for several invalid pulses, but abandoned this due to limited code space and the difficulty of sending updates to the servo during the validation check.
In the normal course of events, I do not read multiple pulses before outputting the pulse. This gives the fastest response, albeit at the possible expense of the odd glitch. Since it will be used to sheet a sail, this is not really an issue.
I have recieved a lot of interest in this device from our local model boat club (I have made 12 so far). It is a great way to extend the range of a regular servo to make it better suited as a sail winch. The failsafe is also of interest, particularly after one sailboat sailed off in the great St. Lawrence river after losing radio contact, never to be seen again.
I can post code, schematic and PCB layout if of interest to anyone.
Thanks again for all the help.
p.s. Wired up my (Picaxe based) rudder/3-motor mixer and 3 (Picaxe based) speed controllers installed in a 6 ft long model icebreaker. All works as designed.
 

MPep

Senior Member
Hiya Goom,

Would be interested to see your project in the Finished Projects area of the forum. Perhaps a photo of the yacht too?

The 3-motor mixer sounds interesting too.
 

goom

Senior Member
Details now posted in Finished Projects - Miscellaneous.
Immediate application is a micro-servo sail winch for a "Footy" (a 1ft x 6" x 1ft class sailboat).
Will try to post mixer details in finished projects in the near future.
 

Attachments

Wrenow

Senior Member
Many thanks for all of the replies.
Technical's response certainly explains my observations. Since I only have 3 bytes of code space left, I may not be able to scale to get pulsout and servo commands to give the same servo position.
I probably could re-code to use only sero/servopos, but it is so much simpler to syncronise and give immediate updated outputs using pulsout (as Wreno pointed out). Using pulsout in the failsafe routine would not work since a total loss of signal means waiting 0,65536 seconds for the timeout, during which time there would be nothing going to the servo.
I do use a range check to trigger the failsafe (>75 and <225). I initially did check for several invalid pulses, but abandoned this due to limited code space and the difficulty of sending updates to the servo during the validation check.
In the normal course of events, I do not read multiple pulses before outputting the pulse. This gives the fastest response, albeit at the possible expense of the odd glitch. Since it will be used to sheet a sail, this is not really an issue.
I have recieved a lot of interest in this device from our local model boat club (I have made 12 so far). It is a great way to extend the range of a regular servo to make it better suited as a sail winch. The failsafe is also of interest, particularly after one sailboat sailed off in the great St. Lawrence river after losing radio contact, never to be seen again.
I can post code, schematic and PCB layout if of interest to anyone.
Thanks again for all the help.
p.s. Wired up my (Picaxe based) rudder/3-motor mixer and 3 (Picaxe based) speed controllers installed in a 6 ft long model icebreaker. All works as designed.
Would love to see it all - will check it out in the completed projects section.

By the way, if you are wanting to "stretch" the servo range, there is also the http://www.servocity.com/html/180o_servo_stretcher.html (and there are some other versions out there, too). Me, I just use a 3.5 rotation sail winch servo for sail winch type functions (the Futaba is $$$, but the Hitec is not too bad (http://servocity.com/html/hs-785hb_3_5_rotations.html).

As for the failsafes, some RXs have failsafe programming (the Spektrum robotics series in 2.4gHz, for example, or the Sombra SL-8 in currently in 72/75mHz, European frequenies announced but not yet available http://www.sombralabs.com/products_sl8.php).

Cheers,

Wreno
 

goom

Senior Member
Wreno,
Yes, I am aware of the commercial servo strecher. No failsafe, and considerably more expensice than my version (assuming I work for 10c/hour).
The main objective of the Footy related efforts is to help encourage new people to the sport of RC sailing. Cheap and simple are important atributes, so the ability to use cheap standard servos as sail winches is helpful. The servo strether could also be used with a 3.5 turn winch in order to increase or decrease the end points. Some winches are programmable, but are 100's of $. "Fancy" radios can also be programmed to adjust end points to some degree.
I have a Spektrum DX6, and use BR6000 receivers which can be programmed for failsafe positions on all channels. The "standard" AR6000 recievers can only be programmed with failsafe on the "throttle". We still have many members using simple 75MHz equipment, so a failsafe option is definitely of use. Just ask the guy who waved goodbye to his Mini12 as it dissapeared heading for the Gulf of St. Lawrence.
Kevin
 
Top