Hello. I was wondering if anyone has any experience driving a digital servo directly from labview . . . no ssc-32 board. I am using a NI PXI chassis with a M-series DAQ card (6229). I am generating the PWM signal needed to drive the servo using the DAQ board’s counter. What I am ultimately trying to do is update the PWM signal every 20ms (what the servo is allegedly looking for) with a different position command generated by a cosine function which is also updated at the same 20ms. The user enters in the freq and amplitude of the cosine function. So basically I want the servo to track the function. It mostly works. A PWM signal is generated that is updated by the cosine function (tracked on an oscilliscope and output to the servo). The problem is that the PWM signal is unreliable. The period of the output sinusoid changes and the motion of the servo is pretty jittery. Any ideas? Anyone with experience messing around with labview and digi servos? I can attach my labview code if anyone can (and wants to ) look at it.
It’s a pretty obscure method of creating servo pulses. Do you have a scope or logic analyzer to look at the pulses. Nothing like knowing what is actually happening in real life. Servo pulses are a major pain to generate, even when the device is designed to do it.
I am using an oscilliscope and can generate a PWM signal . . . its just that the signal is unreliable. I was hoping that someone on here has used labview before to drive servos and that I could pick their brain for ideas. I think I am close but I am definitely missing something! Any ideas?
The R/C servos require a .5 to 2.5 mS pulse width in a “frame” of 20 mS. How are you generating the PWM with a 6229 counter? Servos typically don’t like much faster or slower “updates” then that. To generate R/C PWM signals, we generally cascade interrupts. One interrupt runs at 20 mS, and the second one generates the “duty cycle” (pulse width) of the PWM. This generally requires two counters, one for the frame time, and one that gets re-loaded each frame to time the pulse width. DC servo motors require a simpler 0-100% duty cycle. While you can generate a very short pulse (.5% to 12% or so) with a single counter, you generally can do it with enough precision, namely 2048 (11) bits or so.
Also, why are you calling it the “output sinusoid”? Are you describing the path you expect (xy?) the servo to be able to trace out? The output should be a square wave (PWM) of what looks like very low duty cycle.
Can you use two counters, one “frame” counter to trigger a second “pulse width” counter?
I am creating a 1000 point array that is stepped through every 20ms. The PW is represented by the number of high values in the array . . . for instance if you wanted a PW of 2.5ms, the first 125 values in the array will be high and the rest will be low. The oscilloscope shows this method to work, the problem comes in when I try to alter the PW every loop. The output I am talking about is how the servo horn itself moves . . . the pulses are always square they are just altered in size relative to a cosine function involving the elapsed time. Basically I want the servo to move slower at the peaks of the sinusoid and faster through the zero crossings.
I don't see why I would need two counters if one counter is working fast enough. Then again, I am pretty new to all of this. Allegedly the hardware timer is fast enough but I am certainly having what seems to be timing issues.
It’s fast enough, but if you’ve got 1000 points that describe 20 mS, then only 1/8 (250) of them should actually be used to “drive” the servo! Does that make sense?
The use of two counters allows fine resolution of the single servo’s period (there can be eight such servos in a 20 mS frame, R/C stuff).
I recognize that it seems silly to generate all those zeros and that I could get better resolution if I, lets say, split the 2.5ms pulse up in to 1000 points. But, if I can do that, which I will probably try at some point, what is the downside to simply using this faster timer to indicating when the loop should repeat at 20ms also? What am I missing?
What resolution (division) can you get over the full range of the counter? Divide that by eight, and see what resolution you’re giving the servo. If I recall correctly, the SSC-32, and a lot of PIC implementations of R/C servo controllers (and mine) typically get 256 “steps” over the range of the servo.
Any less then 256 or so divisions, and you’ve really compromised your resolution.
Another point, if you can break up your moves into “little bytes”, as opposed to one big move, your “smoothness” will improve. Another parameter would be acceleration/deceleration.
You do not recall… The SSC-32 divides the range into 2000 steps. 500uS to 2500uS, for a resolution of 1uS. This is roughly 0.09° given a perfect servo. The old MinSSC-II had 254 steps across 180° which yields about 0.72° resolution, but there is no mention in their docs of what exact servo pulse ranges are generated. 8)
Most low end servo controllers use 254 steps, as they reserve 255 as a sync byte. I’m sure you know this, but a byte is 0-255, so you can’t have 256 steps, more like 254.
In my tinkering a standard $10 servo seemed to be limited to ~426 discrete movements in its ~190 deg range of travel. I think the pot in the servo may be an important factor in the servo resolution.
That may be true. I was thinking a typical R/C servo would have an 8-bit A/D converter, and what, 8-bit D/A?
You are quite correct that the pot is a limiting factor. And not particularly linear. Probably it’s worse “feature”. I’ve used '645 servos with an external “mill grade” pot (Tilt/Pan), and the further geared servos performed quite nicely.
They can’t, even the best servos dead band prevents this. That’s why I said “given a perfect servo.” But there is a BIG difference between 256 steps and 2000 steps. The difference is quite noticeable in action, especially with higher end servos.
Typical R/C servos don’t have A/D or D/A converters! They have an analog comparator system that actually works very well. The pot is not the limiting factor in analog servos resolution capability. It’s the mechanics mainly and secondly the output driver stage that limits analog servo resolution.
Analog servos are generally low end. That means the gears are not as precise, which equates to slop. The output stage is not updated as fast as digital and the weaker bipolar transistors can’t hold position as well as FET’s. For these reasons they build in a larger dead band in the electronics to prevent hunting and oscillations. This dead band is the true limiting factor, but it’s designed-in to compensate for other inefficiencies in the system.
Again, apologies for misquoting the SSC-32’s capabilities!
(R/C servos)
Pure analog! Analog comparators! Hard to imagine these R/C servos work at all.
I thought I had remembered more “servo system” in them. I was probably thinking more of small DC servo implementations I have seen.
The Open Servo project looks like it might actually do an A/D conversion on the pot data; but of course the drive to the FET H-bridge is just PWM. but that’s an expensive “fix” (project) for a low end servo.
I picked up a pair of AX12+ servos to experiment with, but I can’t even talk to them without a board to interface to their proprietary serial bus.
But then compared to a true DC servo motor control system (not really on the same level as an R/C servo) such as JrKerr:
Plus the servo motor, I guess we’re getting quite a bit for the money in R/C hobby servos.
The slop in the gear train and poor motor drive is a major limitation in the R/C servos, as you’ve pointed out. And the fact that the feedback device (pot) is on the output of the gear train instead of the motor shaft can’t help. But then you’d have the excessive backlash to contend with. I’m sure they’re doing the (near) best they can with what low-cost parts they build them with. don’t get me started on the little brushed DC motor in them!
Hard to put 18 DC servo systems into a hexapod ($$) ;>)
But I might just put a pair of the JrKerr servo boards into a MircoMouse. (now that I have them!).
Back a little on topic, I did notice that JrKerr did have a Lab-View driver for their servo boards.
Again, apologies for misquoting the SSC-32’s abilities.
Analog comparators! It’s amazing these R/C servos work at all! I was remembering more in them then that. the Open Servo project is a step up from that. At least they apparently read the pot with an A/D. But they just use PWM driven FET’s for the output. Only servo systems with analog amps probably use the D/A’s I was thinking of.
These cheap R/C servos suffer from a myriad of limitations, the gear train being a major contributor to their sloppiness, as you’ve pointed out. And of course having a pot as a feedback device on the output instead of on the motor it’s self couldn’t help. But then they’d have to deal with all the backlash.
I did just buy a pair of AX-12+ digital servos, but they need a serial driver board for their propitiatory interface bus.
Would perform much more accurately for the plotting application from Lab-View. And JrKerr has the drivers for Lab-View! (I just received three PIC-SERVO boards, which I’m thinking about putting into my current MicroMouse project).
Of course, it would be a little expensive to build a hexapod from 18 DC-Servo systems with the JrKerr boards! ;>)
