Complex trajectories with SSC-32

I am using an SSC-32 to control the servos for my 18DOF hexapod.

I would like to sample a desired movement trajectory, performing inverse kinematics at discrete timesteps to enable the legs to follow the trajectory with less error, due to the naturally convex relationship between joint space and task space.

I am wondering how other people use the SSC-32 to perform more advanced movement? It is easy enough to just tell each servo on the leg to move from the start position to the end position, however in some situations the joint space trajectory may cause the legs to move through some illegal space (say below ground level).
The two options that I can think of are either:

Send commands to the SSC-32 at set intervals.

Store all of the points in EEPROM then play the move.

Neither seem to be optimal as the latency with sending commands every 100ms or so could cause jittery movement, the 20ms update rate of the SSC-32 may also pose an issue. And storing all of the moves in EEPROM may cause some delay between steps as EEPROM can not be written whilst a sequence is being executed.

How do other people perform advanced moves?

Thanks
HeZ

Hi HeZ,

We’re not sure if anyone does anything different, but the two options you listed are the best options that we know. Unfortunately, many of these limitations are inherent to using servo motors. For instance, the 20ms delay is because that’s the period which servo signal usually send new pulses. Also, when the servo receives a new position, it has its own algorithm to determine acceleration curve based on the current position and the size of the “error” to the new position (internal PID controller calibrations).

If you want better control of your motor, we would recommend looking into changing the electronics board inside the servo motors. We have this OpenServo board that has a reprogrammable ATmega328 chip:

If you change your servos to use this instead, you could program it to follow your movement patterns. The I2C and SPI pins of the ATmega are made available via solder pans, so you can use these to update the motors much quicker than the servo PWM pulse signals.

We hope this helps,

Hi Jeffrey,

I am not too concerned with the error in positions of the servos, I am more concerned with the following error of the leg from the desired Cartesian space trajectory. Since a linear movement of the angles will have some naturally convex movement in Cartesian space (Moving the leg from A to B will not produce a straight line, rather it will have some convex trajectory). The more discrete angles that are specified over the trajectory will allow it to follow closer and give a more predictable motion. So I am just looking for the best way to send as many points as I can whilst still achieving smooth motion. Although perhaps that is a bit overkill, only one or two waypoints are probably needed. Maybe I should look through source code for other peoples projects so see how they get nice smooth gaits. But that is probably cheating.

I have seen lots of nice smooth gaits be implemented using the SSC-32. So since your reply confirms my assumption that those are the only two practical solutions, I think I should be able to get it working nicely. Sending it all to EEPROM should not take too long and barely be noticeable between steps so I think I will try that way first.

Parts are almost finished printing so should be taking first steps soon :slight_smile:

Regards

HeZ

We have some sample code for Hexapod and Quadruped gaits here:

The code was made by some members of the Lynxmotion community (Xan, KurtE, and Zenta), so I’m unfortunately not familiar with the specifics methods they used.

Another trick you can use, if you’re sending commands at regular intervals, is to start sending a move while the previous one is still running. If you send the whole command except the character, the command will be cached in memory and you only need to send when the previous move is done to start executing the new move. This way, you don’t have to wait until the previous move is done to start transmitting the whole command for the next move.

Hope this helps,