Walking Robots.

The day when we can ask our robot to get us a beer and it walks to the fridge get the beer out and returns it to us out in the shed will be truly a great day.  There are some who say it can't be done, and those people will never achieve this ultimate goal, but as a community this goal is achievable and quite possibly before the end of next year.
 
The rate of advancement on the Open Source Robotics community is nothing short of miraculous.  We now have robot that talk to us, give presentations and interact with people in real time.  They can understand to a point (but this is improving) what we speak and can even recognise our face to identify who we are, all of this under the MyRobotLab Operating System.
 
My goal is to have my robot walking on un-even ground without falling over. We all have either ramps, stairs or some form of un-developed ground nearby, it would be a shame to have these areas out of bounds for our robots.
 
I do not believe that a single Maker can achieve this goal, but as a community of Makers with skill set across a large range of areas it can be achieved.
 
This blog is aimed at getting discussions about the walking robots and what is needed to accomplish the end goal of a walking robot.  There is no right or wrong way of doing this, but with the input of many different opinions, we may just find the best most cost effective way of doing this.
To start I will first break the project down into smaller parts.
  • Hardware / Framework and pivot points (Degrees Of Freedom - DOF)
  • Mechatronics / Motors, motor controllers, sensors, power distribution and communications
  • Control system / Types of controllers, number of controllers and software.
There has already been a great deal of progress on the hardware front with a number of potential designs being published on ThingVerse:
Of these, I believe the most promising is the Bartods aka Bartcam version.
There are also two remixes of this version, one starting with:
Damian legs (InMoov) - Tall parts split in two by AcapulcoRolf https://www.thingiverse.com/thing:2320603 and Damian legs (InMoov) Manifold by monnerby  aka Mats https://www.thingiverse.com/thing:2557736  As a result I will be concentrating on this design.
 
Bartods design included two strain gauges (load cells) in the bottom of the feet.  Bartods original idea was to be able to weigh what Damian picked up, I had other thoughts and talked him into adding a third load cell to the bottom of each foot, don't think I fully convinced Bartods of the benefit of the extra load cell. My thoughts were if the load cells were arranged in a triangle pattern in the foot, as the foot was being placed on the ground, the controller would be able to see what im-balance was present on the base of the foot before the full weight was applied and the foot could be levelled by the ankle servos to so that when the full weight of the robot is applied to the foot, it would provide a good stable footing preventing unwanted tipping motion to the robot.   This would also allow the robot to determine the ground plane with reference to the accelerometers. The extra load cell also increases the robots load caring capacity by almost 50% as an added advantage.
Each of the specified load cells has a capacity of 50Kg, with 3 load cells distributing the weight evenly we have a max load capacity of 150Kg.
 
One of the challenges of walking on un-even ground is if the foot does not level to the ground first, it will cause the robot to tip towards the downhill direction until the accelerometers report the problem to the controller and action is taken to prevent the fall.  For this load cell based auto foot levelling to work, each load cell requires its own Analog to Digital Converter (ADC), Bartods has specified the HX711, this is a relatively low cost small sized unit and there is a couple of Arduino libraries for this module.  One of the libraries available is for multiple HX711, allowing for all three to be connected to a small Arduino Nano, all located in the foot.  The signals from the load cells are very small, in the mV range, to keep the electrical noise out of these signals, it is best to have the ADC in the foot next to the load cells, and with the Arduino Nano in the same location, most of the interfering noise can be eliminated.
 
Next question is how to get the values from the load cells to the main controller.  My suggestion here is the I2C bus. The wire library for the Arduino allows for the Arduino to not only be a master on the bus, but as a device as well or instead.  And if we are using the I2C bus in the feet, then there is no reason why we can't use the same I2C bus for the servo controllers in the legs.
 
Servo Controllers come in a variety of styles and types.
  • The traditional PW signal to a self-contained servo controller
  • A dedicated servo controller using communications to receive commands and setting and to report back position and motor load
  • Main controller type setup using the likes of the DIY servo service in MRL.
While I know Bartods in creating the first option in his build, I prefer the second option, leaving the PID control to a dedicated controller but with the ability to adjust the PID settings via the control and to obtain the current position and motor load. The ability to determine the current position before enabling the servo motor will have the benefit of not causing the servo to move in an un-expected matter especially during start-up.  You don't want the servo moving to a standing position while the robot is seated, or moving to a seated position while the robot is standing. What would happen if the power was removed and later re-applied while the robot was standing on sloped ground?
 
