Hexapod tripod gait is bumping too much

Lynxmotion Legged Robots
1

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!

Patrick

P.S.: Sorry if my English isn’t perfect, I’m Austrian. :slight_smile:

2

You mention “the tripod gait we implemented”, so I assume you wrote it? Do you make the “point A to point B” moves of the legs in one move, or have you split them up into multiple states, like LM’s code? If you have or can make multiple shorter moves, then you should be able to apply acceleration/deceleration to ALL the joints, and hence in both horizontal and vertical directions. This, I think should be similar to the accl/decel efforts needed in CNC coordinated moves.

Another thought, what is on the end of the legs? Some sort of plastic cap, right? How about reworking the caps so that they are more compliant?

Alan KM6VV

3

hi patrick!

this is what i would have surggested but you have already covered these procedures!

posting a picture might be helpfull but as its a comp concept im guessing you wouldnt want to do this.

maybe the configuration of the batterys or anything holding weight is having an impact on the the stability of the chassis?!!!

its only a surggestion but you find its all the simple things that make the problems!

goog luck with this one. if i think of anything else ill post it.

good luck with comp!!!

4

Hi Alan,

yes, we have written it ourselves. Let me show you the main part of the code:


	for(;;) {

		updateDirection();

		for(i = 0; i < 30; i++) {
			flyBack(flyLegs, i);
			grip(gripLegs, 10 + (i * 20 / 30), 0);
			setLegMovement();
		}

		for(i = 30; i < 35; i++) {
			grip(gripLegs, i, 0);
			moveDown(flyLegs); // 5 mal für 10
			grip(flyLegs, i-30, 1);
			setLegMovement();
		}

		switchLegs();

		for(i = 35; i < 40; i++) {
			grip(gripLegs, i-30, 1);
			grip(flyLegs, i, 0);
			moveUp(flyLegs); // 5 mal für 10
			setLegMovement();
		}

	}

In this version we have tried to damp the bumps by lowering the legs slowly, while they are already moving into the direction needed for our locomotion. The problem I am having here is (this is really messing with my brain :slight_smile:) that the part of the movement that lets the legs speed to the front, change direction and then go down slowly while already moving into the desired direction is taking additional time and I was not successful synchronizing all this to get a uniform motion of the hexapod body. The (i * 20 / 30) makes this part go slower to keep up with the step cycle and I think this causes the water to spill. Any ideas?

We have thought of this, too, but we already have quite elastic rubber feet so I think there is not much potential to make everything go more smoothly here.

Thanks for your quick reply!

Patrick[/code]

5

Just seeing your mainline code is not going to be enough to help you. Where are the calculations done? We need more code.

8-Dale

6

One would have to see and study your grip, flyback, moveup and movedown routines, but I think I’m seeing 3 distinct phases of the gait. The move down and move up sections appear to have 5 states, so you’ve got some “states” to play with. I’m suggesting that you very the time of the last few touchdown states (longer), or move a shorter distance for those states. Something like a look-up table for a multiplier for these 5 states. The travel during the 5 states would then have accl/decl due to the table’s effects.

Note: Or maybe it’s in the first for-loop that you need the accl/decl, you were talking about the 20/30 stuff. I don’t know enough about your code.

HTH

Alan KM6VV

7

What about a ripple gait? :bulb: