As I have mainly finished the mechanical contruction for Android 9 I thought I'd start to look at making it dynamically stable and document some basic testing along with my own thoughts / methods for making it work.

I have no ankle motors for leaning sideways in the android so mechanically it will rely on end-stops at the ankles to stop it falling too far sideways. However, as it builds up momentum from leaning side-to-side in quick sucsession it will still be able to fall over. I'll be using cheap off the shelf gyro(s) for this project that are designed for use with R/C helecopters and the like. The aim will be to make it lean side to side in order to walk so it will have to take it's weight completely off one foot, but without tipping too far the other way. It will have to do this quickly so that it's gait flows, rather than stopping stationary at each extreme as with Android 3 which locked it's ankles in place to stand on one leg.








So far, I've planned for one gyro in the body to act as a kind of 'safety switch' that will modify the target positions of the hip motors along with the timing between leaning right-to-left and left-to-right. I attempted to draw the process in this rather large flowchart:



I've ordered one GWS PG03 gyro and some picaxe chips to control the whole thing which will need some basic testing so I can get things just right. I'll put all the progress/testing here as things arrive or any other bright ideas I have...

Further thoughts 20/05/06

Ideally the android would stop it's hip motors when it reaches a limit detected by the gyro and at this point it would start leaning back the other way (like a two wheeled balancing robot / Segway scooter). However, as I have only one gyro, but two leg motors, it will be hard to keep the legs the right distance apart as they will never actually reach their target positions. To achieve this I think I'd need another two gyros - one in each leg... then the legs could lean until they were both at the right angle. So to get around this (as shown in the flow chart above), if leaning left exceeds it's 'safe angle' then it will lean right less to kill the momentum and keep it stable as well as pausing for a bit to let gravity pull it back on centre before the motors turn the other way.

I suppose this is kind of the inverse to a two wheeled balancing robot / Segway scooter, because something on two wheels tends to fall over in either direction as gravity pulls it. This android tends to stand up in the centre rather than fall in each direction, what I need to achieve is getting it to 'fall' in either direction but not too far.

It's also worth mentioning that in this picture when I was testing a while ago, the hip and ankle joints are at their extremes. This allows the android to statically balance on one foot. i.e. it's not in motion, just stood still even though the ankle joint has no motor - the joint is resting against its end stop on it's right foot as the weight is over to this side enough to hold it there.



When I get to deciding the target positions for leaning left and right they will be no where near the extremes. The momentum it builds up from leaning side-to-side in quick sucsession will be enough to move the weight off each foot with much smaller movements.

The flow chart above only lays out the process for leaning side-to-side but not actually walking. Once it can dynamically shift it's weight then I'll be adding some 'trigger' outputs to the main picaxe microcontroller which will in turn set off independant program loops on two other picaxes, one to control each set of leg motors to make them move to the correct positions at the correct time during the main loop from the flow chart above. This should make it locomote... small steps to start with though.

Here's a block diagram of the main electronics layout:



It's centred around the three picaxes as described above. I'm planning to have a common RS232 control bus that goes to the input of them all to trigger different program loops on each, as well as other controllers such as those for the arm motors. 'Picaxe 1' will run the main dynamic stabilty loop so this will also be able to output to the RS232 bus to trigger the other two picaxes which in turn control the leg motors. Picaxe 1 will also read the gyro data.

24/05/06

Today I received the parts including the gyro. I have one GWS-PG03 gyro and 3 picaxe-18 'high power' project boards:



I tested the gyro with a standard R/C servo and an RS232 servo controller board to output a constant signal that tells the servo to centre. The gyro modifies the signal as you tilt it and the servo moves. However, if the gyro is stationary, the servo centres again... basically the signal only gets modified if the gyro moves at a certain speed, if you move it slowly the servo stays still. The input and output are PWM signals that R/C servos use as their positioning signal so this can easily be generated and read by picaxe microcontrollers.

I made a short low quality video of the gyro and a servo moving, you can see that the servo only moves if the gyro is moved and a certain speed, too slowly and not much happens... but, it always centers when the gyro is stationary. It's a WMV video I'm afraid until a encode a DivX format version (not much to miss if you can't play it):

gyro001.wmv - 1.00Mb - right click here and select 'Save Target As...'






So, although my first flowchart above assumed the gyro would output a contant signal in relation to it's angle, I can still use the gyro, but I'll need to interface it to another picaxe which simply brings an output high for around 100ms (0.1 seconds) in the event that the gyro signal goes outside 'safe' limits for the android. This way the main picaxe actually running the dynamically stable program loop will read that output on at least one cycle where it checks the gyro. Otherwise there is a danger that the android would lean to far but the raw gyro output would get read by the picaxe whilst the gyro was stationary.

First methodology

This may seem a bit confusing and I only just worked it all out myself. So my approach will be:

1) Build up one picaxe-18 project board to read the hip position feedback pots and switch the motors. This will be programmed to send the motors to target positions - leaning left and right in turn, with a fixed time delay between each, and fixed hip positions. It will be set up through trial and error to get a rough idea what sort of numbers we need and to get a feel for the dynamics of the android in motion.

