22 January 2015

A Two Wheel Balancer

OK, It's a bit different from my main humanoid biped project, but it does use a lot of the hardware and some of the software I will eventually use in my biped. Plus I had all the bits I needed to make it while I wait for some more powerful servos to arrive for the biped.

There must be more than 100 examples of two wheel balancing robots on the internet (just check google), so the temptation to "copy and paste" can be quite high, but you can only learn so much by running someone else's code on someone else's hardware, so I did some research and started almost from scratch.

The Hardware


Balancer wheel fitted to servo on plywood chassis
Balancer wheel fitted to servo on plywood chassis
Chassis is 3mm plywood
Wheels are 75 mm model aircraft wheels
Motors are Futaba FPS148 Servos modified to rotate continuously.
Controller is Raspberry Pi B+ running Raspian
Sensor is MPU6050 6 axis (3 gyro + 3 accelerometer)
Power 2x 18650 Lithium Ion Cells (7.2v)
The battery voltage is regulated using a cheap 3A switch mode buck regulator from eBay.

The software


All written in python (if you want the source code send me a message) I wont post it on-line to help others resist the temptation to "copy and paste".

Balancer Wheel with servo horn and mounting hardware
Balancer Wheel with servo horn and mounting hardware
Pseudo code:

Start.
Get tilt angle from sensor
feed data into control algorithm
set wheel speed based on output of control algorithm
Goto Start
I'm a big fan of keeping things simple, but as I quickly found out whilst developing the balancer you can go too far and too simple just doesn't work!

Making the Chassis simple did work, making the software simple didn't.

After a little testing I soon discovered that accelerometer data from the MPU-6050 is just too noisy to use for control, especially when the control loop gain is turned up and the robot is oscillating quite rapidly. The solution to this problem is quite clever and as it turns out, quite simple too. You need to use all of the sensor data, and not just a single axis of accelerometer data as I had originally tried to do. The data from the accelerometer and the gyro needs to be combined or fused using a filter. I wont go into the details as others have covered this already, but basically the filter uses the gyro data to determine tilt angle and the accelerometer data to reduce (eliminate?) the gyro drift.

Having implemented this 'Complementary' filter the balancer was instantly more stable, even managing to stutter around the floor for a few seconds and able to withstand a push or two without falling.

**Pic of balancer balancing here**

Success! Well, partial success... I still need to fine tune the controller constants to improve the stability some more, and probably get some bigger wheels to allow the balancer to recover from bigger excursions from upright.


I also need to look into a secondary control loop that will prevent the balancer from creeping forward or backwards and also allow me to control it so that it can be driven around.







Biped Ankle Development and Testing

It feels like I'm taking two steps forward and one step back at every stage of this project (no pun intended). Probably due to my lack of 3D CAD and 3D mechanical modelling software, but it's more fun to build than to model, even if it takes a bit longer, so that's what I'm doing.

My original biped was going to be a micro sized robot (about 30 cm tall), but early servo testing soon put the brakes on that idea. The current design should be about 60 cm tall and will use standard sized servos. Cheap Tower Pro MG 996R servos to be precise. The robot height may have doubled, but the budget hasn't. I also made a decision to avoid the temptation to use the servos as pivots like so many simple biped robots seem to do. I made that decision for several reasons:
  1. I want to design and build a unique robot, not make a copy of a robot 1000 other people have.
  2. Using the servo as a pivot reduces the usable range (and therefore precision) of the servo. e.g. in an ankle that might need to move +/- 45 degrees a servo that can move +/-90 degrees will only be using half of its available range and precision.
  3. By using appropriately sized gears or servo horns, push-rods and levers to connect the servo to the joint I can take advantage of the servo's full range of motion and precision . This will also have the added benefit of increasing the available torque at the joint if the joint needs to move less than the servo.
  4. Using levers or gears to scale down the output of the servo will also scale down the dead band by the same proportion. This is a very important factor if you are using cheap servos like I am. I know from my early testing that the MG996R's have a massive dead band (between 5 and 10 degrees) so anything that can be done to reduce it is very welcome.
One disadvantage of using levers or gears to take advantage of the servos full range of motion is that the speed at which the joint moves will be reduced as the ratio between the servo movement and joint movement increases. When operated at 5 volts the MG996R servos will rotate 60 degrees in just under 0.2 seconds (no load), which is equal to 0.6 seconds for 180 degrees (the maximum travel I've seen the MG996R's perform reliably). So if I use the servos full output range it would take 0.6 seconds for a join to travel through its full range even if that was only 30 degrees. If that turns out to be too slow I can always adjust the servo limits (possibly only use +/- 120 degrees to reduce the travel time to 0.4 seconds) and then adjust the servo horns and levers etc until I find a good compromise between speed and torque / precision.
Anyway, enough words, here is my biped ankle prototype:



