still working on them

Rebuilt knees and battery holder clips after they broke from fall. Changed feet and ankles. Making ankles stronger and different design. Removed toes and servos for toes. Installed 10 ft. rail to ceiling to catch feet if they fall while walking. Only had 5 ft. rail before. Still trying to get the motion for the step right.  

Ray.Edgley's picture

Servo Control

Its good to see your legs back up and walking :-)

With the motor controller your using, do you control the power and direction or the speed and position?

Can you control to power and position with an external PID loop?


harland's picture

motor control

I am using roboclaw motor controllers.  There is several ways to use them.

above is one of the commands in the step routine
so 0x80 is board address, 2000 is speed in rpms, next 2000 is acceration, next 2000 deacceration
the 1800 is how many rpms to turn, the 1 means don't buffer the command excute it now.
to make the motor turn the other direction the 1800 would be -1800. the M2 means the 2nd motor attached to the board. I have PID values loaded in the 3 roboclaw boards, each board does 2 motors, but I am using those to get accruate moves ie tell it to move so many rpms and then see on the encoders that it did it.
I have a dead zone of 10 rpms so it does not 'hunt' forever.  You see if you look close the  motors sometimes go back and forth to find the final position.
But I think what you are asking can I do run the PID loop from my C program and yes I should be able.
I don't really know how to program that.
appreciate your help
Ray.Edgley's picture

Keeping the Balance :-)

Your correct in where I was going with the questions. Sort of......

Inside MRL, there are 2 PID service, one for a single PID loop and one for multiple PID loops.
There are also service that cover the more popular IMU's

The MRL system supports the Python language structure which is reasonably easy to program in.
More importantly, the MRL system is most likely what the rest of your robot will be running.
You will after all want to tell your robot to follow you or go and get you a beer.

Your balance control system will also need to know what the rest of the robot is doing, such as arm movements, as this can throw the robot off balance.

I would also look a lifting the mass of the robot up higher.
For the purposes of testing I build a second Chassis and mounted that on the legs.
I plan for the mass of the batteries to be about halfway up the chassis, maybe a bit higher.

Just below the white section.

The use of the waist section will also become very important.
There are two types of movement we need to be aware of,
1) Linear, typical as the robot is moving forward, or left and right.
2) Rotational as the body pivots left and right to take a step.

The use of the waist rotation allows us to take the rotational movement out of the equation as we walk.

Just some more food for thought.

I will no doubt cover this in my next Walking Robots blog.

mayaway's picture


Excellent work! I think the legs may wind up needing a transverse joint at the top so when you perform the weight shift, the top platform will remain parallel to the floor. The ankle angle and the hip angle would adjust in concert. Rem we need to put 35 pounds of InMoov on top of that platform & can't have it swing off laterally.

Ray.Edgley's picture

You are quite correct.

The reason I added a entire chassis was to allow to mass to be added approximately where the mass will be.

And the joint at the waist needs to move not only side to side, but also back to front as well.

This is all about how we recover the balance by using the hip. If we note that the body is falling forward, we can move the hips and waist back to relocate the center of gravity to a point behind the feet, the mass being up high will not immediately move back, but will start to accelerate back after the CG has moved back.

Remember the sum of all the masses is used for the CG, but individual masses will resist movement, Our only real hope is to use that to our advantage.