After stumbling on this site and seeing the various videos of hexapods, I was immediately hooked - I want to build one. My first big problem is that I’m broke, so I have to start out with what I can actually do - write the code to drive the walker. But since I don’t yet have any hardware to try out, I thought I’d post here to get some feedback and make sure I’m not taking a wrong-headed approach.
So here’s the plan:
The goal is to create a 3DOF/leg hexapod that will be driven (for the time being) from my PC (actually, Mac OSX) via serial connection to a SSC-32 controller. I type in a heading, and the bot walks that way. Rinse Lather Repeat.
I’m not a real programmer, but I do know my way around Ruby in a brutish way, so that’s where I started. So far this is what I’ve got:
I defined leg objects (comprised of link objects) and created forward and inverse kinematics methods that I can call at any time. The step routine works like this:
I input a heading at the terminal.
the program generates a direction vector from that heading, and uses a pre-defined step height, step length and step trajectory function to define the path of the foot in 3D. (To keep things simple, I figured a step would follow the path of a sine wave).
that sine wave trajectory is approximated by a series of linear segments.
store the sequence of joint angles in an array (for example, if the step is approximated by 5 linear motions, there will be five sets of servo angle inputs, generated via the inverse kinematics routine).
convert those joint angles into SSC-32 commands
send the commands to the SSC-32.
That is just for one leg, of course. For a hexapod, you’d do that for each leg so that you stack up the commands required for 1 complete gait cycle and then let them rip. Once it’s done, the bot will wait for another heading command.
So is this crazy? I’m concerned about jerky motion and the possibility of weirdness if the segment size is made too small for the servos to resolve properly.
So far, it works for my virtual leg (I’ve run some tests and my code generates the proper numbers to make the leg move as asked), but is there a better way?
I’ve not yet done a multi leg set up or the actual translation to SSC-32 speak yet, but the one leg program seems to be working.
I forgot who it was, but I saw a video on youtube of a CH3-R simulation versus the real thing. This guy simulates a CH3-R in the virtual world and the CH3-R in real life follows the movement in the sim…
Wow. That is quite impressive. My program is basically a command line only, hacked-together-by-an-amateur version of that. To get any visual confirmation that the numbers are correct, I have to cut and paste into a graphing program…
After a little more thought, I think my question can be focused on the calculation and timing of the servo commands.
As written, I’m calculating all of the movements required for a gait cycle (6 steps) before sending commands to the controller. Would it be better to send commands every step (rather than every 6 steps)?
And what is the preferred way to time the commands to the SSC-32 so that they don’t step on each other. I noticed that the SSC has a query command to see if the motions are complete. Should I use that, or can I safely assume that the motion times will be pretty accurate?
I’d much rather skip the query if I can get away with timing the motions pretty closely together (close enough to eliminate any perception of gaps between motion segments). Any advice on how close I can cut it? Are we talking mS or tenths of seconds?
Once I get the code finished, I’ll pick up a controller and test it out. Do you think there’s any interest in a Ruby wrapper for the SSC-32 commands? I think I’ll probably end up writing one before I’m done. I’d be happy to post it when finished (assuming I can get it to work).
I don’t have any specific data on the accuracy of the T value. However there are some delays outlined in the manual as they pertain to queries. None of them are greater than 100uS. Because the T command is at the core of the SSC-32’s process I seriously doubt there are any issues with the accuracy of it. I will ask Mike to comment on it.
As for Ruby, we would welcome and host any useful information you send us. Thanks in advance!
Thanks for the help. There’s only so far I can get before getting my hands on hardware, of course, but every little bit helps so I can be well prepared when I get some spending cash.
As for the usefulness of my code, that remains to be seen… Is anyone else around here using Ruby to command their bots? I’ve seen a few references to Python and lots to C, but none for Ruby, which is a shame because it’s so easy to work with.
If you add together the sources of delay, the T command can take up to 30 ms longer than the value specified. This is mostly due to the fact that servo pulses are only output every 20ms, combined with the time it takes the SSC-32 to process a long command. The servo move will never end sooner than specified by the T command.
The 30ms value does not take into account communication time (depends on Baud rate and message length) and the actual servo move time (depends on the servo).
If you send a new move command before the previous one has quite finished, the SSC-32 will start the new command from the current position and honor the new T parameter.
Thanks, Mike. Sounds like some trial and error is in my future. Seems like I should be able to get it pretty smooth if I play around with the lag between T commands. I also sounds like it’s ok to overlap commands a little bit for my application.
I couldn’t help myself - took the plunge and ordered a controller yesterday… so I suppose I’ll answer some of these questions soon!
Thanks in advance!