Hexapod tripod gait is bumping too much!

Hello,
we are participating in a competition held by a local university where each of the participants got a circular hexapod robot that has to be
trained to run as fast and as smooth as possible. The smoothness of the motion is measured by a little cup located in a larger cup that is fixed to the hexapod, where the inner cup is filled with water and has a scale on it. So far so good... However, we are facing a problem here that has already cost us quite a lot of time:
Whenever one of the three-leg pairs of the tripod gait we implemented hits the floor, the whole body of the hexapod suffers quite a bump that spills a lot of water, which we want to avoid. We have done the servo linearization and the hexapod calibration very, very exactly and are able to set the footpoint to almost any point with an accuracy of less than a millimeter, but there are still those annoying bumps when walking. We have tried to just make the part of the movement where the legs are set down to the floor slower, but then the deceleration and acceleration in horizontal direction causes another impulse on the water cup and spills almost the same amount of water than the bump we are avoiding with it.
And to be honest, I have spent so much time in front of this f****** AVR IDE in the last few days that I think I'm going to go crazy right now, so I would really, really appreciate any suggestion we can get. This concern is also quite urgent, as the competition takes place this thursday! Please help!
Thanks in advance for your replies!
Yours sincerely, Patrick Themessl.
P.S.: Sorry if my English isn't perfect, I'm Austrian. Smile
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

In robotics, it is generally good to have an acceleration/ deacceleration curve for all movements. If you had some success making a more gentle curve for the up/down motion, then perhaps you also need to add this for the front/back movement.
By the way, servos often have their own internal acceleration/ deacceleration curves. The best servos allow you to adjust this curve (by some sort of digital interface). There is also some "dead space" where the servo won't attempt to move. I've also played with cheap R/ C servos and been able to adjust some of its "tightness" by changing the rate at which I send pulses to them. Normally, a pluse lasting 1 to 2 ms is sent every 20 ms. But, by increasing or decreasing the 20ms value, you can adjust how quickly the servo acts to correct its position.
Joe Dunfee
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi Joe,
thanks for your reply.
I will try varying the frequency of servo pulsing and see if this has an effect.
The robot is actually not one produced by Lynxmotion, I was just looking up "robotics forum" in Google and this is where I was led and because of the fact that their hardware seems to be very similar to the hexapod we have, I thought I'll take a chance asking. An image of the hexapod we have can be found here:
    
http://forum.hexapod.at/forum/galerie/bilder/bild-99.jpg
Hardware modifications are unfortunately not allowed, so we have to live without any feedback.
At the moment, I am thinking that one of the main problems we are having is that the CPU speed of the C located at the board is just too slow. When working with an incrementation of 1 for each cycle of the gait sequencer loop, the hexapod seems to stay relatively stable, but much too slow. The only way to make it go faster is incrementing by 2 for each loop cycle, as there is no artificial delay in our code anywhere and the C is operating at its limit, but then (especially in the leg-up and leg-down sections) the movement gets too unexact. To solve this, we tried to pre-calculate the servo angles for steps in each direction we want, but then the program gets too large to fit on the C.
Another question: Does anyone know a web site where a tripod gait that does not stop the body of the hexapod for changing the stance legs is explained in detail? I think I am having some conceptual errors in my code, too.
Thank you very much for your help!
Patrick.
cadcoke4 schrieb:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Mon, 07 Apr 2008 23:18:43 +0200, Patrick Themessl

Try one leg at a time, in the sequence (using DIP numbering, 1 = left front) 1 - 5 - 3 - 6 - 2 - 4 ... You still have your triplets (1, 5, 3 and 6, 2, 4) but now you have six small taps instead of two kalumps.

8-)
--
Rich Webb Norfolk, VA

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Patrick Themessl wrote:

This person also asked the same question on a Lynxmotion support forum, at
http://www.lynxmotion.net/viewtopic.php?p9015&sid 6fc52e8197b373af7d723a668215c3
The discussion there is more informative. He's apparently using a Lynxmotion CH3-R robot:
http://www.lynxmotion.com/Category.aspx?CategoryID1
This is a nice piece of machinery, but has no useful feedback. For over $700, there should be more sensors on the thing, enough to do what Rod Brooks was doing twenty years ago with his insect robots. But no. There's no force feedback signal for the servos. There don't even seem to be foot/ground contact switches. It's a dumbbot.
The typical programming approach is to put a table of leg position values into an Excel spreadsheet and load those onto the robot's CPU. Given that you have no useful info about what the legs are doing, that's probably as good as it gets.
                    John Nagle
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John Nagle wrote:

John is correct ... feedback is the answer here. Yes, you can always deaccelerate at the point of motion where the leg is most likely approaching the ground, but this is a bit wasteful of the hardware. But, following John's link to the Lynxmotion forum I get the feeling hardware mods are not allowed, as the student groups get the use of the robot, and the next tgroup may not appreciate the hacks made to it. So that means going into the servos and tapping out the motors for EMF feedback, or maybe even attaching some rudimentary whisker sensors, may not be allowed.
This has me thinking what overall use the exercise might have. If it's purely a programmatical problem, then it's all in the gaits and accel/deaccel curves. But it seems to me this is like trying to build a fuel efficient car using steam. The robot will never do as well than one with even simple feedback.
I once experimented with the servo controller from NetMedia that touts force feedback using unmodified servos (unmodified for rotation and unmodified for picking off the EMF from the motor). It worked well enough that the concept behind how it works could probably be used here to achieve a substantial improvement for this application, without guessing at how the robot should walk - i.e., the robot will decide that in actual motion. And this approach would not require hardware modification.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

