Loopy, it's good hear that you are still working on this. I've been focusing on the DCM method for now, and I haven't looked at the other methods. The DCM method seems very straight-forward to me. From my understanding it's basically just a simplification of a the complex expression that result from doing a 3D Euler rotation. If sin(x) is replaced by x, sin(x)*sin(y) is zero and cos(x) is one you get the rotation matrix that I showed in one of my earlier posts.
I hope to look at the other methods when I have time. I appreciate the information you have posted about them.
I found this one at McMastercarr on this page. Good news is is a perfect fit according to my digital calipers. Bad news, pack of 25. Group buy? That would satisfy six people at about 2 bucks a board, (plus shipping). I'll order if a few people show the want.
I order a bag of 25. Let me know if you need any, (via PM). Shipping should be minimal, First Class Mail.
Loopy, it's good hear that you are still working on this. I've been focusing on the DCM method for now, and I haven't looked at the other methods. The DCM method seems very straight-forward to me. From my understanding it's basically just a simplification of a the complex expression that result from doing a 3D Euler rotation. If sin(x) is replaced by x, sin(x)*sin(y) is zero and cos(x) is one you get the rotation matrix that I showed in one of my earlier posts.
I hope to look at the other methods when I have time. I appreciate the information you have posted about them.
Well, I had a brainwave to create an all Quaternion solution rather than have the Madjwick filters shift from Quaternion to DCM. So far, it seems that shifting over to DCM right after the sensor fusion is the most reasonable way to go.
Euler Angles are not worth using. They are 18th century maths for a 21st century technology. Ironically, Euler also created the maths for a rotational theorm that is used for Quaternions. (So one might get confused by seeing him references with Quaternions. http://en.wikipedia.org/wiki/Euler%27s_rotation_theorem.
One has to learn to visualize in a different way for Euler Angles, Direction Cosine Matrix, or Quaternions. But in addition to the ablity to visualize, one has to determine which optimizes the maths. It all is a bit surprising to actually have such variety in regards to rotation about X, Y, and Z, but the concepts are very subtle in their differences.
It actually seems less costly to convert from Quaternions to Direction Cosine Matrix and then do rotational adjustments for stabilty than to try to merge the two frames of reference with all Quaternions.
Jason, I tried the original code you posted, and it does work correctly.
No worries, and no apologies necessary. I was thinking about it more over the last couple days and figured it was probably your change to the order of the rotation values. If you change the order of those, *all* the places where the original order is assumed will need to change, so that'll include where the incremental rotation matrix is applied, the gravity vector, which vector you compute the cross products against when correcting the gravity vector, the correction rotation, and so on. It'll be a decent chunk of code to change, so it might be better to just document the original version well and get it working that way, and then change it while leaving the original implementation as reference.
When I wrote it, I started by doing all the coding in floating point in C#. First just the incremental rotation update, then I added in the gravity correction. Once that worked I converted the classes to fixed point, then I ported the fixed point code to the Prop. By doing it on the PC first, I had a reference version to compare my results against at every step, so it was easy to find mistakes when I made them. Much simpler to do this than debug on the Prop itself, especially given that there are so many places it could go wrong, and adding visualization code on the PC is pretty trivial.
I did a little bit more work on it this morning using your original version as the basis. I did decide to change the DCM code to align to the XYZ axes of the HoverFly board. The Prop Visualizer program makes it very easy to see if I'm doing the right thing. The changes for the gyro portion were straight forward, and I got that working the first time. The gravity vector changes took me a little longer, but I got it working also.
I'm just about ready to interface the code to a couple of servos that drive a gimballed rocket motor mount. I have the motor mount attached to a test stand for now. One problem I had was to figure out how to get the X and Y angles that I need to use to drive the servos. I initially came up with a fairly complicated way of deriving the angles because I have to account for rotations around the Z axis. I then realized I can just use the two matrix values that represent the Z component of the rotated X and Y axes. To get the precise angle I would need to do an arc sine, but I think I can avoid that since I'm working with a small angular range.
I'll try to take some video of it, and post it once I get it working.
I used ArcSin in the original code to extract out the angles you're talking about. It's possible to do it at 200hz if you're not doing much else in the loop, so it might still be workable for you.
Well, my other MARG unit arrived yesterday -- a GY-85 from Deal Extreme. They seemed to have split my order into four separate deliveries.
Direction Cosine Matrix is making sense to me for a balancing bot. I only need to keep track of the Pitch for balancing stability, so rotation measurements are only necessary about the Pitch axis. I can safely ignore Roll and Yaw activity. And it seems that mostly, I just need to know the direction of lean to react to, not much need for a precise scalar at this point. IOW, the 9DoF device will work, but it is going to be under-utilized.
The HoverFlyGimal Experimenters board makes a great input device for some sort of control or gaming. I mounted one in a small plastic case with a slot cut out for the USB. It seems possible to easily add at least 3 button inputs as well.
My other HoverFly is on the balancing bot, but I am a bit concerned that without encoders on the motors this is going to teeter a lot.
I am a bit concerned that without encoders on the motors this is going to teeter a lot.
I don't think this is a problem for simply balancing the thing.
In the usual analysis of the inverted pendulum problem that I have seen there is a model with a mass at the top, the pendulum bob as it were, and a mass at the bottom, the cart or at least wheels. In order to balance one has to move the base under the bob by applying a horizontal force to it.
That force translates to current in the motors driving the wheels, which basically translates to the PWM signal we send to the motor driver.
No wheel encoders required. Indeed there are many examples of balancing bots with no wheel encoders.
Now, if you want the bot to balance and also try to maintain its position on the ground then you need to know how far it has wondered from it's starting point. You might want to use wheel encoders for that estimation.
Offer for grommets from Posts 101, 123 are all gone.
This is what they look like:
They have a slightly greater ID than the HoverFly Open, but I don't think it matters since there is a 4-40 screw going in and doesn't contact the internal walls on the original..
I don't think this is a problem for simply balancing the thing.
In the usual analysis of the inverted pendulum problem that I have seen there is a model with a mass at the top, the pendulum bob as it were, and a mass at the bottom, the cart or at least wheels. In order to balance one has to move the base under the bob by applying a horizontal force to it.
That force translates to current in the motors driving the wheels, which basically translates to the PWM signal we send to the motor driver.
No wheel encoders required. Indeed there are many examples of balancing bots with no wheel encoders.
Now, if you want the bot to balance and also try to maintain its position on the ground then you need to know how far it has wondered from it's starting point. You might want to use wheel encoders for that estimation.
Well, eventually I desire a balancing bot that will handle sloped surfaces -- thus the need for gyros, etc. Iit still is all one axis. But the one axis project is merely a stepping stone toward two, and then three. I am already getting very curious about stabilized r/c flight as I have an electric glider that could use that.
Stability in this case is all about measuring the tilt and reversing it. The Direction Cosine Matrix pretty much does this by providing tilt data and then applying a Rotation Matrix for one select axis to do the opposite of what was given as output.
The Inverted Pendulum is an elegant presentation of the problem, but the reality is that you just have to keep moving the axle under the center of gravity. Not sure how much one has to thing about pendulums and reversing pendulums and so forth, just as long as the iterations don't let the device wander too far from upright.
Umm.. I am using an LM297 H-bridge to control the motors. Not too sure that PWM will come into play or not.
Accelerometers, gyros etc are just a means to an end here. What we want to know is how far from upright is the bot so that we can try and correct for it and stop it falling over. As shown above this can be done with simple light sensors and many other means.
Sloped surfaces make no difference. Except you have to do more work to move the base up hill than down, so knowing something about the slope might help. So far we have not discussed that.
I agree, the one dimensional balancing bot is a good stepping stone to other things like planes and quad copters.
Not sure how much one has to thing about pendulums and reversing pendulums and so forth,
Well I don't know. The inverted pendulum seems like a good model of what we want to do here. It tries to describe a mass on a stick standing above it's base. The inverted pendulum model at least explains why proportional control alone is not enough. The differential signal is also required.
Like all such mathematical models it may not perfectly describe the actual physical hardware you have but it's a good start.
The DCM thing says nothing about actually controlling the balance of your machine. It only helps in getting sensible data from your sensors. After all it has no idea if your machine is a balancing bot, a quad copter, a ship or a Saturn V.
I am using an LM297 H-bridge to control the motors. Not too sure that PWM will come into play or not.
The LM297 switches power to your motor. Full on or full off. Forwards or backwards. If you want more than stupid "bang-bang" control you are going to want to vary the power in a more analogue way. That is done by varying the pulse width. That is PWM.
@Heater
I can only handle so much of this intellectual debate nonsense. I simply reserve the right to study in my own way and to select projects that seem to help me do so. I want to learn, not to replicate without the kind of understanding that will empower me to be more creative.
Yes, you can use light or ultrasound sensors to have a two-wheel robot balance on flat surfaces; but in the real world of varied slopes -- a gyro with accelerometer is going to faithfully tell you how much tilt.... regardless of what the surface does. Those other sensors will not.
And when you add in PID for the motors to assure they don't run wild, you end up with an all-terrain balancing bot that can stand in one position on a slope, or do fancy maneuvers..
_______
I purchased the HoverFlyGimal to experiment, and the one-axis solution is just my way of applying the maths in the most limited context. I will get to 2D and 3D a bit later.
One of the Kalman filter's weaknesses is that it does sensor fusion for each axis separately; while Madgwick does all three axises at the same time.
Ironically, I suppose I could just use Kalman for the balancing bot and might even have a bit less code. But I decided to deploy Madgwick, then convert it to DCM, and finally use just one axis. If it works, I have the other data available for other purposes. I suppose using the Yaw to do tight 90 degree and 180 degree turns would be interesting.
+++++++
The main point is that I am not trying to replicate the cheapest balancing bot that was ever posted on the internet.
I am using the balancing bot as a means to expand my knowledge of IMU and MARG devices in a way that I might apply them to many different project scenarios... primarily as a stabilization device or a positioning device.
And I am trying to learn on the Propeller platform. Dave Hein has helped a lot with his code contributions expanding on Jason Dorie's original PropellerDCM.
So far, a lot has been learned.. far more than what I have reported here. Much of it has been about math topics that I fear would scare off many timid souls.
The Madjwick filter has math roots that go way back. One paper I have that uses the same gradient descent approach is for flight simulation that was written in 1981. I find it a bit curious that that Kalman got so entrenched in quad-copters and DIY drones as it seems people in aeronautics and aerospace have known Kalman to be inferior for many decades.
+++++++
Yes, I realize the LM297 is not really optimal. I tend to strongly dislike how hot it runs and would love a MOSfet H-bridge instead. But I figured that I'd learn more by trying with this and adding PWM; than by buying into a set up that does it all for me. There are robotic motors out their with built-in PID these days.
Regarding your link to the Berlin paper on Quaternions applied to spacecraft, I provided that link earlier and have read it a half-dozen times.
There are a lot of other links to to Quatnion Stabilization Algorhithm as applied to spacecraft, but the publishers want $$$ for copies of those articles. I may see if I can get an E.E. friend to get free copies via his university library. Those might lead the way to not having to use the Direction Cosine Matrix as an interim step.
I've been wanting to do a balance bot (or all ball balance bot) for quite a while. My thinking was that I'd use belt-driven stepper motors. You don't really need encoders or PWM as long as you have enough torque. Not as efficient as DC motors, but it'd be relatively simple to swap for a PWM / encoder setup once it was all working.
The direct driver steppers do seem to have several construction advantages.. you don't need belts and gears. There is space between the two motors to place an IMU if that is indeed the optimal location.
My dilemma is that I need to go shopping for the stepper motor controller. I already have a pair of steppers that fit direct drive wheels.
I guess in the back of my mind, I have wanted to explore encoders and PID as a second topic as well. But I seem to move along at a snail's pace with actual construction and coding. Right now, I have something built and I am trying to get the coding in order. After that, a rebuild of the balancing bot with more expensive hardware.
I filled my income tax last Monday for 2013, so that distraction has vanished until next year.
i just found some interesting link, do not know who make this.
It is a try to maVlink ground station qgroundcontrol
Take a look, cordic , quaternion for propeller ....
Ooops, sorry. My coworker gave me a printed copy of that paper that got mixed up with other printouts in the office days ago. I had forgoten where it came from so I googled it and recycled it back here.
I was not suggesting we abandon an IMU for other sensors. Or that we should throw out the MCU contol for two transistors. I mentioned them only to emphasise that a 9 DOF systems is probably overkill for simple balancing and that wheel encoders are not needed for that.
All depends what you want to do of course. For an all terrain, steering, navigating bot you may well need a lot more complexity.
I do agree, simply cloning a design, simple or otherwise, off the net is not so interesting. This thread has introduced me to a whole world of new and useful ideas. Starting from that quaternion thing... All good stuff even if I never get around to building a balancing bot.
I have moved on to reading and loading both Jason Dorie's code and Dave Hein's code in order to see if I can modify some of their work for the balancing robot. Not much to report there.
On the other hand, while the Berlin paper is informative on Quaternions, the really interesting stuff centers around the Gradient Descent Linear Regression.
The whole reason that Madjwick is superior to Kalman has to do with avoiding the Least Squares Linear Regression and using this powerful alternative. It just so happens that Gradients are a math concept that get expressed in Quaternion notation and so the sensor input fit by presuming the scalar will always be equivalent to a unit radius (that is why you see normalization calculations -- to convert the data to the concept of a unit radius equivalent).
Since the readings are taken at regular intervals, you end up with derivatives that migrate nicely into a first derivative matrix (called the Jacobian Matrix). From there it is easy to get linear regression withut doing intensive maths that the Least Squares approach requires, and it does X, Y, and Z all together.
A similar process is either repeated twice for a gyro and accelerator or thrice with the add compass is included and some clever tweaks are made to drop out drift and noise. It just so happen that the Quaternion format input provides Quaternion format out.
I suspect that the main thing that Quaternion's provide is a notation where all four quadrants are unique mathematically. With more traditional maths, the quadrants for ++ and -- get muddled together and the +- and -+ get muddled together when trying to track rotation as sine and cosine.
We all have learned Least Squares Linear Regression in high school or university. But the Gradient Descent Linear Regression seems to be held back for graduate students that need something faster and that can handle the Calculus involved. Gradient Descent Linear Regression also is not confined to 2 dimensions, it handles 3 dimensions.
Just keep in mind that Gradient Descent Linear Regression works with a ton of things and is useful wherever vectors or tensors come into play -- live weather prediction and other super-computer stuff. In those case, the Scalar portion might vary. With rotation, we are forcing the scalar portion to always represent one unit radius. The application to sensor fusion is just a handy secondary application to what it can do, but it loose like this is how earthquake data, weather data, and geological survey for oil and gas gas gets sorted out.
I've attached my latest version of the DCM code. This version uses P18 for the serial link to the PropViz board, and uses P12 and P13 to drive the X and Y servos on my gimbaled motor mount. I've tested all of the output pins, and everything is working. The PropViz program shows the correct orientation of the board, and the X and Y servos track the motion of the board as well. It's pretty cool to actually see hardware responding to the motions of the HoverFly board.
The video doesn't show the problems. It's temporarily stable, but eventually it starts slowly accelerating in a direction, and doesn't counter it. Before long the steppers can't keep up and it falls. I haven't figured out why yet. I also want to make it taller, as that'll make it fall slower, so it's an easier problem.
I mounted my HoverFly vertically rather than horizontally and that has been a bit of distraction on reading code. And of course, I don't have the PID ability of the stepper motors. Maybe I should just go to a quick reconstruction rather than follow my own path.
I did purchase a cheap Serial to Bluetooth link in anticipation of debugging problems... it has yet to arrive. That could provide your data in real time which you could observe and capture.
I see you are using Pololu wheels with the steppers. The motors have 5mm shafts. The wheels I really like are for 4mm shafts, and the wheels I have are for 6mm shafts. If I build anything expensive I desire a good pneumatic wheel for eventual outdoor use.
I have two English students that want to study abroad and need intensive help with improving writing skills. It is cutting into my time with the HoverFly.
@Jason Dorie
I took my dog for his 2 am run and it occurred to me that you might have the positioning of the HoverFly in the wrong location.
At least one individual has asserted that the optimal location for the acceleration sensor is between the axle's of the two stepper motors (low and under the center of gravity when balanced). His was an analog balancing bot, but he claimed it reduced the amount of noise to be managed from the acceleration sensor.
He went on to build a 2 dimension balancing bot that one could actually sit on and ride around. Though his work is all analog, I think his engineering is fundamentally sound.
I still have not gotten to the bottom of this. As a simple model what we have is a long stick with a mass at each end. Now, when your motors fire up and try to balance the thing the base is accelerated one way. Quite likely the head is accelerated the other way. After all we are applying a force to an object far away from it's center of gravity. That is to say a torque around it's C of G which will rotate it.
So, it seems to me that the accelerometer input could be the total opposite to what you want depending if the IMU is placed at the top or the bottom of the robot.
Ergo, I suspect the best place for the IMU is in the middle. At the center of gravity. Where the least lateral acceleration is happening.
Either way. It seems Jason's bot is accumulating some pitch error with time that causes it to run away. Where do we get the absolute reference of vertical here?
@Heater
Obviously, I haven't gotten to the bottom of it either. But I thought that it was worth mentioning in passing.
Opinions differ, but some good solid empirical research will settle the issue. I presumed that Dale actually got some info from a scope, but his justification was not provided in such a formal matter.
The general concept is the gyros are subject to high frequency noise that requires one kind of filtering to prevent wandering; and the accelerometers are subject to low frequency noise that requires yet another solution.
What you do say about positioning in between does make sense if the robot remains static and balancing. I am a bit uncertain if the same position would be good once the robot begins to wander (via R/C control or whatever).
I still go with the idea is to have the controller try to seek and reposition directly under the center of gravity, while being at the axle center minimizes the momentum of swings through an arc.
If you are using the accelerometer as part of an IMU it is probably best to locate it at the center of gravity. This will minimize the accelerations due to rotation. However, in the case of a balancing bot I don't think the location matters too much.
A balancing bot will run away if it doesn't have an accurate reference for vertical, as Heater alluded to. If the sensor axis is slightly off vertical the bot will have to move to keep from falling over. I suspect the problem is in the drift compensation for the gyros. The rate of gyro drift will change over time. The accelerometer provides a correction for the gyros, but there will always be a residual angle error depending on the rate of gyro drift. In PropDMC28.spin the correction factor is generated from the error value by the following statements:
Reducing the divisor from 256 to 128 or lower might reduce the run-away problem. However, if the divisor is too low it will probably cause oscillation, and also make it too sensitive to accelerations, so it shouldn't be made too small.
EDIT: I think there may also be a truncation error, which causes the gyros to not be fully corrected. I believe I saw in the visualizer that the rotation matrix would not always return back to the identity matrix when the HoverFly was put back in it's initial orientation. Reducing the divisor should help to reduce the truncation error. Adding a rounding term would also help, such as:
I still go with the idea is to have the controller try to seek and reposition directly under the center of gravity, while being at the axle center minimizes the momentum of swings through an arc.
But I see it the other way. Let's imagine a hypothetical bot half a meter high, with 1Kg at the head end full of batteries and electronics and 1Kg at the base with motors.
And we have to put our IMU somewhere to get a good measure of tilt.
Now, when it starts to tilt we assume the motors fire up and push it in the right direction.
At that point we have a huge lateral acceleration at the wheel axis. Which may well confuse the IMU if it is down there.
Meanwhile, at the head end there is pretty much no lateral acceleration going on
I might now conclude that the head end is best for our IMU. Where stray lateral accelerations are minimized and a better estimate of "down" can be had.
Dam'it do I have to build one of these for myself?
Dam'it do I have to build one of these for myself?
Well...... why not? Jason has done wonders with NEMA 17 steppers. I am about to order the steppers, the controller boards, and the wheels from Pololu. That would eliminate the need for Encoders and since the HoverFly is not using 16 of the Propeller's i/o pins, the stepper motor solution seems really more prudent.
@Dave Hein
I have been reading the PropDCM28 code along with the rest of what you provided in HoverFly07.zip. I have not yet gotten to your latest revision. You and Jason are way ahead of me. But thanks.
I keep wondering if there is some confusion between the Center of Mass and the Center of Gravity.
Are these the same in this situation? And does putting more mass high really have a benefit of allowing a slower response time? It seems that putting the mass low would require more motor power for quicker response.
I also wonder if the Center of Gravity remains static or might change location depending upon the degree of tilt. I gut instinct tells me No.
In all honesty, I have been so deep into the software that I have ignored the mechanical issues. But they are indeed half of a good design.
I believe the center of gravity is identical to the center of mass in a uniform gravitational field. The center of gravity could be different in a non-uniform field.
Putting the mass higher does two things. It increases the length of the moment arm, and it reduces the mass that you are moving on the surface. Increasing the length of the moment arm allows for a slower response time, but it may be offset by the distance you have to travel on the surface to produce the same rotational angle. Since we can react in about 100th of a second there should be a moment-arm length where this is sufficient, and going longer doesn't really help.
For a rigid body, the center of gravity is independent of the orientation with the gravitation field.
Comments
I hope to look at the other methods when I have time. I appreciate the information you have posted about them.
I order a bag of 25. Let me know if you need any, (via PM). Shipping should be minimal, First Class Mail.
Well, I had a brainwave to create an all Quaternion solution rather than have the Madjwick filters shift from Quaternion to DCM. So far, it seems that shifting over to DCM right after the sensor fusion is the most reasonable way to go.
Euler Angles are not worth using. They are 18th century maths for a 21st century technology. Ironically, Euler also created the maths for a rotational theorm that is used for Quaternions. (So one might get confused by seeing him references with Quaternions. http://en.wikipedia.org/wiki/Euler%27s_rotation_theorem.
One has to learn to visualize in a different way for Euler Angles, Direction Cosine Matrix, or Quaternions. But in addition to the ablity to visualize, one has to determine which optimizes the maths. It all is a bit surprising to actually have such variety in regards to rotation about X, Y, and Z, but the concepts are very subtle in their differences.
It actually seems less costly to convert from Quaternions to Direction Cosine Matrix and then do rotational adjustments for stabilty than to try to merge the two frames of reference with all Quaternions.
No worries, and no apologies necessary. I was thinking about it more over the last couple days and figured it was probably your change to the order of the rotation values. If you change the order of those, *all* the places where the original order is assumed will need to change, so that'll include where the incremental rotation matrix is applied, the gravity vector, which vector you compute the cross products against when correcting the gravity vector, the correction rotation, and so on. It'll be a decent chunk of code to change, so it might be better to just document the original version well and get it working that way, and then change it while leaving the original implementation as reference.
When I wrote it, I started by doing all the coding in floating point in C#. First just the incremental rotation update, then I added in the gravity correction. Once that worked I converted the classes to fixed point, then I ported the fixed point code to the Prop. By doing it on the PC first, I had a reference version to compare my results against at every step, so it was easy to find mistakes when I made them. Much simpler to do this than debug on the Prop itself, especially given that there are so many places it could go wrong, and adding visualization code on the PC is pretty trivial.
I'm just about ready to interface the code to a couple of servos that drive a gimballed rocket motor mount. I have the motor mount attached to a test stand for now. One problem I had was to figure out how to get the X and Y angles that I need to use to drive the servos. I initially came up with a fairly complicated way of deriving the angles because I have to account for rotations around the Z axis. I then realized I can just use the two matrix values that represent the Z component of the rotated X and Y axes. To get the precise angle I would need to do an arc sine, but I think I can avoid that since I'm working with a small angular range.
I'll try to take some video of it, and post it once I get it working.
Direction Cosine Matrix is making sense to me for a balancing bot. I only need to keep track of the Pitch for balancing stability, so rotation measurements are only necessary about the Pitch axis. I can safely ignore Roll and Yaw activity. And it seems that mostly, I just need to know the direction of lean to react to, not much need for a precise scalar at this point. IOW, the 9DoF device will work, but it is going to be under-utilized.
The HoverFlyGimal Experimenters board makes a great input device for some sort of control or gaming. I mounted one in a small plastic case with a slot cut out for the USB. It seems possible to easily add at least 3 button inputs as well.
My other HoverFly is on the balancing bot, but I am a bit concerned that without encoders on the motors this is going to teeter a lot.
In the usual analysis of the inverted pendulum problem that I have seen there is a model with a mass at the top, the pendulum bob as it were, and a mass at the bottom, the cart or at least wheels. In order to balance one has to move the base under the bob by applying a horizontal force to it.
That force translates to current in the motors driving the wheels, which basically translates to the PWM signal we send to the motor driver.
No wheel encoders required. Indeed there are many examples of balancing bots with no wheel encoders.
Now, if you want the bot to balance and also try to maintain its position on the ground then you need to know how far it has wondered from it's starting point. You might want to use wheel encoders for that estimation.
You are right that a 9 DOF sensor is overkill for a balancing bot. After all this chap does the job with nothing but a pair of light dependent resistors and a 555 timer for control. Or even just two transistors! http://www.reddit.com/r/electronics/comments/f7p9l/how_to_build_a_simple_analog_balancing_robot_with/
Or on YouTube:
https://www.youtube.com/watch?v=bdNxgCsWB5E
This is what they look like:
They have a slightly greater ID than the HoverFly Open, but I don't think it matters since there is a 4-40 screw going in and doesn't contact the internal walls on the original..
Well, eventually I desire a balancing bot that will handle sloped surfaces -- thus the need for gyros, etc. Iit still is all one axis. But the one axis project is merely a stepping stone toward two, and then three. I am already getting very curious about stabilized r/c flight as I have an electric glider that could use that.
Stability in this case is all about measuring the tilt and reversing it. The Direction Cosine Matrix pretty much does this by providing tilt data and then applying a Rotation Matrix for one select axis to do the opposite of what was given as output.
http://en.wikipedia.org/wiki/Rotation_matrix
The Inverted Pendulum is an elegant presentation of the problem, but the reality is that you just have to keep moving the axle under the center of gravity. Not sure how much one has to thing about pendulums and reversing pendulums and so forth, just as long as the iterations don't let the device wander too far from upright.
Umm.. I am using an LM297 H-bridge to control the motors. Not too sure that PWM will come into play or not.
Accelerometers, gyros etc are just a means to an end here. What we want to know is how far from upright is the bot so that we can try and correct for it and stop it falling over. As shown above this can be done with simple light sensors and many other means.
Sloped surfaces make no difference. Except you have to do more work to move the base up hill than down, so knowing something about the slope might help. So far we have not discussed that.
I agree, the one dimensional balancing bot is a good stepping stone to other things like planes and quad copters. Well I don't know. The inverted pendulum seems like a good model of what we want to do here. It tries to describe a mass on a stick standing above it's base. The inverted pendulum model at least explains why proportional control alone is not enough. The differential signal is also required.
Like all such mathematical models it may not perfectly describe the actual physical hardware you have but it's a good start.
The DCM thing says nothing about actually controlling the balance of your machine. It only helps in getting sensible data from your sensors. After all it has no idea if your machine is a balancing bot, a quad copter, a ship or a Saturn V. The LM297 switches power to your motor. Full on or full off. Forwards or backwards. If you want more than stupid "bang-bang" control you are going to want to vary the power in a more analogue way. That is done by varying the pulse width. That is PWM.
P.S. I just found this nice paper that describes quaterions and how to convert them to and from Euler and DCM. Might be useful: http://www.tu-berlin.de/fileadmin/fg169/miscellaneous/Quaternions.pdf
I can only handle so much of this intellectual debate nonsense. I simply reserve the right to study in my own way and to select projects that seem to help me do so. I want to learn, not to replicate without the kind of understanding that will empower me to be more creative.
Yes, you can use light or ultrasound sensors to have a two-wheel robot balance on flat surfaces; but in the real world of varied slopes -- a gyro with accelerometer is going to faithfully tell you how much tilt.... regardless of what the surface does. Those other sensors will not.
And when you add in PID for the motors to assure they don't run wild, you end up with an all-terrain balancing bot that can stand in one position on a slope, or do fancy maneuvers..
_______
I purchased the HoverFlyGimal to experiment, and the one-axis solution is just my way of applying the maths in the most limited context. I will get to 2D and 3D a bit later.
One of the Kalman filter's weaknesses is that it does sensor fusion for each axis separately; while Madgwick does all three axises at the same time.
Ironically, I suppose I could just use Kalman for the balancing bot and might even have a bit less code. But I decided to deploy Madgwick, then convert it to DCM, and finally use just one axis. If it works, I have the other data available for other purposes. I suppose using the Yaw to do tight 90 degree and 180 degree turns would be interesting.
+++++++
The main point is that I am not trying to replicate the cheapest balancing bot that was ever posted on the internet.
I am using the balancing bot as a means to expand my knowledge of IMU and MARG devices in a way that I might apply them to many different project scenarios... primarily as a stabilization device or a positioning device.
And I am trying to learn on the Propeller platform. Dave Hein has helped a lot with his code contributions expanding on Jason Dorie's original PropellerDCM.
So far, a lot has been learned.. far more than what I have reported here. Much of it has been about math topics that I fear would scare off many timid souls.
The Madjwick filter has math roots that go way back. One paper I have that uses the same gradient descent approach is for flight simulation that was written in 1981. I find it a bit curious that that Kalman got so entrenched in quad-copters and DIY drones as it seems people in aeronautics and aerospace have known Kalman to be inferior for many decades.
+++++++
Yes, I realize the LM297 is not really optimal. I tend to strongly dislike how hot it runs and would love a MOSfet H-bridge instead. But I figured that I'd learn more by trying with this and adding PWM; than by buying into a set up that does it all for me. There are robotic motors out their with built-in PID these days.
Regarding your link to the Berlin paper on Quaternions applied to spacecraft, I provided that link earlier and have read it a half-dozen times.
There are a lot of other links to to Quatnion Stabilization Algorhithm as applied to spacecraft, but the publishers want $$$ for copies of those articles. I may see if I can get an E.E. friend to get free copies via his university library. Those might lead the way to not having to use the Direction Cosine Matrix as an interim step.
http://www.adafruit.com/blog/2013/11/08/self-balancing-raspberry-pi-image-processing-robot-raspberry_pi-piday-raspberrypi/
The direct driver steppers do seem to have several construction advantages.. you don't need belts and gears. There is space between the two motors to place an IMU if that is indeed the optimal location.
My dilemma is that I need to go shopping for the stepper motor controller. I already have a pair of steppers that fit direct drive wheels.
I guess in the back of my mind, I have wanted to explore encoders and PID as a second topic as well. But I seem to move along at a snail's pace with actual construction and coding. Right now, I have something built and I am trying to get the coding in order. After that, a rebuild of the balancing bot with more expensive hardware.
I filled my income tax last Monday for 2013, so that distraction has vanished until next year.
Excellent find. I have been trying to get Dave Heins code compiled and loaded, but this seems to be another worthy item.
Ooops, sorry. My coworker gave me a printed copy of that paper that got mixed up with other printouts in the office days ago. I had forgoten where it came from so I googled it and recycled it back here.
I was not suggesting we abandon an IMU for other sensors. Or that we should throw out the MCU contol for two transistors. I mentioned them only to emphasise that a 9 DOF systems is probably overkill for simple balancing and that wheel encoders are not needed for that.
All depends what you want to do of course. For an all terrain, steering, navigating bot you may well need a lot more complexity.
I do agree, simply cloning a design, simple or otherwise, off the net is not so interesting. This thread has introduced me to a whole world of new and useful ideas. Starting from that quaternion thing... All good stuff even if I never get around to building a balancing bot.
So thank you all for that.
Well, my reaction was a bit strong.
I have moved on to reading and loading both Jason Dorie's code and Dave Hein's code in order to see if I can modify some of their work for the balancing robot. Not much to report there.
On the other hand, while the Berlin paper is informative on Quaternions, the really interesting stuff centers around the Gradient Descent Linear Regression.
The whole reason that Madjwick is superior to Kalman has to do with avoiding the Least Squares Linear Regression and using this powerful alternative. It just so happens that Gradients are a math concept that get expressed in Quaternion notation and so the sensor input fit by presuming the scalar will always be equivalent to a unit radius (that is why you see normalization calculations -- to convert the data to the concept of a unit radius equivalent).
Since the readings are taken at regular intervals, you end up with derivatives that migrate nicely into a first derivative matrix (called the Jacobian Matrix). From there it is easy to get linear regression withut doing intensive maths that the Least Squares approach requires, and it does X, Y, and Z all together.
A similar process is either repeated twice for a gyro and accelerator or thrice with the add compass is included and some clever tweaks are made to drop out drift and noise. It just so happen that the Quaternion format input provides Quaternion format out.
I suspect that the main thing that Quaternion's provide is a notation where all four quadrants are unique mathematically. With more traditional maths, the quadrants for ++ and -- get muddled together and the +- and -+ get muddled together when trying to track rotation as sine and cosine.
We all have learned Least Squares Linear Regression in high school or university. But the Gradient Descent Linear Regression seems to be held back for graduate students that need something faster and that can handle the Calculus involved. Gradient Descent Linear Regression also is not confined to 2 dimensions, it handles 3 dimensions.
Just keep in mind that Gradient Descent Linear Regression works with a ton of things and is useful wherever vectors or tensors come into play -- live weather prediction and other super-computer stuff. In those case, the Scalar portion might vary. With rotation, we are forcing the scalar portion to always represent one unit radius. The application to sensor fusion is just a handy secondary application to what it can do, but it loose like this is how earthquake data, weather data, and geological survey for oil and gas gas gets sorted out.
If you are only part way there, where are you planning to get to with it?
J
Wonderful progress on your part.
I mounted my HoverFly vertically rather than horizontally and that has been a bit of distraction on reading code. And of course, I don't have the PID ability of the stepper motors. Maybe I should just go to a quick reconstruction rather than follow my own path.
I did purchase a cheap Serial to Bluetooth link in anticipation of debugging problems... it has yet to arrive. That could provide your data in real time which you could observe and capture.
I see you are using Pololu wheels with the steppers. The motors have 5mm shafts. The wheels I really like are for 4mm shafts, and the wheels I have are for 6mm shafts. If I build anything expensive I desire a good pneumatic wheel for eventual outdoor use.
I have two English students that want to study abroad and need intensive help with improving writing skills. It is cutting into my time with the HoverFly.
I took my dog for his 2 am run and it occurred to me that you might have the positioning of the HoverFly in the wrong location.
At least one individual has asserted that the optimal location for the acceleration sensor is between the axle's of the two stepper motors (low and under the center of gravity when balanced). His was an analog balancing bot, but he claimed it reduced the amount of noise to be managed from the acceleration sensor.
He went on to build a 2 dimension balancing bot that one could actually sit on and ride around. Though his work is all analog, I think his engineering is fundamentally sound.
I still have not gotten to the bottom of this. As a simple model what we have is a long stick with a mass at each end. Now, when your motors fire up and try to balance the thing the base is accelerated one way. Quite likely the head is accelerated the other way. After all we are applying a force to an object far away from it's center of gravity. That is to say a torque around it's C of G which will rotate it.
So, it seems to me that the accelerometer input could be the total opposite to what you want depending if the IMU is placed at the top or the bottom of the robot.
Ergo, I suspect the best place for the IMU is in the middle. At the center of gravity. Where the least lateral acceleration is happening.
Either way. It seems Jason's bot is accumulating some pitch error with time that causes it to run away. Where do we get the absolute reference of vertical here?
Obviously, I haven't gotten to the bottom of it either. But I thought that it was worth mentioning in passing.
Opinions differ, but some good solid empirical research will settle the issue. I presumed that Dale actually got some info from a scope, but his justification was not provided in such a formal matter.
The general concept is the gyros are subject to high frequency noise that requires one kind of filtering to prevent wandering; and the accelerometers are subject to low frequency noise that requires yet another solution.
What you do say about positioning in between does make sense if the robot remains static and balancing. I am a bit uncertain if the same position would be good once the robot begins to wander (via R/C control or whatever).
I still go with the idea is to have the controller try to seek and reposition directly under the center of gravity, while being at the axle center minimizes the momentum of swings through an arc.
A balancing bot will run away if it doesn't have an accurate reference for vertical, as Heater alluded to. If the sensor axis is slightly off vertical the bot will have to move to keep from falling over. I suspect the problem is in the drift compensation for the gyros. The rate of gyro drift will change over time. The accelerometer provides a correction for the gyros, but there will always be a residual angle error depending on the rate of gyro drift. In PropDMC28.spin the correction factor is generated from the error value by the following statements: Reducing the divisor from 256 to 128 or lower might reduce the run-away problem. However, if the divisor is too low it will probably cause oscillation, and also make it too sensitive to accelerations, so it shouldn't be made too small.
EDIT: I think there may also be a truncation error, which causes the gyros to not be fully corrected. I believe I saw in the visualizer that the rotation matrix would not always return back to the identity matrix when the HoverFly was put back in it's initial orientation. Reducing the divisor should help to reduce the truncation error. Adding a rounding term would also help, such as:
But I see it the other way. Let's imagine a hypothetical bot half a meter high, with 1Kg at the head end full of batteries and electronics and 1Kg at the base with motors.
And we have to put our IMU somewhere to get a good measure of tilt.
Now, when it starts to tilt we assume the motors fire up and push it in the right direction.
At that point we have a huge lateral acceleration at the wheel axis. Which may well confuse the IMU if it is down there.
Meanwhile, at the head end there is pretty much no lateral acceleration going on
I might now conclude that the head end is best for our IMU. Where stray lateral accelerations are minimized and a better estimate of "down" can be had.
Dam'it do I have to build one of these for myself?
Well...... why not? Jason has done wonders with NEMA 17 steppers. I am about to order the steppers, the controller boards, and the wheels from Pololu. That would eliminate the need for Encoders and since the HoverFly is not using 16 of the Propeller's i/o pins, the stepper motor solution seems really more prudent.
@Dave Hein
I have been reading the PropDCM28 code along with the rest of what you provided in HoverFly07.zip. I have not yet gotten to your latest revision. You and Jason are way ahead of me. But thanks.
Are these the same in this situation? And does putting more mass high really have a benefit of allowing a slower response time? It seems that putting the mass low would require more motor power for quicker response.
I also wonder if the Center of Gravity remains static or might change location depending upon the degree of tilt. I gut instinct tells me No.
In all honesty, I have been so deep into the software that I have ignored the mechanical issues. But they are indeed half of a good design.
Putting the mass higher does two things. It increases the length of the moment arm, and it reduces the mass that you are moving on the surface. Increasing the length of the moment arm allows for a slower response time, but it may be offset by the distance you have to travel on the surface to produce the same rotational angle. Since we can react in about 100th of a second there should be a moment-arm length where this is sufficient, and going longer doesn't really help.
For a rigid body, the center of gravity is independent of the orientation with the gravitation field.