If we are using the second option, what method of communication do we use?  If we are using the I2C bus to talk to the scale controllers in the feet, then why not take advantage of the same bus for the servo controllers?
In any type of servo system, you need a feedback system so the servo controller knows the position of the servo output.  What type of feedback system should be used?
The options as I see at are as follows:
  • *The Potentiometer. This type is typically used on rotating axis providing an analogue feedback as a voltage divider.  The pro's as it were are that its simple, cheap and somewhat reliable. The down side is it's a mechanical device that does ware out over time and can be adversely affected but dust built up and electrical noise.
  • *Optical Rage measurement typically used on linear travel systems. Pro's it's easy to setup for linear travel and can be very accurate, the down side is it is very susceptible to dust.
  • *Pulse Encoder on the motor. Typically used in all types of systems. Pros are it very reliable and very accurate, I have seen this type of system in use and working well after 30 years of operation, the down side is the system must move to a home position on start-up otherwise it has no idea where it is.
  • *Absolute Encoder. While not very common due to the complexity and cost, these encoders are very accurate and are available in a range of resolutions; they can be setup for either rotational or linear travel and are virtually impervious to electrical noise. The down side is they can be susceptible to dust just like the pot.
 
As our motor controllers will generate a fair amount of heat as will the motors, and it would be far better to have the motor controllers as close to the motors as possible to help reduce the electrical motor noise, we will need to have either convection cooling or forced air cooling, either will bring dust into the system 9 For this reason, I would be hesitant to use an optical system.  During start-up, we don't want our legs moving to their limits to determine the position, and while I would love to implement an absolute encoder, the best option for us at this time would be the pot.
 
Inertial Measurement Unit (IMU) is a small device used to measure both rotational and linear travel movement. This is required for the robot to balance, particularly while the robot is in motion.
Walking can be described as an exercise in controlled falling where the goal is to not hit the ground.
I believe that we should have at least two IMU's installed in the robot, one located around the waist of the robot around the base plate or as Bartods called it the podstawa_dol. This can also be connected to the same I2C bus.
 
Finally we come to the main controller. Now this is just my opinion, however with such a timing critical section, I am hesitant to use anything running an operating system.  Operating systems can and do by design perform multiple operations on a time slicing basis, MRL is therefore run as a time slice.  If one of the other running operations takes longer than it should as a result of and error in network communications or even a time clock or periodic function occurs at the wrong time, our robot will fall over.  For this reason I suggest a dedicated Arduino such as a Mega2560 be used as the main controller and that be directed by the main brain computer running MRL.
 
All of the current servo positions, estimated ground plane, motor loads and orientation can be fed back to MRL while MRL can give instructions such as what direction to travel, speed of travel, and most importantly perform obstacle avoidance and provide backup IMU information as well as estimated load shift information based on the arm and body movements.
 
This should be enough to start some discussion or even debate over, please have your say below.
Thanks to Rolf I also have to following Video as well
https://youtu.be/T7SEyvPtWFY
 
https://youtu.be/2PsQwUpx7eg
 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kakadu31's picture

I'm impressed by the great

I'm impressed by the great resume you made Ray. Despite I am a big Fan of solid wheels and prefer them over legs on my robot, I think this is both, a great overwiev about the current situation and progress and goal for the future with a clear plan or set of options for eac step. I'm curious to see your progress in the next time.

Humanoid's picture

Longblog is Looooong

Your efforts here are appreciated, Ray. If DARPA can do it, so can Open Source, with the right contributions. Here's hoping. 

Ray.Edgley's picture

Thanks

Personally I think Bartod should get most of the thanks with the effort he has put in.

I know I apreciate it, and I don't think I'm the only one.

 

bartcam's picture

THX

thank you very much it motivates me to act and raises my spirits.

harland's picture

one step

So i have been working on Mindach design which is on thingiverse. I am using 12 volt DC motors with encoders. A mega board sends commands to the motor controllers. I have been printing at 50% fill in ABS or \nylon-X. Each leg has 3 motors and 2 servos.  The toes are just for looks. I have broke many parts. Each leg motor has a limit switch marking travel end and an opto sensor for home position. There is a lot of force on the hip movement and I splt the Nylon-X part on Sunday, again. I have broke this part 3 times and am changing my design. 

Really happy to see your post describing your thoughts on a leg!  I have been able to do 2 steps on a level surface and cannot  believe this design will ever do an uneven floor.  But havng fun working on it.

Harland

Ray.Edgley's picture

Keep up the good work.

Hello Harland,

What is the Thingverse address for your leg? they look good.

If you help with your design, post here the problems your having, I have noticed that a lot of the makers here rise to a challenge, any challenge of a technical nature.

Just look how far they have come in the last 6 years...

As a team effort I believe we will have at least one walking robot on level ground possible this year and un-even ground by the end of next year.

If all goes well maybe even 3 walking robot by the end of next year.

Ray

harland's picture

one step

So i have been working on Mindach design which is on thingiverse. I am using 12 volt DC motors with encoders. A mega board sends commands to the motor controllers. I have been printing at 50% fill in ABS or \nylon-X. Each leg has 3 motors and 2 servos.  The toes are just for looks. I have broke many parts. Each leg motor has a limit switch marking travel end and an opto sensor for home position. There is a lot of force on the hip movement and I splt the Nylon-X part on Sunday, again. I have broke this part 3 times and am changing my design. 

