PSC command rate

ndo79

Hello,

I am using a C-program in Linux to control a PSC-usb board (servo controller).
I have a function that commands 7 channels (0-6) every 10 ms and I’m noticing jerking.
Can anyone tell me how fast I can send commands to the board or how fast the board can respond?

Here’s some pseudo code of my function that I call every 10 ms:
If I comment out all but 1 channel, the function works well. How can I control multiple channels at once smoothly?

controlServos() {

generate commands for ch 0;
write commands;

generate commands for ch 1;
write commands;

…

generate commands for ch 6;
write commands;

return;
}

Regards,

-N

Chris Savage

Hello,

·· One thing I noticed is that you're trying to update every 10 ms but the servos are refreshed every 20 ms.· This may or may not be causing the jerkiness you are seeing.· Try putting a 20 ms pause between refreshes and see if that helps.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

ndo79

that's not possible, unfortunately. Are you saying that the servos update themselves every 20 ms, meaning they look at the commands sent to them every 20 ms? Or is the PWM signal from the PSC to ther servos updated every 20ms? If the servos are slow, are there any types of servos that are faster? I need servos that can respond to commands at more than 100Hz. Whether they can go to those positions that quickly is not important. Thanks. -N

allanlane5

The servo control signal is a 0.5 to 2.5 mSec pulse every 20 mSec to 50 mSec. The servo has on-device electronics which compare this input signal to a pulse generated by the shaft position, and then moves the shaft position to make the difference zero.

So that's the control signal. Now, how "fast" the servo "responds", and what the difference is between that and how fast the servo actually moves, is unclear from your posting.

So, I have to ask -- what does it mean to you that you need "servos that can respond to commands at more than 100 hz"? What form do you want that "response" to take?

Chris Savage

The PSC should be limiting the pulse frequency to 20 ms intervals...If you try to overdrive a servo, many will do strange things.· But your brought up another interesting point.· If you try to change the position too quickly repeatedly on the servo before it reaches its destination it may start acting erratically.· I have seen this behavior driving a servo directly (No PSC) when trying to reposition the servo faster than it could get to the new destination.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

ndo79

Allan,

Sorry, that was pretty vague. What I mean by "response" is just that the servos can accept commands at that rate; that it can see commands coming every 10 ms. Every 10 ms, I want to send a new position for the servos to go to. Whether the servos can make it to the new position before the next command comes over is irrelevant, it would simply get interrupted and it will head to the new position.

From what you're saying, the servo looks at the pwm signal every 20ms to 50ms. It that's the case, the fastes I can send new position commands is limited by the update rate. Are there any servos that updates faster?

Chris,

my function from the first post runs

ndo79

sorry, hit wrong button,

Chris,

If my function from the first post runs every 10ms, is that too fast for the PSC to operate on? Every 10 ms the function updates channels 0-6 one after another. I suspect the writes to the serial port are very quick (less than 1 ms between writes to each channel). How does that affect the PSC?

-N

allanlane5

Hmm. My understanding of the generic radio-controlled servo (Futaba 148 being one) is that they all expect that control signal, and all radio-control recievers put out that control signal.

If you don't really expect the servo to 'snap' to a position in 10 mSec anyway, then why do they need to 'listen' every 10 mSec? You can do this level of 'decoupling' the new positions, versus how
often you actually send a command to the PSC·in C, actually.

Pseudocode:
int i;
char CmdStr[noparse][[/noparse]5][noparse][[/noparse]8];· // Or however long the command strings are...

UpdateTime = gettime() + 20 mSec;
while(TRUE)
· {
··· // 1.· Update the new·desired servo position as often as desired.
··· for(i=0; i<5;i++)
··· {
····· GenCommand(i, Cmdstr[noparse][[/noparse]i]);
··· }

··· // 2.· Send the new position when the PSC is ready for it.
··· CurTime = gettime();
··· if (CurTime > UpdateTime)
··· {
······for (i=0; i<5; i++)
····· {
······· SendCommand(i, CmdStr[noparse][[/noparse]i]);
····· }
····· UpdateTime = gettime() + 20 mSec;
··· }
· }

This approach allows you to update the 'position command'
as often as you want to, but only send it when the PSC is
ready to implement it.· Since the Servo's can't move that fast
anyway, they would be "ignoring" lots of messages if you sent
them any faster.

In any event, you're using the PSC board to actually send
commands to the Servo's.· So you're computer is not "in the
business" of sending the refresh every 20 mSec.· You just need
to update the PSC board with new servo positions -- but not so
fast you confuse the PSC.


Post Edited (allanlane5) : 6/26/2006 8:50:36 PM GMT

ndo79

Allan,

You are correct. I would be better off commanding at a slower rate, but i'm trying to stay true to the system. This is all for a control system for a UAV. The operating frequency will be 50-100Hz. Every cycle, states of aircraft is determined and a control algorithm calculates what the position of the servos should be next to keep it stable. If I slow down the commands I will be cheating the control system (If that makes any sense at all). It's alot to consider is such a brief post. Bottom line is, I must be able to send out those commands and the servos must try to meet them.

