GELway - Self Balancing Robot with Self Reset

[gloomyandy]

Hi,
That is looking pretty cool! Did you have to re-tune the PID values to handle carrying the objects?

All the best

Andy

PS Have you tried running the robot autonomously? How well does it work then?

[iWitzand]

Hey Andy,

I have since fine tuned the PID parameters a little. I finally got a Simulink model up and running, which allows me to play with the values a little. But in answer to your quesiton, the programming hasn't changed to balance the objects.

My understanding of two wheeled balancing robots is that they shift the CoG over the wheels at all times, this is why when my robot travels up slopes it still remains upright. This is why when heavy weights are carried the robot leans back to counter the forward weight. Its a pretty intuitive control system, I must say I was very impressed at the weights it could carry.

As for autonomous control, I am just getting into that stage now, so no news to report as of yet. I will keep you posted, I think it may be a little tricky, but I'm always up for a challenge.

Steve

[gloomyandy]

Hi,
Yes that's how I understand that things work with balancing robots, but I was curious to see if it actually worked in practice!

As to autonomous mode, I'll be interested to see how you get on. I tried to do this (but not very hard!), but found that there was interaction between rotation and balancing, which seemed to make things rather tricky. I didn't try remote control of the robot, but I suspect that having a human in the loop makes it easier to fix that sort of thing!

All the best

Andy

[kirkpthompson]

Hi Witzand. NIce!

Can you share your GyroscopeSensor class source? I am interested in your implementation of gyro.getAngleVelocity(); and gyro.getAngle(); .

Best,
-K

[iWitzand]

Hey K,

This is a modified version of the guys that made Marvin the balancing robot. I have added in a method called CalcOffset, which will calculate the offset of any HiTechnic gyro sensor.

The getAngle method can be trickty, and really only works if you call it frequently, which is fine when you have a balancing robot constantly reading the gyro sensor. Hope this helps,

Witz

Code: Select all

Code Removed


[iWitzand]

Hey everyone,

Just a bit of explanation into why I have removed the code from my previous posts.

Since I am conducting my thesis through a university it is a bit unwise to release my code before I submit it. This is because there are complications with plagiarism, specially if my code starts poping up everywhere, not that I would think anyone would start releasing my code.

Anyway it isn't much longer to wait till November 2nd, where I am sure I can release my years work. So just sorry in advance, and hope everyone doesn't mind,

Steve

[sabinehaag]

Hey iWitzand,

very impressive videos!

Sadly I missed to see your code! Maybe you would share your code anyway via PM?! Of course I will not release it, but would like to get some further ideas how to balance it (get rid of the offset) or move it forward / backward.

Or maybe you could give me some hints. First I have to explain you how I did it.

