Servo twich when sending serial commands

[tri]

Apologies if this has already been discussed.

I wrote my own PC motion controller and noticed there was a lot of twitching in Hexy’s motions. The servos sit quite still when hexy in not in motion.
I’ve spent a long time diagnosing the problem and it turns out that serial commands sent to Hexy interfere with the servo callback interrupt timer.

Here is a video where I just send what is essentially “Center” servo 10 times a second for all 18 leg servos (i.e. “#5P1500\r#6P1500\r…#25P1500”). Each command is about 197 bytes, so I’m probably exceeding the baud rate (9600 baud is roughly 960 bytes per second right?). But when I toned it down to send once per second, I still saw the same kind of twitch every second.

http://www.youtube.com/watch?v=SYGG5BHXj58

Is anyone else seeing this same behavior? (I don’t think you’ll see anything this with PyMoCo because it only sends commands when servos change, but you will still see less than smooth movement).

Does anyone have any suggestions for how to reduce this twitching? I’ve considered:
[ul]
[]Rebuilding the packet layer to send less data, I tested something like this where I sent 32 garbage bytes per command instead of 197. There was still a twitch, but it was less noticeable.[/]
[]Sending data in smaller chunks (perhaps even 1 byte at a time?). I don’t know very much about the low level details of the serial layer, but I have a theory that these large 197 byte payloads are taking more time than 10us per serial interrupt, and so it causes the servo timer callback to get skipped. I have nothing to back this up with though. [/]
[]Compensating for the serial time spent inside the timer callback, I don’t even know where to begin with this and could use any Arduino fu that this forum is able to provide.[/]
[]Modifying the serial interrupts and only allowing them to occur when all servos initially go into their “Low” state. I’m pretty certain there will be data loss in this case though, but maybe that’s okay if the data is getting sent frequent enough.[/]
[]Any other ideas?[/]
[/ul]

[Hellboy]

Indeed, it’s a problem: All Servos are shaking

Joseph indicated that he’s working on it. I’m sure any coding solution you can come up with would be gratefully received. I believe many of our fellow posters are swapping out servos for ones that seem to shake less, but they are not the problem.

I’m working around it by using a Pololu Maestro 24 controller in place of the Servotor 32 board.

[Hellboy]

On further reflection, if it is the USB serial communication that is interfering it may have something to do with the choice of microprocessor. I believe the Servotor 32 uses the ATmega32U4 processor, which handles USB functions internally.

This in contrast with boards that are based on the ATmega328 or ATmega2560, for example, that require a separate USB chip like the FTDI FT232RL, thus keeping the USB functions separate.

[Yggdrasil]

It exists a simple solution, if you own a bluetooth dongle: Use the bluetooth connection. This way omits the usb interrupt problem.

[Cameron]

I would have thought it was the servos on yours

[tri]

Cameron, These servos aren’t great, but they certainly aren’t that bad. Like I said, I was simply sending the “Zero” command for all servo’s 10 times a second. When I stop sending the command the servos sit quite still.

In my motion controller code, the default behavior is to only send updates for servos that changed since the last send. The idea is that I let my PC decide what position the servos should be in, and it synchronizes the motions to Hexy. Here is an example video where I use a gamepad to control Hexy’s movement speed. Notice how when my hand is off the gamepad Hexy stands pretty still (no serial commands are being sent at that time), there is little jitter in the servos, but not nearly as bad as when Hexy is in motion.

http://www.youtube.com/watch?v=xWCuAgv3jlM

Yggdrasil… nice idea, but I’ve tried the bluetooth connection and get the same results (actually a little worse, I find the bluetooth to be quite laggy, I haven’t spent much time diagnosing the problem though).