Parallax Servo Controller (PSC) Unstable at 38k4

Istha Powron

Hello again ParaGurus,

We are using a PSC to control the servos on a UAV for the 2008 Outback Challenge Competition.

We have no problem controlling 6 servos at 2k4 baud, however, when we ramp up to 38k4 and try to control more than one servo, we have two problems;

1) The servos occassionally move unpredictably for their full travel
2) Rather than all servos moving simultaneously, they start to move sequentially. i.e. if you change the position for all servos, they will not change position at the same time.

I have scanned the forums and can confirm;

1) Servo ground and signal ground are common.
2) Servo current and voltage is suficient and stable.
3) We have scoped the outputs of the PSC (with servo attached) and can confirm the wave form changes occasionally for no reason. i.e. it is not a servo problem.
4) The leads between the micro and the PSC are only 3 inches long.
5) There is no source of interference in close proximity
6) There are no poltergeists in the immediate vicinity.

One thing we don't understand is that on page 3 of the PSC data sheet it says that the comms is default as 2k4 8N with 2 stop bits. We assume that when you ramp up to 38k4 the 8N2 remains the same?

We are running the PSC from an ATMEL, but would like to try from a BS2px24. How do you configure SEROUT for 2 stop bits?

Any help would be appreciated.

istha

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔





The robot is going to lose. Not by much. But when the final score is tallied, flesh and blood will beat the damn monster.
Adam Smith

Mike Green

1) The PSC doesn't really use 2 stop bits on the receiving side. It uses 2 stop bits on the transmitting side to accomodate slow microcontrollers that may need a little time to process the characters. With the BS2px, just make sure you're using the proper Baud constant for 38.4KBaud. The Stamp Manual has formulas for calculating this in the chapters on the SERIN and SEROUT statements.

2) If you can, check the bit time timing on the ATMEL. A small difference in Baud between the two devices may be insignificant at 2400 Baud, but it's a big deal at 38.4KBaud or higher.

Istha Powron

Thank's Mike,

We have checked the output of the ATMEL on another ATMEL, with Hyperterminal and with an LCD display. The stream appears good, but that could be an issue. I could put a scope on the output, but I don't think any of us would really know what we're looking for. Do you think the PSC is that sensitive to timing?

As well, we are sending a command string for each channel of the servo;

"!SC", ch1, ra, pw.LOWBYTE, pw.HIGHBYTE, CR
"!SC", ch2, ra, pw.LOWBYTE, pw.HIGHBYTE, CR

We assume you can't do this;

"!SC", ch1, ra, pw.LOWBYTE, pw.HIGHBYTE, ch2, ra, pw.LOWBYTE, pw.HIGHBYTE,CR

We are updating the demand positions of 8 servos at 10Hz. Should we leave a delay between command strings? Or should teh terminating carrier be enough.

Istha

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔





The robot is going to lose. Not by much. But when the final score is tallied, flesh and blood will beat the damn monster.
Adam Smith

Mike Green

I know that each channel has to have its own "!SC" and CR since the various parameters are positional in the command.

8 servos at 10Hz requires 8 bytes x 8 servos x 10 per second = 640 bytes/second or 6400 Baud minimum. You could manage quite well at 9600 Baud.

"the terminating carrier"? Huh?

Istha Powron

Sorry, terminating CHARACTER

The PSC only has two baud settings; 2k4 & 38k4.

I

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔





The robot is going to lose. Not by much. But when the final score is tallied, flesh and blood will beat the damn monster.
Adam Smith

Mike Green

That's true. I must have been thinking of another device.

If you want to keep experimenting with the ATMEL, I'd suggest just putting a couple of characters' delay between PSC commands. I don't know how much buffering exists between the ATMEL's hardware and library routines, but make sure everything's actually been sent from the ATMEL, delay one character time, then start the next PSC command.

If you want to try with the BS2px, just make sure each PSC command is in a separate SEROUT statement. The execution delays between SEROUT statements may be enough.

Istha Powron

Thank's I'll try the character delay and I'll try with the 2px.

I'm tempted just to use a jevelin running 8 virtual peripheral pwm channels in the background.

I

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔





The robot is going to lose. Not by much. But when the final score is tallied, flesh and blood will beat the damn monster.
Adam Smith

Istha Powron

Some success.

If we run a minimum of a 20ms delay after each command, the problem goes away. Even if we run two commands and then a delay the PSC can't cope. The problem then is that 8 x 20ms = 160ms which means we lose the 10hz update. We are now trying to daisy chain two PSCs and send two commands (one to each) and then wait 20ms. It sounds like the buffer is filling up.

I

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔





The robot is going to lose. Not by much. But when the final score is tallied, flesh and blood will beat the damn monster.
Adam Smith

Chris Savage

Hello,

If you look at the output from a BASIC Stamp @ 38.4Kbps VS the Atmel you will find the BASIC Stamp will have more spacing between the individual bytes being sent. My guess is you need to pace your output a little. The PSC works @ 38.4Kbps with the BASIC Stamps up to 16 channels as used with the Hex Crawler with all the attachments. But the BASIC Stamps don’t have a hardware UART. Does the Atmel?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

Istha Powron

Thank's Chris.

I'll get back to you.

I

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔





The robot is going to lose. Not by much. But when the final score is tallied, flesh and blood will beat the damn monster.
Adam Smith