I thought it was time to tell a little about the application I'm working on these days. Though very far from finished, it's starting to look like something bit by bit. The working-title of the app is actually "Crab-Crap Kinematics Simulator & Generator". Crap-Crab being the quadruped I intend to use the app with. As the name suggests the idea of the app is to both simulate the movements of the quadruped as well as generate serial output, which eventually will control the actual robot.
I started by making an app for a leg only, which I used to get the kinematics and graphics right, then I wrapped that into a class and used it in the app for the entire robot. For now I'm just working on some basic movements such as: hover, sway, twist, tilt, turn and the individual movements of each servo/leg. All of which controlled by joystick, while the camera (position and zoom) is controlled by mouse.
The process has been rather slow and somewhat painful, yet extremely interesting. It is unlike anything I've ever programmed before and pretty much everything is new to me. I'm using the language Python, which I've used very little previously. More specifically I'm using Visual Python, which I didn't know existed until last week. The app is filled with linear algebra and trigonometry, which I had all but forgotten. I'm doing 3D simulations, which I haven't done in like 15 years. And off course I'd never even heard about kinematics a couple of weeks ago.
I have several ideas for the future. One of them being using the app to visualize different sensor data in real time. Another is creating a way of recording and editing sequences of basic movements, thus creating new walking gaits in a matter of minutes. This may open up the door to creating gaits that would otherwise never have occurred to me sitting in front of a keyboard.
When I get a little further I'll start posting the code off course. I would also like to find a way to create Windows/Linux executables, but so far haven't had any luck with that. For now I just created a small video to give you an idea.
If you guys have any ideas please let me know :)
UPDATE:
A bit more about my ideas for the app...
Basically there will be two ways of using it:
(1) As a standalone application with a predefined control interface where you can try out basic movements as well as record, edit, playback, load and save sequences, which you can use to create gaits without writing a line of code. At any time you can turn the serial communication on/off.
(2) As an API where you just import the app as a module and then you're basically on your own. You can then write your own gaits and AIs etc. And you can choose to hide the control interface (entirely or partially) and replace it with your own. What is left of the app then is the visualization of the robot, automatic serial communication and a set of methods for manipulating the robot.
Now working with sequences the program wont be recording the movements as fluid motion, but rather you have a set of frames (which you can insert and delete as you please), where each frame will contain a fixed position of the robot. The program will then calculate the intermediate positions to create a fluid motion.
Apart from being able to control the robot with joystick (later keyboard too), you can also set the angles of the servos directly, for better precision. The program will then calculate the foot positions using forward kinematics. Or you can set the foot positions and the program will calculate the servo angles using inverse kinematics.
I updated the pic in the topic description to give an idea of what the control interface will look like.
"That looks really nice. Hope your physical machine behaves the same!!"
Thanks! And I believe eventually it will, although for now I’m still having a lot of problems with the servos
"Do you have provisions for modeling the real motors and leg structures?"
Not entirely sure what you mean by that. If you mean whether I have plans of making a model that looks more like my actual robot then the answer is no. Infact I very much intend not to. I might change it somewhat, should I feel the urge, however I like it simple like that, and I like the fact that it doesn’t look like a game, but rather a scientific tool. Besides I wanna be able do draw more auxiliary lines and vectors, which wouldn’t be visible if the robot was more solid. For instance I wanna draw the projection of the center of gravity unto the walking plane and the triangle representing the supporting area between the legs on the ground when a leg is lifted. Stuff like that which will actually help me visualize the physical laws pertinent to the study of motion of a quadruped robot.
is allowing for dimensions of the body and leg segments. I also believe that might be what was being asked about with respect to different configurations.
There are actually a few things I would like some general input on…
(1) I’m currently thinking about different ways of describing a walking gait. That is I’m trying to find methods of notation to describe gaits that are both as short/simple as possible and yet as generic/flexible as possible. So to everybody who has fiddled with walking robots I’d like to hear your ideas on this.
(2) I’m also thinking about how to format the serial communication between the app and the Arduino. For starters I need to decide the level of precision of the servo angles to work with. So I’m trying to decide whether to use 8 bit words or 16 bit words for the serial communication. If I use 8 bit words I figure I could get 0.5 degrees of precision by limiting the servo movement to a range of 120 degrees. Thus I’ll be sending numbers between 0 and 240. Obviously I wanna limit the serial traffic as much as possible, but I don’t know if this level of precision is enough in the long run.
Ah yes that off course is the plan. Currently these dimensions are set by constants which can be easily changed. Making them configurable via the visual interface wouldn’t be too hard either…
I was think along the lines of random errors, delays in reacting to stimulus, overshoting. Sorry, I spent too many years in simulation land!! Ideal behaviors were highly discouraged.
As for the gait description, the paper that you previously linked to, the one about a measure of stability of the gait, has at least two compact ways of describing a gait – one using the timings for the gait events (lowering and raising of the legs), and one using cycle time, duty factor and relative phase of the legs.
Hmmm… About that protocol… Don’t know why I would send 4 bytes to move one servo? Why do you think that is a good idea? Off course in the long run I would have to send some kind of “package header” if I want the control app to send other things besides servo updates, but this can be done with ONE byte per “package” (a “package” being 1 to 12 servo updates).
And yes I remember those notacions. I’ll take a look at them again. However while they certainly are simple/short, they aren’t very generic/flexible as I recall. These notacions contain no information about the movement of the body (which is the hard part) or other details, only the pattern in which the legs are being lifted. But thanks for reminding me.
I’m not saying you should copy it, but there are some ideas in there. In particular, the fact that all commands have the highest bit set, and all parameters have it unset – this way you can recover if the transmission has been interrupted and resumed in a random place. Other protocols have other ways of doing that, such as synchronization bytes or control sums.
As for body motion – I do all the calculations on the python side anyways, and I yet have to move it all into arduino code. I didn’t think about it too much yet.