2) A seperate picaxe 08M (or something) will be used to generate a fixed servo 'centre' signal. This will be fed into the gyro.

3) Another picaxe-18 will be used to read the gyro data and turn on an LED for 100ms if it goes too far off centre whilst the android is leaning/rocking from side to side as per step 1). This circuit will be mounted at a fixed position inside the android.

4) Once I can see that the gyro 'warning' light comes on when the android leans too far, I'll connect this output to the input of the picaxe responsible for controlling the timing and motors. Then I'll implement my first flowchart so that when the gyro 'warning' trigger is recieved, it does something to the program variables and pauses the motion to kill the momentum... again through trial and error.

5) If this proves sucsessful then I'll consider sending a value from the picaxe directly connected to the gyro to the picaxe controlling the motors and timers. This value will represent the peak amount that the gyro excedded its 'safe' limit so that program variables for timing and motor positions can be modifed on a granular scale.

Second methodology

I had some other thoughts about uses for the gyro driven from the experience I had from Android 6 (also see the testing videos of it rocking from side to side). I considered that the gyro would have been useful here using the following process:



The basic stages are:

-Bend one leg, this of course makes the android tip over as one leg is shorter than the other.

-Wait until the gyro says you've tipped far enough.

-Straighten that leg again and bend the hips to lean the body the opposite way... bringing it back on balance.

-Wait until the gyro says you are straight enough.

-Bend the hips back to the centre.

-Bend the other leg to tip the other way... etc....

That should be pretty easy to implement and because the hips always get back to the centre position on each cycle you always have a reference from which to base their movement.

Locomotion

Obviously both these methods only make the android walk on the spot so extra program loops are required to move the legs to the right positions, hence my other two picaxe boards.

29/05/06

I have now built the following bits of electronics...

The board with two picaxes on. A Picaxe-08M generates a 'centre' servo signal signal which is fed into the gyro. The another picaxe-18 reads the pulse width of the signal on one of it's inputs. At the moment it lights an LED for 200ms if the signal deviates outside contraints which are coded into it's program. This board is built into the bottom of the body although I may move it higher up depending on how the testing goes:



Two relay boards. These are fitted in each leg and switch the hip motors. I used relays because unlike solid state drivers it's hard to burn them out unless you do something really stupid:



I've been testing with an old PC power supply which does 25A at 5V which is good for the motors, but sometimes it still trips out - don't think it likes the spikey load... might try batteries next. I'm loading it with a lightbulb to make it turn on but it's not the best arrangement really. I've also got another mains PSU to power the logic that's seperate from the motor PSU:



I fitted some pots to the hip motors which are coupled directly to the gearbox output shafts. These read the position of the motors and therefore the hips, there is one on each side:



Picaxe re-planning

I started to program one Picaxe-18 on a 'high power' development board from tech-supplies.co.uk. As per my original plan, this was to read the position of both hip feedback pots and switch all four relays to control both hip motors. The positions were to be hardcoded into the program and it would simply switch the motors in either direction one way and then the other after a short pause, stopping them at the target postions.

However, I found that as well as running out of programming space as I only had straight picaxe-18's instead of the 18-X (which has 6x the program space)... I had problems with the speed of the ADC reading (I thought) to read in the values of the feedback pots. Because the program had to check each pot/ADC in turn and then call a sub for either turning the motor in either direction, or stopping it, I ended up with a massive loop of nested subs and various return points which meant that the motor far over-ran it's desired position due to the delay in switching it off.

So, I used one Picaxe per motor in an attempt to speed things up. This wasn't much better but in the end I managed to alter the code so there were less subroutines and this seemed to fix the problem. The pseudo code is approximately along these lines:

Original code:

-readADC
-if >= target postion then sub to stop
-if < target postion then sub to turn
-start again

Both subs send the program back to the top again to read the ADC when they are done.

Modified code (and v.quicker):

-readADC
-if < target postion then sub to turn
-else...program line to stop
-start again

...Only using one sub which sends the program back to the top when it's done. For some reason this is much quicker... but I'm not sure why because the only difference is taking one subroutine away that only gets called when the motors are ready to stop anyway and putting the code from it in the main program loop.

Anyway, now it's really quick and the motors are much easier to control. If I went back to one Picaxe reading two ADCs and switching both motors it would probably be ok, so this is what I'll do for the two legs motors in each leg. However, I got thinking about how to control everything with the gyro so I decided to use the Picaxe that the gyro is linked to for timing control between leaning left and right, keeping one Picaxe per hip motor. So my new control layout is like this:



