nxt coming in balance

These movies look really funny:

• http://www.youtube.com/watch?v=b3vDnwwBmgQ
• http://www.youtube.com/watch?v=nJGy_oMSmWE (where is this last one gone?)
  

some movies are really fake like this:

• http://video.aol.com/video-detail/another-balancebot-lego-mindstorms-nxt/3625739070
  

Let us try to reproduce these things and learn something about balance and the sensors.

First the model: the nxt brick is upright, that means that the centre of mass is rather high up.
(Similar balance examples are this child game with the stick balancing on your nose, or the bike with one wheel...)

First observations:

• this must be done with a prog in the brick, bluetooth has a considerable lag
  
• the movie seems to use the light sensor, this is rather dependent on the surface...
  
• let us try lejos JAVA with the acceleration sensor i bought...

The movements should be short and not to far from equilibrium...

(In the picture two sensors can be seen: the lightsensor (used in the movies) and the tiltsensor. I was too naiv: sensors cost time, and the tiltsensor (I2C) above all....i continued with the wrong one: the tiltsensor....)



sensors:

• most movies use the lightsensor: strange, because in this setting only about three values are available, say -1, 0, 1 around equilibrium.
• (ok later on i found out that the JAVA "readvalue()" method gives only values between 0 and 100 (normalized) You have to use contrary to expectations: readNormalizedValue() which gives values between 0 ans 1023)
  
• the acceleration (tilt) sensor, using the x-angle, this gives a range of about 30 steps , 15 each side of equilibrium

motor methods:

• motor.A.forwards(speed) and backwards, steers 2 motors (A and B) at the same time
  
• motor.A.rotateTo(angle, true), this steers one motor, and the other lags behind!

First try: find equilibrium and then just drive in the opposite direction when needed:

if ( (senosrValue - midPoint) > 0 )
{
Motor.A.forward();
Motor.B.forward();
}
else
{
Motor.A.backward();
Motor.B.backward();
}

But this seems to brutal, there are four parameters involved:

• equilibrium
• driving time
• speed of driving
  
• waiting time, between the driving (waiting time??? please dont waist any time!!!)
  

The next thing to try is, make the speed a function of the measured angle
............hmmm doesn't work to well

Let's think: this is actually a reversed pendulum, and the acrobat on the one wheel bike is also in perpetual movement, she is not waiting to fall, and then reacting, could we try a balancing movement?

Then we have to find the time this this is swinging on.....
a long time ago Huygens mae his clocks and since then this is called the law of Huygens...

this means a swing time of about ...... 6/10 or a thread of 600 milliseconds, way to long.....
anyway also this experiment fails
the centre of mass could be moved higher up.
of course much depends on the model...

Nelleke proposed to make the robot self learning, but actually this is a 4 parameter space,

• equilibrium
• driving time
• waiting time
• force of driving

this as a minimum...

could he find his way in this space at random? (No of course not, this is 4 dimensional, easy to loose your way! Later on i reduced this space to : one! speed!)

what is the criterium to decide a good match?

I have tried to reduce the parameter space, and after that i could use an array for each amplitude around equilibrium and get the outcome decide to change this value, this didn't improve things much.

I tried to reduce the driving/waiting time altogehter, and only change backwards forwards when neccessary, so in case of going over to the other side of equilibrium. Using a few switches.
This seemed to improve things but not too enough.

Driving speeds: depends on battery level, but normally below 300 (Lejos value) is was too slow, i used values aroud 500.

Problems:

• the corrections are too brutal, it is impossible to stay close enough to equilibrium. When the angle of falling is too large, the NXT is too late to get itself upright. It should become more subtile and gracious in its movements!
  

For the moment this experiment failed!

Could we use the acceleration and not the angle, in the acceleration sensor?

//-----------------------------------------------------------------------------

This failure prompted a more detailed study of the sensors.
The accel sensors, as all the I2C sensors are considerably slower then the light sensor.
Also changing the speed in the motors has to be studied.
(Any difference using bluetooth - yes: back to lejos JAVA in the brick.)
Then an estimate can be made of the response time of the total system
them we can see if this response time is fast enough to do the balancing trick,- or not! In the brick the lightsensor is speedy, the limiting factor is now the reaction time of the motors.

//-----------------------------------------------------------------------------

Research on the sensors showed that the lightsensor is the fastest, and has to be used instead of the tiltsensor, which is I2C.
But also using the lightsensor in the readNormalizedValue() mode, it gives more accurate measurements then the readValue(). The only problem is these measurements are not symmetric: closer to the table and further from the table, the light is not linearly increasing/decreasing.
But only using a small middle range of floating motors and the quickest possible reaction of the motors at fixed speed of 600 gave a far better result then anything before.
It starts balancing!

//---------------------------------------------------------------------------------
Tried using bigger wheels, and went back to the smaller ones.
Introduced the angle for the motors, Motor.B.rotate(angleT, true).
Speed fixed, but is very important: 600 in Lejos JAVA.
Time consuming is configuring the average for the lightsensor. Each surface is different in reflection. Eventually I calibrated before letting it balance like this:

Sound.beep();
for(int x=0;x<10000;x++) equilib = (int)((equilib + tilt.readNormalizedValue())/2); Sound.beep();
//the beeps to indicate starting and ending calibration, the lightsensor is very fast!

then here what i used in the loop:

if ( Math.abs( myAverage) >5 ){
angleT = 15 + 15 * Math.abs(myAverage ); //angle varying for being out of balance
if ( myAverage < 5 )
{ Motor.B.rotate(angleT, true); Motor.A.rotate(angleT, true); }
else
{ Motor.B.rotate(-angleT, true); Motor.A.rotate(-angleT, true); }
} else
{ Motor.A.stop(); Motor.B.stop(); }

with a speed of 600 it started balancing for a second or so, and had still to be helped
example movie (really no fake!) But I could leave the supporting strips out now!

work in progress!