Exactly. This is what irks me about most robotics hardware for hobbyists - totally inadequate feedback. This is teaching kids the Wrong Stuff. If you want to deal with the real world, you have to have considerable feedback. This is NOT like programming a computer, where what you command happens reliably.
The pathetic thing is that even simple R/C servos have position and current info available within the servo, yet so few of them bring it out to where a controller can read it.
The Dynamixel servos have real feedback and a two-way digital interface, but are more costly than R/C pulse-coded servos. Bioloid, Troxxen, and Robotis robots now use them. Slowly, the hobbyist robotics industry is getting enough volume that the components become affordable.
                    John Nagle
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John Nagle wrote:

However it would be counter-productive to add this to all the hardware because there is no one generic use of robotics components. It would generally be overkill, for example, to provide feedback (and therefore cost) for servos used on the typical line-follower. For kids price is paramount; you don't want to foist $300 kit of fancy parts when $100 will do.
To me this is an integration issue, but it won't get better any time soon. The Robotis servos are nice, but I bet the company is still working through the R&D cost. It's not like hobby servos where the R/C market - which does not require feedback - is MANY time larger than amateur robotics.
The ideal product is the one with a base model at an affordable price, and options that can be added on. It's a wonderful idea, but who has the money to create such a product line for what is ultimately a market of a few tens of thousands of potential buyers. Too rich for my blood!
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

The Linxmotion 6-legged thing is over US$700. At that price, there should be decent sensing.

Things are happening faster than you think. Take a look at "http://www.robots-dreams.com " for what's going on in Japan. Some very interesting robotic toys will be shipping for Xmas 2009, too.

For some things, especially electronics, integration is cheaper than add-ons. The extra silicon is cheaper than the connectors and wiring for the accessories.
                    John Nagle
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John Nagle wrote:

You're still missing the point. For R/C servos, 99% of the intended buyers would have no use for such a thing. The manufacturer is wasting his money, even if it's only incremental. There is no business sense in that, and this is business. They couldn't care less about the state of the art of robotics. (And those that do charge a lot for those servos, if you've ever priced them. Beyond what most of the kids you referred to a message ago can afford.)
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

Some of Hitec's newer servos supposedly talk a "proprietary HMI protocol", which supposedly allows daisy-chaining. There's a document on this ("http://hitecroboticsusa.com/Tony%20information/HMI%20Protocol.pdf ") but it's almost useless. Somebody finally reverse-engineered the things and produced a document:
http://robosavvy.com/Builders/i-Bot/HSR8498HB%20Servo.pdf
which at least describes how to talk to the thing via a serial port at 19.2KB.
Much to the annoyance of robotics people, the Atmel ATmega8 in the thing has been set to "mode 3, further programming and verify disabled", so you can't look at or replace the firmware.
                    John Nagle
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 09 Apr 2008 09:41:02 -0700, John Nagle

I think you guy's insistance on feedback is a little over done for this application. If the bot were moving over uneven ground then leg position feedback might be of use, but probably not in this case. Perhaps you could desribe the benefits that would make it worth while in this instance. As for the $700 bot without sensors, start making one for $700 that is laden with sensors and get rich! ;)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Si Ballenger wrote:

Don't underestimate the benefits of force-based (as opposed to position-based) control. A couple classic examples where force-feedback dominates are writing and drilling/grinding.
With force feedback, this guy could have moved the legs into position and then lowered them under force control, thus setting an upper bound for the acceleration. Instead, he had to lower them "slowly enough" that it "usually worked".
That said, heavily-geared motors (e.g. hobby servos) are horrible for force control due to (a) friction (b) backlash and (c) the large downconversion of the geartrain. Real torque motors run nearly direct-drive, but they're big, heavy, pricey, and use high voltages. So we make due with hobby servos instead.
- Daniel
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
D Herring wrote:

This is why I suggested a simple feedback via the serial servo controller. It's a coarse guide, but in my experience it at least can be used for determining if a bot is trapped against a wall and otherwise not able to sense this because of its sensor arrangement. The NetMedia controller is the only commercial one I've seen with this feature built-in, but there might be others. With this type of device force feedback is basically free, except for the cost of programming.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

http://www.lynxmotion.net/viewtopic.php?p9015&sid 6fc52e8197b373af7d723a668215c3
It doesn't really invalidate the points you are trying to make, but the original poster is not using the CH3 - just one similar in configuration. (see the 1st reply to cadcoke ... )
fwiw ... jcd
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
pogo wrote:

If you have to do this without feedback, probably the thing to do is to put in an IK solver and control the endpoints of the feet.
                    John Nagle
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

By "IK solver" do you mean Inverse Kinetics ? I've never tried any of that at all, so I'll ask this: given the limited hardware, would it involve a look-up table or would it need to calculate everything *completely* for every step ?
Just a thought... thanks! JCD
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
pogo wrote:

Inverse kinematics; given the end point (foot position), calculate the joint angles.
Here's a simple two-link 3D IK solver in Java, with a demo applet. The first joint has 2DOF, the second joint has 1DOF, which, I think, is what your robot has.
http://mrl.nyu.edu/~perlin/gdc/ik/talk.html
Doesn't even need any trig functions.
Once you have an IK solver, you can treat six legs as two triangular supports, each of which is moved as a unit.
                    John Nagle
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John Nagle wrote:

Since they can't modify the hardware there is no way to tell the foot position other than "guessing" where it should be at given the instantaneous pulse position sent to the servo, and waiting X for the servo to travel there (and hoping it does).
I don't think this solution gives them much more than they had to begin with for their particular problem, frankly, and at the cost of more coding for what they programmed their robot to have (one gait).
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Patrick Themessl wrote:

Could you put some soft rubber neoprene feet on the bot?
Bob
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.