Here are the two Picaxe boards in the android along with the (green) pots that can be seen on each hip:



At the moment I have high/low inputs on each hip Picaxe controller so I can take an input high and it leans left... then another high and it leans back right again. The Picaxe with the gyro connected will trigger these lines when it's happy that the android can lean back the other way without falling over. The left and right hip postions will remain hardcoded for now so as per the original plan the gyro data/master Picaxe will just insert a delay between left/right leaning to kill the momentum.

Next stages are:

-build a platform inside for all those picaxe boards.
-get some batteries to power it and fit them somewhere (in the legs?)
-buy another Picaxe-18 high power board as I'm now one short.
-buy some Picaxe-18X parts, although my hip code now fits inside the standard 18 I can see that the 'gyro interface' picaxe may run out of space... shame as I have lots of 18s spare.
-get my Pcaxe-40X back from Mr Stick Legs and attach the I/R remote control kit I bought a while ago so I can build the 'master-master' controller and trigger it with the remote... this will trigger the 'gyro-master-Picaxe' with RS232 for different functions - just one called 'go' for now that makes it go.
-Think more about the relation between gyro output and time delay between leaning left and right. I think if the gyro says it's value is outside limits it just waits until it's within limits before leaning back... more testing to do really.

04/06/06

One of the leg mechanisms got jammed (my fault) and stripped its gearbox as well as snapping the feedback pot shaft - so no question the motors and gearboxes are up to the job. While I'm waiting for a new one to arrive I've sorted a few things out.

I've got hold of some batteries to power the android. It now runs from 4x NiCad D cells wired as two series pairs in parallel to give 2.4v at a total of 11Ah - as each battery is 5.5Ah at 1.2v. This seems to run the motors as just the right speed. I've also used a PP9 'latern batery' which is 9v to power the electronics - regulated down to 5v for the Picaxes and left at 9v to power the relays which are 12v but seem to work ok. I taped the batteries together to make one 'pack':



They now sit in the base of the android body and I've built a kind of platform above to hold some of the electronics:



Here are the three boards on the platform, clipped on with some plastic pegs/clips for now:



Testing is going ok for now, (check out my Blog). I have some parts on order that will arrive early this week so I should have some action out of it shortly. It basically works ok but the one gearbox sometimes clicks and free wheels so it's a bit unstable at the moment.

07/06/05

I've now added a remote control to the android. There's an an infra-red receiver attached to a Picaxe-40X project board, this board will be the central control / 'master-master' controller picaxe... more on that later. The Picaxe can read Sony remote codes so the handset is one of those 'universal' ones programmed to be Sony:



The replcement gear box arrived so I have both legs working relaibly and the android can lean back and forth (sideways), using the gyro to tell it when it's safe to lean back the other way without over balancing. The legs move to fixed positions left and right every 800ms (0.8 seconds), if the gyro says there is too much 'tip' then it waits another 50ms and waits again... then again... etc, until the body is stable and the gyro reads 'upright'. This reading also occurs when there's no momentum/sideways 'force' on the android whilst it's moving and the gyro thinks is stationary. So this, I think, is the Zero Moment Point (ZMP).

I've made a short video of the android in both WMV and DivX format. Basically is does three cycles of leaning back and forth 8 times each (or something). After each cycle I hit the remote again so they all blend into one but I missed the timing once so it kind of 'relaxes' about two thirds of the way through... the rest of the time it keeps moving and it's pretty stable.

android09-001DivX.avi - 6.04Mb - right click here and select 'Save Target As...'





android09-001.wmv - 4.61Mb - right click here and select 'Save Target As...'






16/06/06

Minor update today, really just testing my new digital camera which has a 2cm macro (that's 1 inch-ish) so the close detail shots should be a lot better from now on. Started work on getting the leg motors working and the first job was to fit the feedback pots to the motors. For and hip feedback pots I basically bodged them on there, so for these I decided to do a proper job. I drilled holes in the end of the pot shafts about 4mm diameter and as deep as the whole shaft:



These push-fit perfectly onto the motor shafts. I also drilled a hole through the pot shafts to fit the existing split pins that hold the arms on that come with the motors (they're a bit like servo 'horns' as supplied):



Each motor is mounted on a bit of card (same that I made the whole android out of). Even though it's card it's quite strong but still flexes if the motor doesn't quite turn on center so nothing gets damaged:



So now I have four pots fitted to the inside of the legs for the four leg motors:



Quite a lot of detail for fitting pots but as I say - just testing the camera. Next will be the construction of 4 more relay boards and fitting the two picaxe-18 boards to control the leg motors. I can already see by pushing the legs manually on each step (as there's some slack) that it will walk ok at least with small steps. Hopefuly due to it's light weight construction it will do quite well.