- the NXT lies and the motors run (lower voltage to the gyro -> different value?) and I measure the value of the gyro over a period of time and build an average.
- offset of gyro is set (with previously measured offset)
- constant is set, which calculates the difference to the offset (offset is an integer, but measurements gives me an average like 598.3, with the .3 being an error which could not be set as offset for the gyro
- integrating the angle rate over time to calculate the angle (also using the constant, which includes the error besides the offset)
- PID controller with angle influencing the P and I part and with angle rate influencing the D part
- NXT would balance a short time

PROBLEMS:
- anyway, there is still an error in the gyro (somehow measures sometimes one degree per second wrong), such that an error accumulates over time
- the robot would fall over after a few seconds
- to overcome this problem the motor encoder values have an influence on the angle (when there is an error in the angle, the robot moves instead of standing in the place; the bigger the motor encoder values, the more they influence the angle)
- this works very well, when not letting the NXT move
- if I let the NXT move, the encoders of course increase and influence the angle -> bad; if the encoders have no influence anymore, robot will fall after a few seconds driving -> bad

HELP:
- does your gyro (after setting the offset) provide good enough values to calculate the angle correct over a longer period of time? if not, how did you overcome this problem?
- as you see, since I use the motor encoder values, I cannot just influence the offset to let the robot move. Any other ideas?

Best regards

[kirkpthompson]

Hi. I have found that the gyro nominal bias (offset) drifts over time (probably due to heat?) so I look at the bias continuously and reset it to current val if I have 100 samples +-x (means not moving or at least if moving, at a very steady rate which is not likely with mechanical vibration of your robot)

Here is a code snippet:

Code: Select all

                // if the reading/sensor average is close to the bias baseline, get mins & maxes and new bias value if stationary.
                // This method allows the bias value to automatically "change" when the sensor heats up, gets humid, etc. which causes
                // the nominal "zero range" to drift.
                if (checkCloseness(GyroDataStruct.rawVal, sensorBiasRoot, 1 * INTSCALER)) {
                    if (GyroDataStruct.rawVal < tempMinBias) tempMinBias = GyroDataStruct.rawVal;
                    if (GyroDataStruct.rawVal > tempMaxBias) tempMaxBias = GyroDataStruct.rawVal;
                    biasHit++;
                    // if we have 100 consecutive close vals, we assume we are stationary
                    if (biasHit>100) {
                        minBias = tempMinBias;
                        tempMinBias = MINMAXEXTREME;
                        maxBias = tempMaxBias;
                        tempMaxBias = -MINMAXEXTREME;
                        sensorBias = (minBias + maxBias) / 2;
                        sensorBiasRoot = sensorBias;
                        biasHit = 0;
                    }
                } else {
                    biasHit = 0;
                    if ((GyroDataStruct.rawVal > maxBias + NOISEFILTEROFFSET) ||
                       (GyroDataStruct.rawVal < minBias - NOISEFILTEROFFSET)) {
//                    if ((GyroDataStruct.rawVal > maxBias) || (GyroDataStruct.rawVal < minBias)) {
                        integralVectorAccumulator += (GyroDataStruct.rawVal - sensorBias) * GyroDataStruct.cycleTime;
                    }
                }

[iWitzand]

I think the problem you are experiencing with the gyro is commonly known as gyro drift. I attemted to account with this using a recursive filter but wasn't very effective. However it wasn't too big a deal for me, and all I really notice is if I leave the robot on for like 20mins, it will gradually move forward. Here is an image of the data logging I did on my gyro.



One thing to note is that you are using an average for your gyro, I rounded my value, since the gyro only reads whole integers anyway, a small thing.

Another way to account for gyro drift is with an accelerometer/tilt sensor. However Andy (gloomyandy) is your man for that. He built a balancing robot too, and used a homebuilt tilt sensor and gyro to account for the drift.

The problem with your gyro may be different however, since you say it falls over -> bad. I imagine it may be a problem with the way you have written your getAngle() method.

My angle method works like this

Code: Select all

public double getAngle()
{
now = current time
deltaT = now - lastTime

    if(deltaT != now) {
      angle += getAngleVelocity() * ((double)delta_t / 1000.0);
    }
    // Note that getAngleVelocity() is the velocity minus the offset

lastTime = now
return angle
}


As for my gyro sensor readings over time, best seen in a plot. Note that in my PID controller I used gyro angle, gyro velocity, motor angle and motor velocity. All these values are combined and passed through the PID controller.



Your next problem I think was moving the robot. You will notice that my robot's average power sent to the motors is approximately zero i.e. it is staying still. Well to move forward I provide an average power to the motors which is greater then zero vise verse for backwards. I do this by offsetting the gyro angle that is being read in. Note that this has to be applied in gradually over time to move forward, if you apply too large a number instantly its like punching the robot in the face -> bad.
Also once you stop applying the offset the robot should start balancing in a stationary position again, since it is the nature of the PID controller to remove the disturbance. Here is a plot of my movements



If your a little confused with the -ve slope making the robot move forwards its cos I originally had the signs wrong, I've since fixed it but haven't updated the image yet.

I hope this helps a bit, if not, try http://wiki.aasimon.org/?id=marvin:marvin, this is the robot that I have built from. My Balance Control systems works similar to theirs, but have made my own modifications. I found their documentation a bit hard to follow,

Steve

[sabinehaag]

Thanks for your answers, I will try to improve my code as soon as I find time to do so!

[burti]

- Able to be driven by mobile phone (I have edited an existing Java Bluetooth mobile application, so that it sends integers to the NXT).

Do you use J2ME on your mobile phone?
I ask because I made a nasty experience with Nokia N95 8GB trying to commicate with a nxt brick. (I wanted to use my mobile phone as a remote control for a nxt car.)
You can connect both with each other but if you want to exchange some information my nokia mobile phone was always buffering everything. Flushing was not possible. So you had to break the connection just to force the buffer to be flushed and the information be transmitted. I haven't found a way through it.
I wanted to try to program the remote control in symbian c++ instead of j2me but I haven't found time for that yet. Which moble phone model do you use ? Have you faced the same problem too ? If so how did you solve it?

[lawrie]

I have no problem communicating with the NXT with my Nokia N95. Could your problem be something to do with the NXTComm mode you are using? By default the NXT works in packet mode with headers on each packet of data sent and received but it can work in raw mode and omit these headers. The NXTReceive sample allows you to select the mode.

There are sample J2ME applications in the j2mecomms and j2mesamples projects in SVN. We have not released these yet as they currently require too much work to keep them in step with new leJOS releases. There is a remote control sample that drives a NXT and takes sensor readings, and a sample that is equivalent to BTSend or BTConnectTest. These work fine with My Nokia N95.

[iWitzand]

Hello,
In regards to the phone I have had no problems at all with communications. I used a program called NXTSymbian that I found from the net and modified it to send integers to the NXT instead of byte commands. The phone I am using is a Nokia 6220 with Symbian on it. Although the install file is a .jar.

This is the website for mobile phone connections,

http://nxt-symbian.sourceforge.net/

The code isn't very well documented but I taught myself what was going, didn't take too long, and I used the mobile phone compiler that he suggested.

Make sure on the NXT that when you set up your Bluetooth connection change the input/output mode to RAW, since the mobile phone will most likely not be usign leJOS class files. That is,

Code: Select all

//BTConnection conn = Bluetooth.waitForConnection();
   //conn.setIOMode(0);                 // Used when a pc connection is made
   //conn.setIOMode(NXTConnection.RAW);   // Used when a phone connection is made

This is what lawrie is suggesting you check. If you need anymore help don't hestitate to ask. I will get back as soon as I can, thesis is due in soon so it's getting a little hectic =).

Steve

[iWitzand]

Hey Everyone,

Haven't done a great deal in the way of videos or anything like that lately since it is all coming to an end. Only

It is 28 days, 17 hours, 26 minutes and 19 seconds until Monday, 2 November =)

Anyway, I made up this little montage of my robot, even rocky had a montage. I am presenting my years work in 2 days, only have 15 minutes to do it, 5 mins of question time. So I made this video to run during question time, hopefully it will distract the audience from asking to hard a questions .

Here it is,

http://www.youtube.com/watch?v=M_0iLQdo1Ck

Steve

[Atr]

So, did you receive your degree?