I should re-iterate that this is only a proof of concept mock up. The final version will have quite a few enhancements including significantly stiffer push-rods and screws to hold the servo horns on! The whole foot will also be rotated 180 degrees so that the push-rods are at the back of the leg and not the front. It will also have the push-rods connected to the foot at the correct angle and distance from the pivot! [I was playing with calculations for the knee joint at the same time and ended up using the knee calculations on the ankle so the connections are approx 45 degrees from the pivot instead of being level with the pivot as they should be. That's what you get for doing stuff like this at 2am]

You can see from the picture that I have two active degrees of freedom (DOF) in the ankle and two servos to operate them. I could have arranged them traditionally so that each servo controlled a single DOF, but that would have made the lower leg less compact because the servos would have needed to have been positioned at 90 degrees to each other so that the output shafts were in the right place relative to the foot and the pivots.

By placing the servos next to each other I've managed to keep the leg relatively slim (60 mm wide) as well as keeping the construction relatively simple using a combination of cheap robot brackets from eBay and a few of my own fabricated brackets/plates. The dis-advantage to this arrangement is that the software / firmware used to control the ankle will be a little more complex but that shouldn't be too much of a problem.

Now I've proven the concept I will fine tune the design and then start work on the hips and knees.

02 December 2014

Servo Testing - Tower Pro SG92R

I wanted my biped to be as small as possible whilst stil having around 30 Degrees of Freedom (DOF) so I decided to get some high torque micro servos. Specifically the Tower Pro SG92R 9 gram servo.
They are advertised as having between 1.4 kg.cm and 2.5 kg.cm of torque. Ignoring the fact torque should be measured in Newtons and not Kilograms this value appeared to be enough (on paper anyway) to actuate most of my bipeds joints. I knew the actual usable range would be a little less, but I wasn't prepared for what I found when I tested a few.

This is by no means a scientific test, but my results may be of use to others considering these servos for their robotic or other projects.

The stall torque is, as I understand it, the maximum torque the servo can withstand or 'fight back against' when applied to the output arm. I should clarify that the servo must be powered up and receiving a good signal e.g. 1.5 ms pulse at 50 Hz.

In my test I had a 20 cm arm attached to the servo horn parallel with the table below. I hung a small bag of coins on the arm at 20 cm from the pivot and ran a small python script on my Raspberry Pi that cycled through several servo positions before returning to the start point.



I had hoped to get around 1.5 to 2 kg.cm of usable torque out of the little SG92R's, but sadly they did not live up to their chinese specs!

The only good thing about the tests is that all the servos I tested started to struggle at roughly the same point, so at least they are consistent.

From my tests I have concluded that the SG92R's:

  • Can hold against a torque of approximately 2 kg.cm. i.e. the stall torque is around 2 kg.cm. But they did sag about 15 degrees before holding the weight.
  • Have, have a 'usable' torque range of about 0.8 to 1.0 kg.cm. At that load they will move where commanded, although slowly, and will hold their position fairly accurately.
  • Will move fairy quickly and accurately with a load of about 0.4 to 0.5 kg.cm.


So, In conclusion, my 9 gram SG92R Servos are only really useful up to about 0.8 kg.cm and that is the absolute limit, I probably wouldn't want to use them above 0.4 kg.cm to be honest.

Unfortunately I can't build my biped light enough to use the SG92R's except in a few lower torque joints, so I ordered some bigger and stronger servos. I'm hoping for slightly better results from those, especially with a quoted stall torque of between 10 kg.cm and 14 kg.cm.




18 November 2014

Introduction

Please excuse the rather random nature of the blog as it stands right now. I started this project a few weeks ago and I still need to add quite a lot of content before the blog is up to date. Until then I'll be dumping information here as and when I can.

Once I'm up to date posts should become a little more sequential and ordered.

Please bookmark, follow or whatever it is you do to a blog so that you can come back soon to see how my little biped is getting on.

Leg development and testing

I wanted to make this robot as small and light and cheap as possible so I opted for some very small and light micro (9 gram) servos (Tower Pro SG92R) to power the joints. Various on-line sources rate them from about 1.6 kg.cm to 2.5 kg.cm which is a lot for a tiny servo, but still a pretty modest figure to work with.

I had already thought one might not be enough for some of the joints like the hips, knees, ankles etc so I had an idea to double them up. Basically mount them base-to-base and use the output shafts as rotation pivots for the joints, but even with this doubled-up configuration I began to wonder if my robot was going to end up too heavy for the little servos so I had another re-think.

To get the most out of a servo we need to match it's full range of motion (180 deg in the case of these servos)  to the full range of the joint in question. A human knee might be able to rotate between about 0deg (standing upright) and maybe 170deg (kneeling down sitting on your heels), but to walk it only needs to rotate through about 60deg. So if I'm only using about 1/3rd of the rotational travel I'm effectively wasting 2/3rds by using them in this direct drive mode.

Time for another re-think.....

Two other option exist, levers, arms, pushrods...whatever you call them, they essentially link the servo output arm to the thing you want to move (in this example the lower leg). The trouble with this approach compared with the direct coupling method is that the torque is not distributed equally over the full range of travel **needs a pic to demonstrate**. It also has a rather interesting feature whereby the torque required to keep a system stable is effectively zero when the servo output arm is parallel with the push rod **needs a pic to demonstrate**, but on the down-side it can introduce slop into the system and the non-linear force issue is a big concern, especially since I may have to 'hold' the robot in a number of different positions and I would like the motion to be as smooth as possible.

One other thing I could do is to use gears (sometimes called cogs or sprockets). My idea is to mount one gear on the output shaft of the servo and one to the structure I need to move. By choosing the right size gears I will be able to match the rotational motion of the servo (180 deg) with the rotational motion of the joint (in this case about 60 deg).  In this example I would use a 20 tooth gear on the servo output and a 60 tooth gear on the structure. Also, because the force is always acting on a tangent it will always be maximised and on top of that i should get a 3:1 increase in torque by reducing the rotational angle by the same ratio with the gears.

I need to do some tests, but if I'm right I should be able to get a constant high(ish) torque out of these little servos after all.
 
I'll mock up some physical tests for the servos and various options described above and post my results as son as I can.

EDIT: I did some testing with the servos discussed above. See the post here: Tower Pro Servo Testing Unfortunately the little servos turned out to be pretty weak. So, for now at least, they're sitting in my servo box waiting for a light weight application to put them to good use.....