Chris Savage

ndo79 said...(trimmed)
If my function from the first post runs every 10ms, is that too fast for the PSC to operate on? Every 10 ms the function updates channels 0-6 one after another. I suspect the writes to the serial port are very quick (less than 1 ms between writes to each channel). How does that affect the PSC?

I'm not suggesting it's too fast for the PSC, I'm suggesting it's too fast for the servos.· I haven't tested what happens if you change the servo pulsewidth faster than you should.· Perhaps it will affect it.· I will have to test this for myself.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

ndo79

strangely, if I comment the funcion so that it only send to 1 channel, then everything seems smooth. That is, it seems that I can update at least 1 channel every 10ms perfectly well. It's only when I try to update more than one channel that it gives me stuttering problems.

-N

MachineMonkey

N,
back to the original post for a sec... you are noticing 'jerking' on how many of your controlled channels? I ask because of your last post. Is it possible one of the other channel's positional data is also being sent to the first channel? Giving a single servo wildly different destinations (which disparate channels are likely to have) more or less simultaneously might give erratic movement. Just for fun, maybe you could give all 7 channels the same 'marching orders' and see if the problem clears up.

a thought,
- K

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Failure is not the only punishment for laziness; there is also the success of others.

- Jules Renard

ndo79

All of them are jerky... I double checked my code and it's being sent to the right channel. I think I might be writting commands too fast for the PSC to read, because i'm noticing a lag sometime. BTW, I have been sending the same command to all channels, that's how I realized it was jerking because they should be moving in sync but they're not.
-N

allanlane5

Hmm. Is it a 'show-stopper' for you to update the UAV 20 to 50 times a second? That 100 times a second is more than the servo's can do. So, if you want to use a servo-based solution, you may have to 'slow-down' your updates slightly.

In the same topic, updating a mechanical element faster than it can actually move may make you feel better, but physically and mechanically it doesn't do anything. Half of the updates are lost in the machinery.

And if you're doing this from a PC, you should probably be aware that PC's aren't really built for real-time operations in the first place. Windows, especially, has several kinds of interrupts that can distort execution times for your program.· Linux on a PC also is not a 'hard' real-time system, but is probably more predictable than Windows.

All of which is to try to point out that your specification may be slightly unrealistic. If it IS realistic, and you really do need 100 times per second updates, then a servo-based solution probably won't work. But from what you've said so far, it does sound like a servo-based solution can work, if you relax your specification a little.

It's also possible that everything is currently working perfectly, but that your update algorithm is 'ping-pong'ing the servo's -- thus the jerkyness.· You do have some hysteresis in your control loop, right?

Post Edited (allanlane5) : 6/27/2006 5:39:31 PM GMT

ndo79

I'm coming to realize that a 100Hz is too much for the servos to handle.

I understand that most actuators don't have that kind of bandwidth. Commanding, say, 5 deg, swing at 100 Hz will probably result in nothing moving at all, but the amout of displacement between commands at that rate will be very small (less than 0.5 degree between command steps I would imagine).

In addition, whether commanded displacement gets attenuated is not an issue; the control system is designed to addapt to servo rate saturation and limits. But if i run the control loop is at 100 Hz and only command the actuators at 10 Hz, it's really a waist of procesisng power.

I'm not sure what you mean by hysteresis in the control loop...

-N

allanlane5

Ah. Hysteresis in a real-time control loop:

It's possible to command a servo to move, then have the servo move, then have the 'feedback element' (a position encoder) move a little, and the software then commands the servo to move back, which moves back the 'feedback element', which then triggers the software to command the servo to move back the other way...

If your software tries to control the servo's too "tightly", then the result is the servo sits there, quivering between two limits, being commanded up, then down, then up, then down.

The hysteresis mentioned allows the software to 'ignore' a certain small amount of movement in the 'feedback element'. Thus, having commanded a servo to a particular position, the software can be a little 'calm' about exactly how close to the commanded position the servo reaches and holds.

So, if you command the servo to move left to a 90 degree position, and it reaches 90.5 degrees, your software can either allow a +- 1 degree 'slop', or it can immediately command the servo to move right to 90 degrees. If it now reaches 89.5 degrees, your software can allow the 'slop' again, or can immediately command the servo to move back left.

Now, 1 degree is probably WAY too lose a 'hysteresis' value to use. But if you make hysterisis too tight, your software spends its time making the servo's 'quiver'. So it's up to you what value of hysteresis to use -- 0.01 degree? 0.1 degree?

allanlane5

Note controlling lots of servo's does raise the possibility of browning out your power supply. I use a rule-of-thumb that a servo takes about 100 mA to move. 8 servo's is around 800 mA then. You might measure what the current draw is on your power supply.