I am looking into making a self-balancing Arduino robot but am unsure whether it is feasible to rely on gyro sensor input alone and use a rough mathematical expression to increase/decrease the duty cycle of the PWM capable pins. The pins will be connected to a dual motor driver (dual h bridge too) driving two dc motors. I am also still choosing an Arduino controller so opinions on boards are welcome and much needed.
Thanks!
a gyro is not enough. u'll need something to tell tilt.
Actually, a gyro alone is sufficient to balance. That is how I do it and it works. There is a lot of misinformation circulating about needing a gyro plus an accelerometer. Simply not true.
Actually, a gyro alone is sufficient to balance.
I have trouble believing that, since it is mathematically impossible for a rate gyro to measure an absolute angle.
Have you posted the complete details of your project anywhere?
jremington:
I have trouble believing that, since it is mathematically impossible for a rate gyro to measure an absolute angle.Have you posted the complete details of your project anywhere?
To balance the robot does not need to know the absolute angle. It just needs to know if it is falling left or right in order to correct and stand upright.
Here is a slideshow I presented to non engineers. A knowledge of differential equations is necessary to make sense.
The link doesn't work for me.
However, to define "upright" requires knowing the direction of "down" and a rate gyro can't give you that.
jremington:
However, to define "upright" requires knowing the direction of "down" and a rate gyro can't give you that.
Upright is not falling. That is what happens with closed loop control. No need for the gyro to "give you that."
I have simulated all this in Mathematica. I have built it with Lego NXT and again with Arduino. All I can say is it works. Try this link.
The link to your slide show still does not work for me, even on the new page.
However, I looked at the presentation linked with the title "Ryo Watanabe's solution" and although too little information is given to completely evaluate the proposal, two independent measurements are used and are required for stability: the wheel angle (presumably measured by an encoder) and a rate gyro, to measure the angular velocity of the robot body.
So, in this case it vastly oversimplifies the situation to say that only a rate gyro is required.
One way of looking at Watanabe's solution is that the wheel rotational angle, by virtue of a frictional contact with ground, defines "horizontal", which is all you need to properly integrate the rate gyro output. In fact, Watanabe clearly states on slide #10, (in commenting on the approaches used by others):
Information on wheel’s rotation angle is NOT used ==> Internal Stability is NOT achieved
To further emphasize the problem of using a single gyro for a balancing robot: "falling" to the right and "rising" from the left cannot be distinguished from each other, given just a rate gyro.
jremington:
So, in this case it vastly oversimplifies the situation to say that only a rate gyro is required.
And yet, I can balance with only a gyro. Like I said initially, there is a lot of misinformation out there.
I should add that with only a gyro the gyro offset will cause the robot to drift slightly. But, it will be stable and upright. Wheel encoders are necessary only if you would like to automatically maintain a fixed position.
Well, add some information. You haven't convinced me.
Wheel encoders are necessary only if you would like to automatically maintain a fixed position.
Which is the point of a self balancing robot. Sorry, but you just aren't making any sense.
jremington:
Well, add some information. You haven't convinced me.
Which is the point of a self balancing robot. Sorry, but you just aren't making any sense.
The point to me is to balance, not maintain a fixed position. Even without nulling out the gyro offset the drift in position is no more than a foot in a minute. I think that's pretty good.
I am done.
I've not built one of these, but you might take a look at this page for reference. dpa is one of the grand old men of hobbyist robotics.
http://www.geology.smu.edu/dpa-www/robo/nbot/index.html
jremington:
You haven't convinced me.
I think he's convinced me.
Is there any advantage to the "gyro only" technique?
I agree using gyros only to show it can be done is certainly worthwhile but it sure seems like it would be more computationally expensive to use gyros only.
@jremington, I saved the pdf to my Dropbox. Can you access the file from there?
@charliesixpack, thanks for the information. Now that I think about it, gyro only balancing makes sense. It does seem like it would be the hard way of doing things (not that there's anything wrong with doing it the hard way).
I don't suppose you have video of any of your robots balancing?
oric_dan:
dpa is one of the grand old men of hobbyist robotics.
Agreed. Here's a video of a talk he gave a while back. I enjoyed watching it very much.
I notice David Anderson also uses both accelerometer and gyro.
charliesixpack:
Even without nulling out the gyro offset the drift in position is no more than a foot in a minute.
The drift doesn't increase with time?
Here is a video of my Arduino project. I don't see a particular advantage to using only a gyro other than the challenge and satisfaction of doing it. But then, challenge and satisfaction is the only reason I do this stuff.
There is no added complexity to the "gyro only" approach. The controller is a simple second order digital filter with only one input. The other approaches add either an encoder or an accelerometer giving you two inputs. The balancing is done with this one equation (THETAdot is the gyro reading, SIGMA is what controls the motors)...
// calculate the motor input for balancing
SIGMA[2] = AA1*THETAdot[1] + AA0*THETAdot[0] + BB1*SIGMA[1] + BB0*SIGMA[0] ;
I have attached the complete sketch. It is more complicated than it needs to be. I added an XBEE to capture the balancing data. It also has a remote control.
Segway.ino (6 KB)
@duane: thanks for posting the PDF. For some reason I could not access this on charliesixpack's site.
I see now that charliesixpack's technique should work, and it is more or less equivalent to Watanabe's approach. However, it requires careful and accurate modeling of the motor response, so that the wheel rotation angle can be estimated (roughly equivalent to using an encoder).
Knowledge of the wheel rotation angle in effect defines horizontal, so that the absolute tilt angle can be estimated from the tilt rate.
This is not something a typical Arduino user can hope to accomplish without a rather good math background, so I will continue to recommend that a gyro/accelerometer combination be used as the simplest possible, workable basis for a balancing robot.
charliesixpack:
I have attached the complete sketch.
Thanks for attaching the sketch. I haven't tried a balancing bot myself yet. It's interesting to learn there's another approach for a balancing bot.
jremington:
I see now that charliesixpack's technique should work, and it is more or less equivalent to Watanabe's approach. However, it requires careful and accurate modeling of the motor response, so that the wheel rotation angle can be estimated (roughly equivalent to using an encoder).Knowledge of the wheel rotation angle in effect defines horizontal, so that the absolute tilt angle can be estimated from the tilt rate.
I would say this is not true. Characterizing the motor and wheel only allows an estimate of the angular velocity of the wheel. I did a careful job of characterizing the pieces of the design so that I would not need any means to tune the controller in order to balance. As it happens, I came pretty close. I needed only to slightly tweak the delay() function that controls the loop sampling time to optimize the stability.
If I wanted to ensure the robot location did not drift I would still need wheel encoders. This is something I did with the Lego NXT version I built. The NXT has built in wheel encoders.
Your derivation of the equations of motion is based on the definition of wheel rotation angle beta, which is ultimately defined by assumption that the robot is standing/traveling on a perfectly horizontal surface.
Furthermore, if the robot is NOT on a horizontal surface, then the potential energy term would depend directly on the angle beta, a consideration that is missing from your derivation.
In any event, the success of the procedure rests entirely on finding the "magic numbers" in the following definitions (and in general they will be different for every different robot). Not a simple approach!
// define balancing filter constants
#define AA1 10.00 // can't name A constant A1 so use AA1
#define AA0 -9.9
#define BB1 2.0200 // feed backward gains
#define BB0 -1.0199
// define speed filter constants
#define CC1 1.100
#define CC0 -1.095
#define DD1 1.85
#define DD0 -0.85
jremington:
Your derivation of the equations of motion is based the definition of wheel rotation angle beta, which is ultimately defined by assumption that the robot is standing/traveling on a perfectly horizontal surface.In any event, the success of the procedure rests entirely on finding the "magic numbers" in the following definitions (and in general they will be different for every different robot). Not a simple process!
// define balancing filter constants
#define AA1 10.00 // can't name A constant A1 so use AA1
#define AA0 -9.9
#define BB1 2.0200 // feed backward gains
#define BB0 -1.0199
// define speed filter constants
#define CC1 1.100
#define CC0 -1.095
#define DD1 1.85
#define DD0 -0.85
The robot does OK going up inclines. The balancing coefficients are critical and will be different depending on the robot.
The speed filter is an attempt to make the robot more responsive to the remote control. The actual response is much more sluggish than the model predicts. The speed filter adds an initial impulse on top of the requested speed control to give the robot an initial budge. I had intended to use the robot to carry my golf clubs but the response isn't there to bring it out on the golf course. There is no need for a speed filter if there is a human rider on board controlling the forward motion.