Really happy to see your post describing your thoughts on a leg!  I have been able to do 2 steps on a level surface and cannot  believe this design will ever do an uneven floor.  But havng fun working on it.

Harland

bartcam's picture

DIY servo driver (microcontroller)

Here is the link to DIY servo files http://bartcam.jcom.pl/t/1

Mindless's picture

Cool,,,

Nice wright up,,, Im more Mechnical then software but know the basics - still got a fair bit of work to do,,, but not far off from becaming a pain in MRL ass with Q&A,,,

Ray.Edgley's picture

Don't discount your ability to contribute

Hello Mindless,

The project of making a bipedal robot walk is going to take a number of people from different fields to solve the various problem we will face.

There is still Mechanical issues to be solved along with control.

Even the design and shape of the leg may change over time as we progress.

If you see a possible problem or better still a solution to a problem that you see, don't hesitate to speak up.

Ray

Mindless's picture

No Worries,,

Hay Ray,, I see I lot of potential Mechanical problems mainly strength/load/Friction on some of the plastic areas,,, I’m completely re-building Inmoov but keeping Mr Gaels Outer Shell and all Basic Mechanical operation such as Gear ratios etc,,, so there’s no conflict with MRL Scripting 

The overall design of Mr Geal’s Inmoov is fantastic,, I know Mr Gael is trying to keep the Cost down and allow people will Small Printer to build him (but I am not),,, 

Have been designing BedBed 3d Printer or about 6 years now and have a Farm/Fishing /Metal Work ect,,, background so inventing contraption for Small Crops/Trawlers and problem solving mechanical problem goes with the territory – ill start posting some of work on MRL for Feedback because it seems to be a more active community then the Inmoov site,,, 

I have actually been following you Guy's for a couple of years now,,,

Ray.Edgley's picture

Keep On Upgrading

I did see a few of your posts on the Inmoov site and the bearing inclusions are a good idea.

I'm from an Industrial Electrical background with years of Appliance service as well, so a strong diagnostic background.

When you upload your alternate designs with bearings, can you include the bearing number and brand of baring that you use?

While the brand of bearing you are using may be common in your area, it may not be in other parts of the world, in this case, matching the bearing number to a locally available one is easier if the brand of the original is known.

I like to hide the wiring where ever I can, it usually protects the wires from mechanical damage. With the low voltage stuff I also like to make the wires bigger than strictly required as it reduces Voltage drop when motors are under heavy load such as when starting.

With your alternate mechanical designs can you allow for the wires to be internal through the bearings in locations such as the shoulders ect..?

Eventually I would like to see some code for process removal of material as opposed to the process addition of 3D printing for some of the high stress load components.

I know Bartcam is looking to use stronger motors and drivers for the legs as the standard servos are not strong enough or fast enough for requirements of walking.  This could then be translated into upgrades for some of the other high load joints such as the elbow and omoplate.

 

In the mean time, Keep up the good work,

Ray

Mindless's picture

That's The Plan,,,

Yep,,, I Know what you mean about “Hiding Wires” I’m not a fan of messy work and was constantly worried about losing Room with the Pot Holder System but I am refining the design so the wires can still run through the centre,,, the amount of adjustability is overkill at the moment and will be reduced to about +/-15degs now that I’ve got the design worked out – The Gearbox’s have been Completely Re-Built and adjusted so it’s almost a Print/ Bolt together and Play System,, there will be   instruction and Hardware List with a worldwide Bearing Suppliers – I can keep a few bearing kits on hand if someone’s is having trouble location them,,,,90% of people won’t have trouble finding the Metric Bearings,,, – I’m a Aussie so I have good access to everything.

I always release the SketchUp Files so people can Mod to suit their needs too,,,

Now that the Genuine Legs have been released it’ been a good incentive to spend more time on Inmoov and get the top half to a stage where I’m reasonably happy,,,  but I still have other projects have to be done,,

CNC or Reverse Moulding of some of Inmove’s high Stress Zones would be good project to do in the near future

Like Most People these Days,,,, I’m Time Poor

Ray.Edgley's picture

A fellow Aussie!

Hello Mindless,

Where about in the great southern land downunder are you?

I'm in Country Victoria

 

Ray

Mindless's picture

Queenslander

We grow the Cane for Bundy Rum where all the Hillbillys build their Guns,,,

Mats's picture

Multifilament muscles

Air Muscles have been around for a while. Latest experiments use thinner air muscles, but many in parallell, like spagetthi. 

https://robomechjournal.springeropen.com/articles/10.1186/s40648-016-0061-3

 

kyle.clinton's picture

Very Cool Air Muscles

I have always thought this would be an interesting thing to test... Maybe Junior 5.0 will have Air Muscles... 

Ray.Edgley's picture

Way Cool

These are a cool muscle.

The down side:

  • You need to use them in pairs as they only pull
  • The control vales are around $177 each putting out of the reach of most hobiest.

On the up side:

  • The more tubes you add in each muscle group the stronger the group is
  • They have a better shock absorbing ability, great for legs