Except good percentage of my ramblings are actually correct, for example:
Where is the center of rotation on a balancing bot? Through the centers of both wheels.
No it is in not.
Why is that so hard to envision?
Because it not true. Except in the Loppyverse where Loopy physics applies:)
Basically, gravity is applying a force at the centre of mass to rotate the robot about the wheel axles, while the motors apply a force at the wheel axles to rotate the robot about the centre of mass. So I cannot agree that the resulting centre of rotation is at the wheels.
Here is an experiment you can do to convince yourself of your error:
Take a broom. Balance it upside down in you fingertip, brush end up in the air.
Observe that as you desperately try to keep the thing balanced upright the base, your finger end, is thrashing around a lot. The brush end might not be moving as much quite often. Observe how the broom seems to be rotating about a point somewhere along it's handle length.
Or watch a guy riding a tall unicycle. Notice how the wheel will often be oscillating backwards and forwards a lot while the guy on the seat at the top seems to be quite stable. Where is the centre of rotation of the unicycle? Not at the wheel.
Why is it important. While the gyros don't care, the accelerometers do. If they are off the axis...
Exactly. That is why you might want to put the IMU sensors at the point on the body where least acceleration is going on. As you say. But that point is not necessarily at the bottom between the wheels on a balancing bot.
Javascript? Maybe mention the Raspberry Pi while you are on pet themes.
Nobody mentioned the Raspi here. That is a nightmare going on in your head not in reality
I could welcome a Javascript graphic application in Linux that will take the quaternion data stream and display in real time the motions of a floating box.
Yes that is what I had in mind. So my ramblings do produce a good idea some times. Thank you.
You don't need PID to get a robot to balance and not wobble on flat floor. You do need PID to get the robot to go up and down slopes...
Why is that true?
What control algorithm would you suggest if not a PID?
These things can be done with fuzzy logic and other methods but they are more complex to implement than a PID as far as I know.
The next simple alternative is a "bang bang controller". Which can work to some extent. Sorry can't find a link to support that assertion but I sure I saw that someone had done it somewhere.
I do understand that you are referring to a dynamic center of rotation. This concept come up in boat design and airplane design. What I mentioned was passed along repeatedly in reading other's construction of balancing bots. They say put the IMU low and as close as possible to the axle. Remember that you have only one axis to deal with. I suspect that a Complimentary filer is quite adequate if that is all you are using. (But I really want to get Madgwick working anyway).
In boats, you have a center of gravity, a center of buoyancy and these are in constant motion. I have no idea where you might put an IMU on a boat. In aircraft, the wings and the hull would pretty much define a center for X, Y, and Z.
You may be right about the inverted pendulum moving the center of rotation. But would it be dynamic or stable?
You don't need PID to get a robot to balance and not wobble on flat floor. You do need PID to get the robot to go up and down slopes...
Why is that true?
What control algorithm would you suggest if not a PID?
These things can be done with fuzzy logic and other methods but they are more complex to implement than a PID as far as I know.
The next simple alternative is a "bang bang controller". Which can work to some extent. Sorry can't find a link to support that assertion but I sure I saw that someone had done it somewhere.
Fuzzy logic is just to fuzzy for me.
The question of needing a PID for the motor is actually a separate PID issue that monitors the wheels via encoders.
I suppose you could argue that the code for balancing is indeed a PID algorithm as well. The gentleman with the analog balancing robot makes that case and explains how he sees it.
I believe he also mentioned that PID on the motors was only required for up and down slopes to hold the motors under tight control.
You never can find the link to support your assertion! But I find mine. Back to Dale's Homemade Robots.
It just could be that the center of rotation is NOT the issue.
The acceleration at the center of the axles is what is important for the accelerometers to measure and being as close as possible to that removes delays in measuring reversals. Just maybe I got tangled up with thinking that meant the center of rotation.
The objective remains keeping the Center of Gravity underneath the wheels.
Here is a link to what might be a better PID scheme of the whole balancing bot concept. This guy was recognized by NASA.
Very true. I like you just the way you are. Do continue.
You may be right about the inverted pendulum moving the center of rotation. But would it be dynamic or stable?
No idea. I can only just convince myself that the equations of motion in the wikipedia article look like they make sense:)
Here is a though experiment:
You balancing bot has all it's electronics and batteries at the head end. For the purpose of this thought experiment we are using a 50 kilogram car battery. Meanwhile our motors are really small and light and can only apply an insignificant driving force.
What happens?
The thing tips over a bit. The motors try to correct that. But being puny they are overwhelmed by the huge mass of that car battery.
The car battery now proceeds to fall almost vertically downwards pushing the motors out sideways rapidly.
Where is the centre of rotation of that?
Where is the point along the height of the bot that experience the least acceleration?
Clearly the battery at the head end was falling vertically and accelerating at almost 1g straight down.
Meanwhile the wheel end was accelerating violently sideways.
The point of minimal acceleration was somewhere in between head and wheels.
I agree. Works well in some applications we have at work though.
The question of needing a PID for the motor is actually a separate ...issue...
Agreed, let's skip that for now.
You never can find the link to support your assertion! But I find mine. Back to Dale's Homemade Robots.
Yes you find your references, but do you ever read them?
Your assertion was that "You don't need PID to balance a bot"
Your link clearly shows a PID controller in the first schematic.
Notice in that block diagram how tilt and rate of tilt signals are summed into create the torque demand signal?
Further down he page text Dale explains in detail how P and I and D are all in there.
I will never get anything built with Heater challenging me.
Ah yes, ignore me. Get that soldering iron on.
The acceleration at the centre of the axles is what is important for the accelerometers to measure and being as close as possible to that removes delays in measuring reversals.
I will go with Dale's advice to put the accelerometer next to the axle. (He says low and near the center of gravity.)
Why? He is the guy with the bowling ball balancing bot that he rides around seated on. And he is the guy that said when he placed it high, he got nothing but heart ache.
++++++++
Actually, my whole balancing bot is built except for the Hoverfly unit. But I don't have encoders on the motors, so that will be very telling.
I did a lot of searching to see if I actually needed motors with encoders and concluded no. Later I will add the motors with encoder - either after a dismal failure or out of the desire to have an all-terrain balancing bot. IOW, this project is going to be long-haul and I expect a second revision where more money will be invested in good hardware.
NOTE -- Dale's IROLL mentions it is important to place the IMU in the center of pivot. and his first project moved repositioned the the acelerometer next to the axle. This is trial and error observation, not theory. He also mentions the issues of PID motor control need for inclines in his first analog balancing bot.
It might be fool hardy to argue with a guy who has actually done it and got it working in practice.
Looking at his block diagram we can see that if the accelerometer is at the head end it will have less acceleration to report and hence less effect on that PID loop. As we have seen the wheels can be thrashing to and fro quite rapidly whilst the big mass at the top barely moves.
Dale's advice to put the accelerometer next to the axle.
and...
(He says low and near the center of gravity.)
Hmm...that's not making sense to me. Those two statements seem contradictory. If he is riding on the thing, I have seen that video, then the c of g of the whole machine is probably not next to the axle.
I guess it's time to start building and experimenting. I'm sure I have some motors around here some place...
Well, at least you know I am making accurate use of my reference material. Possibility right results, wrong justification.
I just have been working diligently to acquire a set of web references that will get me off to a good start. I certainly do get that the Center of Gravity changes when somebody sits in the chair. But there is a bigger acceleration swing of the axle axis as you get farther away from it.
Okay, having gotten a good night's sleep... I think I understand what the builders are trying to say about placement of the IMU for optimal data.
The main issue is that when placed in the wrong location, the data accumulates acceleration data about centrifugal forces that must be filtered out.
So it seems that for an inverted pendulum, the best sensor placement is 'under the the center of gravity' and centered on the wheel axis for a one axis solution.
Why so? The target is to measure the angle and realign the center of gravity under the wheel axle. This sensor placement reduces the data management problems. One uses less noise filtering and avoid having to consider something like calculating an asymmetrical offset with vector calculations ( I don't really want to ponder how to do that.)
For a two-axis solution, it would be ideal to have it under the center of gravity and centered inside the ball. But that would be a very awkward place to install the IMU. So it seems that the second best place for the IMU is directly above the ball's center, so that it is not getting bad data about rotation and it is below the center of gravity.
@Heater
Does that explanation meet your approval?
@Everyone
One can't quite trust the web and the internet to get things right 100% of the time. Errors in information can propagate like wildfire in a 'cut and paste' world. The main point here is that the balancing bot is really a wonderful learning platform and so are IMUs. Lots of physics, mechanics, sophisticated maths, and even a touch of real rocket science.
I suspect Dale meant to say keep the sensor low and under the center of gravity, but just didn't quite express well what he knew would get better results.
Balancing bots are simply chasing the center of gravity at all times to remain upright.
Why so? The target is to measure the angle and realign the center of gravity under the wheel axle.
I guess you mean "realign the centre of gravity over the wheel axle". The c of g is somewhere between the wheels and the top of the machine and we want to keep that point over the point of contact with the ground. Other wise, yeah OK.
This sensor placement reduces the data management problems.
I have no idea what that means.
One uses less noise filtering and avoid having to consider something like calculating an asymmetrical offset with vector calculations
I have no idea what that means.
Question is what actually do you get out of the accelerometer and what does it mean?
Some thought experiments:
Consider a stick, say one meter long, standing upright. It is constrained to only be able to fall to the left or right. There is a 1 dimension accelerometer fixed to the stick such that it measures left/right acceleration.
1) At balance what does the accelerometer read? Nothing. Does it matter where along the stick the accelerometer is? No.
2) If the stick his held stationary at a 45 degree inclination what does the accelerometer read? Basically 0.7g. That is sin(45) times the acceleration due to gravity. In general the acceleration reported is g*sin(theta) for static positioning at various angles.
We don't have a static system so that's no good. Let's allow the stick to start upright and fall over:
3) With the accelerometer at the top of the stick, what does it read as the stick falls down to horizontal?
Well, I'm not sure. If the accelerometer were just dropped in free fall it would always read zero as it has no left/right motion.
But here the stick is pushing it left or right as it falls. So presumably it registers something. But on the other hand it's orientation is changing from left/right to up down as well. At the point in time the stick reaches horizontal it is in free fall, at least at the c of g of the stick.
Can anyone guess the shape of the graph of accelerometer readings during the fall?
4) How does this change as we position the accelerometer lower down the stick?
Clearly if the accelerometer is at ground level it never moves but it's reading change from zero to 1g as it is rotated over 45 degree. What about at other positions?
5) We add motors and wheels to our stick to propel it left and right. What is our accelerometer measuring now?
Clearly it is mostly measuring the acceleration left and right, due to the motors, of the base of the stick when positioned at ground level. That could be rather large and dramatic movements, even when the top of the stick is hardly moving.
But what about when we put the accelerometer at the top. Now it measure "head" movements. These could even be in opposite direction to the "tail" because our stick will rotate around it's c of g so if the base is pushed left the head will go right.
Arghhhh.......... the with or without PID is getting very annoying. It certainly seems as if you want to obscure the way forward.
P = Proportion
I = Integrate
D = Differentiate
The three components can combine in many ways. Solutions can be mechanical, analog, and digital.
We are trying to develop control solutions for design, not just point of phenomina that don't require control.
A. I have tried to clarify the balancing bot PID requirements by refering to two rather good sources == Dale's Homemade Robots and NBot, a NASA recognized balancing bot.
>Dale is a pragmatic 'old school' machinist that relies on proportion, integration and differentiation as required --- not a 'software packaged concept' of PID.
>The NBot has been subject of peer review by some of the best, so I feel it is an above average presentation and should be studied in detail.
B. Both indicate that there are situations where you can remove more than one of the elements of P, I, and D or you can double up on more than one of the elements. IOW, the internet buzz of PID this and PID that is not a full understanding of which components apply and where.
> Dale prefers OP-amps and getting his PID in analog form rather than bothering with the overlay of digital. I find this an excellent contrast to the digital solution and a means of letting analog or mechanics do something better on occasion and have the digital do what it does best.
>>>>>>Bear in mind that Newtonian maths is roughly three centuries old and the digital age of its application is rather new. PID can and may best be done mechanically or via analog, with the digital aspect only coming into play when older solutions under-perform. Try a cafeteria-style approach of understanding where the P, I, and D may come from a combination of elements (forget all that fuzzy logic nonsense as it justifies something that works but is not wholly understood.)
>NBot is backed up by a Geologist that has a deep resume in imaging seismic data. So his vision of a balancing bot is inclusive a wider view than 'getting the PID just right' from a code example.
C. I have pretty much viewed the PID of motor encoder feedback as a separate solution from the PID of IMU axis feedback.
>The realitly is that [a] Dale mentions in his analog balancing robot, a limited flat surface case of PID can be done for only flat surfaces AND he mentions the need for an expanded or additonal PID solution for the sloped surface via the use of motor encoders.
>NBot seem to provide a good diagram of the whole - PID inclusive of the IMU input and the motor encoder input. PLEASE NOTE - the web is awash with PID examples only for motor encoders, not a combination of feedback inputs.
What I am trying to say is two things.
1. Don't hang on to the web-centric notions of PID and the one and only solution to PID. In real design more complex models evolve from the realities of making a better product and older technologies that work well.
2. I am trying to build an encoder-less solution first with a limited PID model. And then, after I find out what it does -- I will purchase motors with the right torque and encoders for a more refined robot.
I don't want to waste money on buying several pairs of motors and encoders as these items are a major portion of the expense. I have a pair of motors that seem okay for the first phase.
As you can see, rather than just looking at the whole project as a lump, I am taking it in phases that conserve time and money while making learning optimal.
And I am trying to take a very pragmatic approach to researching what information I rely upon.
One cannot learn as much by just grabbing any old 'How to' tutorial that fits what you have in your junk box or your personal passions for one project. Be a realist, be pragmatic.. that is real engineering. And above all, don't disdain the topics of mechanics or analog as they both have long provided a series of successes that built up to the digital age.
It is a 'right tool for the job' approach that can be very rewarding.
What? Why would you be annoyed. I'm not trying to obscure anything. I'm trying to get a clear view through your muddled statements to whatever it is you might actually mean .
Your assertion was that we don't need a PID to balance the bot. However you have not answered my question as to what other control technique you would like to use. Whist at the same time your oft' quoted examples, Dale's bot and the NBot both use PID.
Now when I say "PID" I use the term loosely, which I guess could have confused you. That can be"proportional", "integral", or "differential" or any combination of any of them. You can always set their gains to zero to turn them off if you don't need them. Or just don't include that op amp or line of code.
So far nobody has talked about implementation, digital or analogue. Well, except my statements that "Concord was stabilized by a bunch of op amps....Hence my search for the most simple circuitry that can do this."
For a simple control schemes like PID on a bot like this it makes no difference if it's done with analogue or digital technology. Dale has demonstrated how to do it with op amps. But if you are starting with sensors that have digital outputs does it not make more sense just to write the code into the same processor that is handling that?
Newtonian maths may be old. So what? That has no bearing on whether we build a digital or analogue PID controller.
...forget all that fuzzy logic nonsense as it justifies something that works but is not wholly understood.
That is an interesting statement. Yes fuzzy logic is used where people cannot model the system they are trying to control. However I would guess PID is applied in many such situations as well. Or applied by people who don't have the mathematical chops to create a model of the system anyway.
Are you saying that you understand the inverted pendulum problem? Can you tell us why an inverted pendulum cannot be stabilized with just proportional or differential control alone but can be stabilized by using both? Neither can I. If I don't understand the system what difference does it make if I use PID or fuzzy control, as long as I can get it to work?
I don't care about the resume of the NBot creator, only whether the NBot works or not (Great machine by the way). As for "wider view than 'getting the PID just right'", that is exactly what the NBot creator did. Here is the code he uses:
Notice the comment in the code "define constants. In the demo these were set with a knob". Seems nobody knows how to do this except by trial and error and getting the PID just right' is the order of the day
Don't hang on to the web-centric notions of PID and the one and only solution to PID
I have no idea what "web centric" notions of PID you mean. The nbot has been on the web since 2003 when I first discovered it. Whatever it does is a "web centric" notion of PID. I have been writing and using PID algorithms since well before there was an internet.
I am trying to build an encoder-less solution first with a limited PID model. And then, after I find out what it does -- I will purchase motors with the right torque and encoders for a more refined robot.
That would be my plan as well. Although I'd never likely get passed the simple prototype stage.
...don't disdain the topics of mechanics or analog as they both have long provided a series of successes...
I don't. I love steam engines and other old motors. They have mechanical centrifugal speed regulators that work very well. I doubt that the first builders of those regulators had any idea about control system theory, laplace transforms etc etc.
P.S. If you are wondering why both proportional and differential control are required to stabilize the balancing bot, not just either alone, then this nice chap from MIT explains it here : http://www.youtube.com/watch?v=D3bblng-Kcc
I can't really do anything about your interpretations of my meaning. I do know enough about semantics to see that you take a literal narrow interpretaton and then run with a rebutal. It seems you want to assert your authority rather than help to clarify.
What I did attempt to say.. has been subject to much clarification. Don't you get it?
I suggested that one might remove the PID that is involved in the motor encoder. I NEVER said or intended to assert that no PID was necessary.
You are simply being excessively pedantic, thus the snipe about less beer and more thought.
Yes indeed, you use terms loosely when it is to your argumentative advantage and then push others into a corner with a narrow interpretation of their usage. Clever, but transparent, and getting to be very old.
What is my alternative to PID? I didn't offer one as I wasn't making the claim you have been running on and one with.
I have presented the facts FOR the benefit of everyone that might desire to learn more about IMUs and balancing bots. But you turn this into a Heater versus Loopy circus. I have no idea why.
The point about Newtonian maths is not that it is worn out by being 300 years old, but that it is profoundly duriable and has provide 300 years of technical innovation, and may be applied via means other than digital. Robotics is a marriage of digital, analog, and mechanics. Doing everything digital may actually be less than optimal... EVEN SLOWER and less stable, and often more $$$.
OK, now I'm with you. The source of my confusion was your statement in post #61 here:
From what I understand, PID is rather fiddly. You don't need PID to get a robot to balance and not wobble on flat floor. You do need PID to get the robot to go up and down slopes. So why not to debug without it.
That was in the context of simply balancing a robot, no mention wheel encoders or motor control there. So it was a tad ambiguous and caused me to wonder what you would use instead of PID.
@Ratronic
I did notice that, steppers are an interesting variation. Instead of encoders and quadrature to determine position and speed, the mircocontroller keeps track of the steps ... so it had PID feedback via another method.
It really is a very slick robot. The NEMA21 steppers a bit heavy, but being low they lower the overall center of gravity. And they have a nice cap between them that you can place an IMU in for best performance. Motors with encoders tend to be long, whereas the stepper motors are flat. So you get a narrower robot without having to to copy the NBot configuration that adds gears and a pair of offset motors.
My only problem with using stepper motors is that I have to locate a pair of stepper motor drivers. I think I have a pair that I could use in my junk. It might be a good second phase instead of geared motors with encoders. Not only lower budget, it is an easier build.
Any day now, FedEX will deliver my HoverFly Experimenter board and I can start trying a few things with what I have got.
But I have grown very fond of that Raspberry Pi bot as I can finally see it doing something dramatically useful with the visual recognition. This is way beyond the traditional line follower and maze runner kind of robot. It is more likely to survive navigation in a real world environment.
Thanks for mentioning. I think we will see more of trying to emulate it with a Propeller. I will go shopping for some stepper motor controllers and find out how they like their PID control.
Using only P and I? That is a point I was trying to make. Proportion, Integral, and Derivative don't have to be taken together. But new learners might thing so.
++++++++++
Also, I really do think it is far easier to configure PID if you can reset the parameters via wifi. So I am considering putting my MR3020 onboard the balancing bot to allow a wifi link to reconfigure the wifi parameters.
And I want to use a Bluetooth link to a game controller as the remote. The investment is much cheaper than R/C remote control and my 27Mhz R/C receiver has a wire antenna of about 1 meter. Bluetooth will be a cleaner build, and cheaper too. (DealExtreme can deliver both parts for less than $25 USD... a Bluetooth serial reciever for $10 USD and a six DOF game controller via Bluetooth for $12 USD or less.)
In sum, I could stay busy for a long time with all this. For now it is the baby steps to getting started.
OK, now I'm with you. The source of my confusion was your statement in post #61 here:
That was in the context of simply balancing a robot, no mention wheel encoders or motor control there. So it was a tad ambiguous and caused me to wonder what you would use instead of PID.
With that out of the way, let's continue.
P.S. Me pedantic? Never
I understood the source of confusion all along. Could have cleared it up right away if the challenges didn't get more and more fierce.
Very, very nice and tiny 9Dof with the Propeller and USB included. That makes the building pretty much a 15 minute job to complete.
But I have tons to learn. I guess the starting point is to see what the board does on its own. It is supposed to come loaded with software that will output raw data back through the USB to a computer via a serial connection.
Here is a rough To Do List.
1. Proof of life testing -- see if I can get Raw sensor data through serial port
2. Getting a Madgwick filter test bench
3. Figuring out how to use the Quaternion data to drive an dual H-bridge and/or two stepper motors
4. Figuring out how to insert PID to the motors
+++++++++++++
I do have another order in transit from DealExtreme that includes a $10Dof. If anyone already has a Propeller, I suspect that the code that DealExtreme provided for Proof of life testing might be adapted to that.
And then everything could be followed along in parallel.
Please note, that the first step is to get the data output to be stable, and then the second is to deal with driving the motors. You will likely get lost if you try to do this all at one go.
1. Proof of life testing -- see if I can get Raw sensor data through serial port
The HoverFly is pre-programmed with code that prints out the raw sensor data. You just need to plug it into a USB port and connect to it with the Parallax Serial Terminal.
Thanks Dave.. you had mentioned that previously in the HoverFly thread.
So far I have spend the evening on my '15 minute' build. But it is coming along nicely. I need to sitting and study the schematic and ponder what I have done.
HoverFly sent me a nice black T-shirt with their logo on it just to offset the international shipping. The only problem is that yesterday we had a policeman beaten to death trying to break up a Triad dispute. And today the police seem to arresting dozens of males in black T-shirts in Taipei. I think I will wait a month or two before I am tempted to wear it.
+++++++
I did study the Madjwick code for 6DoF from his 2007 paper today and it is not that difficult if you can grasp that Jacobian matrices are partial differentials. It pretty much just initializes, gets the accelerometer readings, prepares them for the combining with the gyro readings, gets the gyro readings, preps them, and then combines the two for output.
@Ratronic
Thanks for the code. I am excited about it.
As far as myself, it just seems that I have to either lay down or stand up for a week or two while I regain strength in the back. I got out today, walked the dog, had a latte at a nearby Starbucks, picked up clean laundry, rode the motorscooter a bit, and took a shower. I just had a close call as I feel very hard on wet tiles.
Madgwick is great for the 9DoH senors and aerial flight, but i am still thinking it may be a bit of overkill for a robot that requires one or only two axis balancing input. A restricted one-axis complimentary solution might be more appropriate -- simpler and faster.
Quaternions certainly seem to be a preferred data format for rotation in 3 dimensions with the possibility to add translation in 3 dimensions. So that allows the HoverFlyGimal to use its USB to make it a stand alone input device for a computer display. It could be used for all sorts of 3D game inputs (similar to the Wii, or placed on a set of 3D goggled to adjust video to head motions).
I really want to load and test this code. I guess I will have to either figure out how to compile C# in Linux or use Windows 7 to support the DCMviewer.
Heater seems to have added a few creative touches of his own.
1. He has coded a Madgwick graphic emulator that I don't fully understand. Instead of getting data from an IMU he has somehow provided synthesized data.
2. He provided links to a 4 hour series of lectures that explain how to use Quaternions without the use of Pi and squareroot and maybe no sine, cosine, and tangent. That certainly does seem more optimal for the usual microcontroller, but the Propeller does include Trig log tables. So i am stuck wondering if this is a good working solution or an elegant maths presentation that might slow calculation. I just don't know.
I mention these things because everyone learns a bit differently. I may not follow the same path that someone else prefers.
I feel more comfortable with thinking in terms of the 'Rotor' which is represented in Euler's formula as cos_x + sin_xi and equal to e to the ix power. http://en.wikipedia.org/wiki/Euler's_formula
Simply put, the maths of 3D rotation has a lot of ways to be represented. Some work better with humans and others work better with microcontrollers.
So it all becomes a game (or puzzle) of how to optimize what we have learned for certain robot.
Take it easy for a while. That scooter sounds like a risky proposition under the circumstances.
In the mean while:
Madgwick is great for the 9DoH senors and aerial flight, but i am still thinking it may be a bit of overkill for a robot that requires one or only two axis balancing input. A restricted one-axis complimentary solution might be more appropriate -- simpler and faster.
I suspect you might be right. At least as far as getting balancing going we know it can be done with a very simple control loop, even made of op amps.
On the other hand what happens when you want to move from just balancing to moving around and steering? Then you pretty much have all the same requirements as a copter or plane.
So, if Madgwick can be gotten to run on your MCU then why not?
...a Madgwick graphic emulator that I don't fully understand. Instead of getting data from an IMU he has somehow provided synthesized data.
There is not much to it. It runs the Madgwick filter/fusion algorithm. It provides simulated gyro, accel, and compass inputs to the filter. It draws a simple box on the screen oriented according to the quaternion output by the filter.
Those input can be as simple as static values. Representing the case that the "virtual" IMU is sitting still. Or it can apply slight changes in compass and accelerometer inputs.
What I do just now is set gx to 1 indicating gravity downwards. Then slightly oscillate gy and gx to simulate a pitch and roll motions. Then apply a static "north" input from the compass or have it rotate around the vertical axis.
This is somewhat simulating what you might get from an IMU in a copter or balancing bot.
It's fascinating to tweak around with the gain of the madgwick filter, and the update rate and see how it responds to different inputs. I should put some controls on the screen so you can try them for yourself easily. Early days yet...
...links to a 4 hour series of lectures that explain how to use Quaternions without the use of Pi and squareroot and maybe no sine, cosine, and tangent.
Actually those lectures are about how the quaternian maths works for anyone who wants a derivation. It's hard work. None of that is required to use the quaternians. I imagine most users of an IMU filter like Madgwick will immediately turn it's quaternian output to Euler angles for use in their control systems.
As for all those sin and cos, as it happens there is no trig functions in the Madgwick code. It's pretty well optimized. There are a few divides which is a pain but they can be removed it you have already normalized the compass and accel inputs. There is also a inverse square root function that can be removed.
Perhaps I should start a new thread for my "Madgwick Roundabout" tool.
Well, I have been trying to run Heater's JavaScipt code, but am clueless. I do have gjs working in Debian. Please advise as I do want to get this actually running.
Meanwhile, I am trying to figure out how to compile the C# alternative.
I am up to my eyeballs in new software. argh.........
Madjwick does have a few squareroots, and Heater's quaternion video series attempts to exclude square root calculations, which may not really be optimal on the Propeller (simply look up a log and divide by 2).
and of course, Euler drives me nuts as he is only the most prolific author of math papers that ever was.
References to 'Euler Angles' have been frequent, but search engines don't exactly tie them into rotation.
Euler Angles are simply a set of angles in relationship with the X, Y, and Z axis.
{ The following within brackets is all wrong, please ignore. It is just here for thread continuity.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
What I do gather is the traditional sine of an angle plus cosine of angle that represent a position on a unit circle, was extended by Euler from the everyday x-y plane to the imaginary number x-i plane. (and he did a lot more with it after that).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
}
Euler also was pretty much a leader in creating the modern set of math symbols that are accepted today, and contributed to making the signs for pi, e, and i standard. So some references to Euler Angles may have less to do with his mathmatics than accepting his standard of representation. (At least, that is what my History of Mathematics text mentions).
I am trying to stay focused on only what Euler offered to rotation as applied to gyros, accelerometers, and compass in this context are only concerned with rotation. One can get lost in Euler jumping from one topic to another (I have been through this before).
Quaternions allow you to avoid the Euler Angle representations for X, X, Z and pretty much handle it all with vector maths instead of trig. But I do admit, just adding 5 degrees to 22 degrees to get rotation on one plane in trig is very seductive when the alternative is using vector dot products and vector cross products.
To run Madgwick_webgl just install The google-chrome browser or firefox and load up the index.html file from the unpacked tar ball.
I do not use the chrome browser that comes as a Debian package as I have had trouble posting to these forums with it. Rather I use the download from Google itself: https://support.google.com/chrome/answer/95346?hl=en
Not sure if webgl works out of the box with Firefox (It may need enabling or something) I notice it does with the Iceweasle browser in Debian Jessie.
Meanwhile, I am trying to figure out how to compile the C# alternative.
You should not have to recompile C# programs to run on Linux. Just run the given .exe file under Mono. "$ mono someprog.exe". I don't have much experience with this but it works for the HomeSpun Spin compiler, even on the Raspberry Pi:)
Madjwick does have a few squareroots...
Not really. Madgwick uses a very cunning little bit of code to calculate inverse square roots of 32 bit floats using only two float multiplies and some integer manipulation. It looks like this:
float invSqrt(float x) {
float halfx = 0.5f * x;
float y = x;
long i = *(long*)&y;
i = 0x5f3759df - (i>>1);
y = *(float*)&i;
y = y * (1.5f - (halfx * y * y));
return y;
}
Aside: We should do this in Spin. Or it should be in the F32 object.
References to 'Euler Angles' have been frequent, but search engines don't exactly tie them into rotation.
You did not search very hard. First google hit for "Euler angles" is wikipedia http://en.wikipedia.org/wiki/Euler_angles which tells you exactly what they represent in the first paragraph or two.
Okay, i have been confused about Euler Angles. I previously looked at the Wikipedia article and didn't fully appreciate it.
It is obvious now that they have nothing to do with imaginary numbers. That was a separate subject that Euler discovered --- related, but separate. I at least warned everyone that Euler was into many, many subjects and pretty much seems to have created a lot of defacto standard terminology (apparently by publishing so much).
Mainly, I do believe I can get a Quaternion or a set of Euler Angles, but after that it requires a comparison with where you desire to go and at what rate. And that is the NEXT step after getting a nice gizmo presenting an image on a computer screen... a real robot in motion.
So it seems the next task is --
A. Quaternions motor control
or
B. Euler Angles to motor control
And your JavaScript demo may show more clearly how Quartenion data applies. ( I just need to keep reading and re-reading until this stuff sinks in. Reading the code may actually be clearer than reading the math essays.)
And I do appreciate that you have demonstrated that Madjwick is working and ready to be applied to motor control.
Comments
Except good percentage of my ramblings are actually correct, for example:
Where is the center of rotation on a balancing bot? Through the centers of both wheels. Because it not true. Except in the Loppyverse where Loopy physics applies:)
Basically, gravity is applying a force at the centre of mass to rotate the robot about the wheel axles, while the motors apply a force at the wheel axles to rotate the robot about the centre of mass. So I cannot agree that the resulting centre of rotation is at the wheels.
See analysis of "inverted pendulum on a cart" here: http://en.wikipedia.org/wiki/Inverted_pendulum
Here is an experiment you can do to convince yourself of your error:
Take a broom. Balance it upside down in you fingertip, brush end up in the air.
Observe that as you desperately try to keep the thing balanced upright the base, your finger end, is thrashing around a lot. The brush end might not be moving as much quite often. Observe how the broom seems to be rotating about a point somewhere along it's handle length.
Or watch a guy riding a tall unicycle. Notice how the wheel will often be oscillating backwards and forwards a lot while the guy on the seat at the top seems to be quite stable. Where is the centre of rotation of the unicycle? Not at the wheel. Exactly. That is why you might want to put the IMU sensors at the point on the body where least acceleration is going on. As you say. But that point is not necessarily at the bottom between the wheels on a balancing bot. Nobody mentioned the Raspi here. That is a nightmare going on in your head not in reality
I do understand that you are referring to a dynamic center of rotation. This concept come up in boat design and airplane design. What I mentioned was passed along repeatedly in reading other's construction of balancing bots. They say put the IMU low and as close as possible to the axle. Remember that you have only one axis to deal with. I suspect that a Complimentary filer is quite adequate if that is all you are using. (But I really want to get Madgwick working anyway).
In boats, you have a center of gravity, a center of buoyancy and these are in constant motion. I have no idea where you might put an IMU on a boat. In aircraft, the wings and the hull would pretty much define a center for X, Y, and Z.
You may be right about the inverted pendulum moving the center of rotation. But would it be dynamic or stable?
The acceleration at the center of the axles is what is important for the accelerometers to measure and being as close as possible to that removes delays in measuring reversals. Just maybe I got tangled up with thinking that meant the center of rotation.
The objective remains keeping the Center of Gravity underneath the wheels.
Here is a link to what might be a better PID scheme of the whole balancing bot concept. This guy was recognized by NASA.
http://www.geology.smu.edu/~dpa-www/robo/nbot/bal2.txt
http://www.geology.smu.edu/~dpa-www/robo/nbot/
Here is a though experiment:
You balancing bot has all it's electronics and batteries at the head end. For the purpose of this thought experiment we are using a 50 kilogram car battery. Meanwhile our motors are really small and light and can only apply an insignificant driving force.
What happens?
The thing tips over a bit. The motors try to correct that. But being puny they are overwhelmed by the huge mass of that car battery.
The car battery now proceeds to fall almost vertically downwards pushing the motors out sideways rapidly.
Where is the centre of rotation of that?
Where is the point along the height of the bot that experience the least acceleration?
Clearly the battery at the head end was falling vertically and accelerating at almost 1g straight down.
Meanwhile the wheel end was accelerating violently sideways.
The point of minimal acceleration was somewhere in between head and wheels.
The centre of rotation was where?
Your assertion was that "You don't need PID to balance a bot"
Your link clearly shows a PID controller in the first schematic.
Notice in that block diagram how tilt and rate of tilt signals are summed into create the torque demand signal?
Further down he page text Dale explains in detail how P and I and D are all in there. Ah yes, ignore me. Get that soldering iron on. That is not clear to me.
Why? He is the guy with the bowling ball balancing bot that he rides around seated on. And he is the guy that said when he placed it high, he got nothing but heart ache.
http://www.wa4dsy.com/robot/iroll
Don't be such a theorist.\\
++++++++
Actually, my whole balancing bot is built except for the Hoverfly unit. But I don't have encoders on the motors, so that will be very telling.
I did a lot of searching to see if I actually needed motors with encoders and concluded no. Later I will add the motors with encoder - either after a dismal failure or out of the desire to have an all-terrain balancing bot. IOW, this project is going to be long-haul and I expect a second revision where more money will be invested in good hardware.
NOTE -- Dale's IROLL mentions it is important to place the IMU in the center of pivot. and his first project moved repositioned the the acelerometer next to the axle. This is trial and error observation, not theory. He also mentions the issues of PID motor control need for inclines in his first analog balancing bot.
It might be fool hardy to argue with a guy who has actually done it and got it working in practice.
Looking at his block diagram we can see that if the accelerometer is at the head end it will have less acceleration to report and hence less effect on that PID loop. As we have seen the wheels can be thrashing to and fro quite rapidly whilst the big mass at the top barely moves. and... Hmm...that's not making sense to me. Those two statements seem contradictory. If he is riding on the thing, I have seen that video, then the c of g of the whole machine is probably not next to the axle.
I guess it's time to start building and experimenting. I'm sure I have some motors around here some place...
I just have been working diligently to acquire a set of web references that will get me off to a good start. I certainly do get that the Center of Gravity changes when somebody sits in the chair. But there is a bigger acceleration swing of the axle axis as you get farther away from it.
Good night it is 4:47am
The main issue is that when placed in the wrong location, the data accumulates acceleration data about centrifugal forces that must be filtered out.
So it seems that for an inverted pendulum, the best sensor placement is 'under the the center of gravity' and centered on the wheel axis for a one axis solution.
Why so? The target is to measure the angle and realign the center of gravity under the wheel axle. This sensor placement reduces the data management problems. One uses less noise filtering and avoid having to consider something like calculating an asymmetrical offset with vector calculations ( I don't really want to ponder how to do that.)
For a two-axis solution, it would be ideal to have it under the center of gravity and centered inside the ball. But that would be a very awkward place to install the IMU. So it seems that the second best place for the IMU is directly above the ball's center, so that it is not getting bad data about rotation and it is below the center of gravity.
@Heater
Does that explanation meet your approval?
@Everyone
One can't quite trust the web and the internet to get things right 100% of the time. Errors in information can propagate like wildfire in a 'cut and paste' world. The main point here is that the balancing bot is really a wonderful learning platform and so are IMUs. Lots of physics, mechanics, sophisticated maths, and even a touch of real rocket science.
I suspect Dale meant to say keep the sensor low and under the center of gravity, but just didn't quite express well what he knew would get better results.
Balancing bots are simply chasing the center of gravity at all times to remain upright.
Question is what actually do you get out of the accelerometer and what does it mean?
Some thought experiments:
Consider a stick, say one meter long, standing upright. It is constrained to only be able to fall to the left or right. There is a 1 dimension accelerometer fixed to the stick such that it measures left/right acceleration.
1) At balance what does the accelerometer read? Nothing. Does it matter where along the stick the accelerometer is? No.
2) If the stick his held stationary at a 45 degree inclination what does the accelerometer read? Basically 0.7g. That is sin(45) times the acceleration due to gravity. In general the acceleration reported is g*sin(theta) for static positioning at various angles.
We don't have a static system so that's no good. Let's allow the stick to start upright and fall over:
3) With the accelerometer at the top of the stick, what does it read as the stick falls down to horizontal?
Well, I'm not sure. If the accelerometer were just dropped in free fall it would always read zero as it has no left/right motion.
But here the stick is pushing it left or right as it falls. So presumably it registers something. But on the other hand it's orientation is changing from left/right to up down as well. At the point in time the stick reaches horizontal it is in free fall, at least at the c of g of the stick.
Can anyone guess the shape of the graph of accelerometer readings during the fall?
4) How does this change as we position the accelerometer lower down the stick?
Clearly if the accelerometer is at ground level it never moves but it's reading change from zero to 1g as it is rotated over 45 degree. What about at other positions?
5) We add motors and wheels to our stick to propel it left and right. What is our accelerometer measuring now?
Clearly it is mostly measuring the acceleration left and right, due to the motors, of the base of the stick when positioned at ground level. That could be rather large and dramatic movements, even when the top of the stick is hardly moving.
But what about when we put the accelerometer at the top. Now it measure "head" movements. These could even be in opposite direction to the "tail" because our stick will rotate around it's c of g so if the base is pushed left the head will go right.
Man this is complicated!
https://www.youtube.com/watch?v=rwGAzy0noU0
or perhaps use a jig saw:
https://www.youtube.com/watch?v=zBOVVwYwKqc
Let's make it more complicated:
https://www.youtube.com/watch?v=BJ7_fFABc9s
P = Proportion
I = Integrate
D = Differentiate
The three components can combine in many ways. Solutions can be mechanical, analog, and digital.
We are trying to develop control solutions for design, not just point of phenomina that don't require control.
A. I have tried to clarify the balancing bot PID requirements by refering to two rather good sources == Dale's Homemade Robots and NBot, a NASA recognized balancing bot.
>Dale is a pragmatic 'old school' machinist that relies on proportion, integration and differentiation as required --- not a 'software packaged concept' of PID.
>The NBot has been subject of peer review by some of the best, so I feel it is an above average presentation and should be studied in detail.
B. Both indicate that there are situations where you can remove more than one of the elements of P, I, and D or you can double up on more than one of the elements. IOW, the internet buzz of PID this and PID that is not a full understanding of which components apply and where.
> Dale prefers OP-amps and getting his PID in analog form rather than bothering with the overlay of digital. I find this an excellent contrast to the digital solution and a means of letting analog or mechanics do something better on occasion and have the digital do what it does best.
>>>>>>Bear in mind that Newtonian maths is roughly three centuries old and the digital age of its application is rather new. PID can and may best be done mechanically or via analog, with the digital aspect only coming into play when older solutions under-perform. Try a cafeteria-style approach of understanding where the P, I, and D may come from a combination of elements (forget all that fuzzy logic nonsense as it justifies something that works but is not wholly understood.)
>NBot is backed up by a Geologist that has a deep resume in imaging seismic data. So his vision of a balancing bot is inclusive a wider view than 'getting the PID just right' from a code example.
C. I have pretty much viewed the PID of motor encoder feedback as a separate solution from the PID of IMU axis feedback.
>The realitly is that [a] Dale mentions in his analog balancing robot, a limited flat surface case of PID can be done for only flat surfaces AND he mentions the need for an expanded or additonal PID solution for the sloped surface via the use of motor encoders.
>NBot seem to provide a good diagram of the whole - PID inclusive of the IMU input and the motor encoder input. PLEASE NOTE - the web is awash with PID examples only for motor encoders, not a combination of feedback inputs.
What I am trying to say is two things.
1. Don't hang on to the web-centric notions of PID and the one and only solution to PID. In real design more complex models evolve from the realities of making a better product and older technologies that work well.
2. I am trying to build an encoder-less solution first with a limited PID model. And then, after I find out what it does -- I will purchase motors with the right torque and encoders for a more refined robot.
I don't want to waste money on buying several pairs of motors and encoders as these items are a major portion of the expense. I have a pair of motors that seem okay for the first phase.
As you can see, rather than just looking at the whole project as a lump, I am taking it in phases that conserve time and money while making learning optimal.
And I am trying to take a very pragmatic approach to researching what information I rely upon.
One cannot learn as much by just grabbing any old 'How to' tutorial that fits what you have in your junk box or your personal passions for one project. Be a realist, be pragmatic.. that is real engineering. And above all, don't disdain the topics of mechanics or analog as they both have long provided a series of successes that built up to the digital age.
It is a 'right tool for the job' approach that can be very rewarding.
What? Why would you be annoyed. I'm not trying to obscure anything. I'm trying to get a clear view through your muddled statements to whatever it is you might actually mean
Your assertion was that we don't need a PID to balance the bot. However you have not answered my question as to what other control technique you would like to use. Whist at the same time your oft' quoted examples, Dale's bot and the NBot both use PID.
Now when I say "PID" I use the term loosely, which I guess could have confused you. That can be"proportional", "integral", or "differential" or any combination of any of them. You can always set their gains to zero to turn them off if you don't need them. Or just don't include that op amp or line of code.
So far nobody has talked about implementation, digital or analogue. Well, except my statements that "Concord was stabilized by a bunch of op amps....Hence my search for the most simple circuitry that can do this."
For a simple control schemes like PID on a bot like this it makes no difference if it's done with analogue or digital technology. Dale has demonstrated how to do it with op amps. But if you are starting with sensors that have digital outputs does it not make more sense just to write the code into the same processor that is handling that?
Newtonian maths may be old. So what? That has no bearing on whether we build a digital or analogue PID controller. That is an interesting statement. Yes fuzzy logic is used where people cannot model the system they are trying to control. However I would guess PID is applied in many such situations as well. Or applied by people who don't have the mathematical chops to create a model of the system anyway.
Are you saying that you understand the inverted pendulum problem? Can you tell us why an inverted pendulum cannot be stabilized with just proportional or differential control alone but can be stabilized by using both? Neither can I. If I don't understand the system what difference does it make if I use PID or fuzzy control, as long as I can get it to work?
I don't care about the resume of the NBot creator, only whether the NBot works or not (Great machine by the way). As for "wider view than 'getting the PID just right'", that is exactly what the NBot creator did. Here is the code he uses:
/* define constants. In the demo these were set with a knob */ ... ... ... void balance() { while(1) { /* loop forever */ angle = read_analog(TILT_SENSOR); angle_velocity = angle - last_angle; last_angle = angle; wheel = read_wheel_encoder(); /* wheel = read_encoder()-profiler() */ velocity = wheel - last_wheel; last_wheel = wheel; torque = (angle_velocity * K1) + (angle * K2) + (wheel_velocity * K3) + (wheel * K4); pwm(torque); msleep(40); /* sleep 40 milliseconds */ } }Notice the comment in the code "define constants. In the demo these were set with a knob". Seems nobody knows how to do this except by trial and error and getting the PID just right' is the order of the dayP.S. If you are wondering why both proportional and differential control are required to stabilize the balancing bot, not just either alone, then this nice chap from MIT explains it here : http://www.youtube.com/watch?v=D3bblng-Kcc
What I did attempt to say.. has been subject to much clarification. Don't you get it?
I suggested that one might remove the PID that is involved in the motor encoder. I NEVER said or intended to assert that no PID was necessary.
You are simply being excessively pedantic, thus the snipe about less beer and more thought.
Yes indeed, you use terms loosely when it is to your argumentative advantage and then push others into a corner with a narrow interpretation of their usage. Clever, but transparent, and getting to be very old.
What is my alternative to PID? I didn't offer one as I wasn't making the claim you have been running on and one with.
I have presented the facts FOR the benefit of everyone that might desire to learn more about IMUs and balancing bots. But you turn this into a Heater versus Loopy circus. I have no idea why.
The point about Newtonian maths is not that it is worn out by being 300 years old, but that it is profoundly duriable and has provide 300 years of technical innovation, and may be applied via means other than digital. Robotics is a marriage of digital, analog, and mechanics. Doing everything digital may actually be less than optimal... EVEN SLOWER and less stable, and often more $$$.
With that out of the way, let's continue.
P.S. Me pedantic? Never
real speed and measured leaning angle and changes the amount of lean to get it to move. Farther down that page past all the pictures
he gives an explanation and a block diagram of his system setup. He is using only P and I in his system.
I did notice that, steppers are an interesting variation. Instead of encoders and quadrature to determine position and speed, the mircocontroller keeps track of the steps ... so it had PID feedback via another method.
It really is a very slick robot. The NEMA21 steppers a bit heavy, but being low they lower the overall center of gravity. And they have a nice cap between them that you can place an IMU in for best performance. Motors with encoders tend to be long, whereas the stepper motors are flat. So you get a narrower robot without having to to copy the NBot configuration that adds gears and a pair of offset motors.
My only problem with using stepper motors is that I have to locate a pair of stepper motor drivers. I think I have a pair that I could use in my junk. It might be a good second phase instead of geared motors with encoders. Not only lower budget, it is an easier build.
Any day now, FedEX will deliver my HoverFly Experimenter board and I can start trying a few things with what I have got.
But I have grown very fond of that Raspberry Pi bot as I can finally see it doing something dramatically useful with the visual recognition. This is way beyond the traditional line follower and maze runner kind of robot. It is more likely to survive navigation in a real world environment.
Thanks for mentioning. I think we will see more of trying to emulate it with a Propeller. I will go shopping for some stepper motor controllers and find out how they like their PID control.
Using only P and I? That is a point I was trying to make. Proportion, Integral, and Derivative don't have to be taken together. But new learners might thing so.
++++++++++
Also, I really do think it is far easier to configure PID if you can reset the parameters via wifi. So I am considering putting my MR3020 onboard the balancing bot to allow a wifi link to reconfigure the wifi parameters.
And I want to use a Bluetooth link to a game controller as the remote. The investment is much cheaper than R/C remote control and my 27Mhz R/C receiver has a wire antenna of about 1 meter. Bluetooth will be a cleaner build, and cheaper too. (DealExtreme can deliver both parts for less than $25 USD... a Bluetooth serial reciever for $10 USD and a six DOF game controller via Bluetooth for $12 USD or less.)
In sum, I could stay busy for a long time with all this. For now it is the baby steps to getting started.
I understood the source of confusion all along. Could have cleared it up right away if the challenges didn't get more and more fierce.
I am a new old learner. I should have said he sets the Derivative to 0.
Very, very nice and tiny 9Dof with the Propeller and USB included. That makes the building pretty much a 15 minute job to complete.
But I have tons to learn. I guess the starting point is to see what the board does on its own. It is supposed to come loaded with software that will output raw data back through the USB to a computer via a serial connection.
Here is a rough To Do List.
1. Proof of life testing -- see if I can get Raw sensor data through serial port
2. Getting a Madgwick filter test bench
3. Figuring out how to use the Quaternion data to drive an dual H-bridge and/or two stepper motors
4. Figuring out how to insert PID to the motors
+++++++++++++
I do have another order in transit from DealExtreme that includes a $10Dof. If anyone already has a Propeller, I suspect that the code that DealExtreme provided for Proof of life testing might be adapted to that.
And then everything could be followed along in parallel.
Please note, that the first step is to get the data output to be stable, and then the second is to deal with driving the motors. You will likely get lost if you try to do this all at one go.
So far I have spend the evening on my '15 minute' build. But it is coming along nicely. I need to sitting and study the schematic and ponder what I have done.
HoverFly sent me a nice black T-shirt with their logo on it just to offset the international shipping. The only problem is that yesterday we had a policeman beaten to death trying to break up a Triad dispute. And today the police seem to arresting dozens of males in black T-shirts in Taipei. I think I will wait a month or two before I am tempted to wear it.
+++++++
I did study the Madjwick code for 6DoF from his 2007 paper today and it is not that difficult if you can grasp that Jacobian matrices are partial differentials. It pretty much just initializes, gets the accelerometer readings, prepares them for the combining with the gyro readings, gets the gyro readings, preps them, and then combines the two for output.
needs to be aware that his code checks for the first free comport above 4 or 5. I just manually enter my comport into his C# source code.
Still don't have a bot balanced and I hope you get better Loopy. I put this here because I didn't want to interrupt Photronix thread.
EDIT: Jason has posted code for the Hoverfly gimbal board on post# 59 here. I would use his code instead of what I posted here.
Thanks for the code. I am excited about it.
As far as myself, it just seems that I have to either lay down or stand up for a week or two while I regain strength in the back. I got out today, walked the dog, had a latte at a nearby Starbucks, picked up clean laundry, rode the motorscooter a bit, and took a shower. I just had a close call as I feel very hard on wet tiles.
Madgwick is great for the 9DoH senors and aerial flight, but i am still thinking it may be a bit of overkill for a robot that requires one or only two axis balancing input. A restricted one-axis complimentary solution might be more appropriate -- simpler and faster.
Quaternions certainly seem to be a preferred data format for rotation in 3 dimensions with the possibility to add translation in 3 dimensions. So that allows the HoverFlyGimal to use its USB to make it a stand alone input device for a computer display. It could be used for all sorts of 3D game inputs (similar to the Wii, or placed on a set of 3D goggled to adjust video to head motions).
I really want to load and test this code. I guess I will have to either figure out how to compile C# in Linux or use Windows 7 to support the DCMviewer.
Heater seems to have added a few creative touches of his own.
1. He has coded a Madgwick graphic emulator that I don't fully understand. Instead of getting data from an IMU he has somehow provided synthesized data.
2. He provided links to a 4 hour series of lectures that explain how to use Quaternions without the use of Pi and squareroot and maybe no sine, cosine, and tangent. That certainly does seem more optimal for the usual microcontroller, but the Propeller does include Trig log tables. So i am stuck wondering if this is a good working solution or an elegant maths presentation that might slow calculation. I just don't know.
I mention these things because everyone learns a bit differently. I may not follow the same path that someone else prefers.
I feel more comfortable with thinking in terms of the 'Rotor' which is represented in Euler's formula as cos_x + sin_xi and equal to e to the ix power. http://en.wikipedia.org/wiki/Euler's_formula
Simply put, the maths of 3D rotation has a lot of ways to be represented. Some work better with humans and others work better with microcontrollers.
So it all becomes a game (or puzzle) of how to optimize what we have learned for certain robot.
Take it easy for a while. That scooter sounds like a risky proposition under the circumstances.
In the mean while: I suspect you might be right. At least as far as getting balancing going we know it can be done with a very simple control loop, even made of op amps.
On the other hand what happens when you want to move from just balancing to moving around and steering? Then you pretty much have all the same requirements as a copter or plane.
So, if Madgwick can be gotten to run on your MCU then why not? There is not much to it. It runs the Madgwick filter/fusion algorithm. It provides simulated gyro, accel, and compass inputs to the filter. It draws a simple box on the screen oriented according to the quaternion output by the filter.
Those input can be as simple as static values. Representing the case that the "virtual" IMU is sitting still. Or it can apply slight changes in compass and accelerometer inputs.
What I do just now is set gx to 1 indicating gravity downwards. Then slightly oscillate gy and gx to simulate a pitch and roll motions. Then apply a static "north" input from the compass or have it rotate around the vertical axis.
This is somewhat simulating what you might get from an IMU in a copter or balancing bot.
It's fascinating to tweak around with the gain of the madgwick filter, and the update rate and see how it responds to different inputs. I should put some controls on the screen so you can try them for yourself easily. Early days yet... Actually those lectures are about how the quaternian maths works for anyone who wants a derivation. It's hard work. None of that is required to use the quaternians. I imagine most users of an IMU filter like Madgwick will immediately turn it's quaternian output to Euler angles for use in their control systems.
As for all those sin and cos, as it happens there is no trig functions in the Madgwick code. It's pretty well optimized. There are a few divides which is a pain but they can be removed it you have already normalized the compass and accel inputs. There is also a inverse square root function that can be removed.
Perhaps I should start a new thread for my "Madgwick Roundabout" tool.
Meanwhile, I am trying to figure out how to compile the C# alternative.
I am up to my eyeballs in new software. argh.........
Madjwick does have a few squareroots, and Heater's quaternion video series attempts to exclude square root calculations, which may not really be optimal on the Propeller (simply look up a log and divide by 2).
and of course, Euler drives me nuts as he is only the most prolific author of math papers that ever was.
References to 'Euler Angles' have been frequent, but search engines don't exactly tie them into rotation.
Euler Angles are simply a set of angles in relationship with the X, Y, and Z axis.
{ The following within brackets is all wrong, please ignore. It is just here for thread continuity.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
What I do gather is the traditional sine of an angle plus cosine of angle that represent a position on a unit circle, was extended by Euler from the everyday x-y plane to the imaginary number x-i plane. (and he did a lot more with it after that).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
}
Euler also was pretty much a leader in creating the modern set of math symbols that are accepted today, and contributed to making the signs for pi, e, and i standard. So some references to Euler Angles may have less to do with his mathmatics than accepting his standard of representation. (At least, that is what my History of Mathematics text mentions).
I am trying to stay focused on only what Euler offered to rotation as applied to gyros, accelerometers, and compass in this context are only concerned with rotation. One can get lost in Euler jumping from one topic to another (I have been through this before).
Quaternions allow you to avoid the Euler Angle representations for X, X, Z and pretty much handle it all with vector maths instead of trig. But I do admit, just adding 5 degrees to 22 degrees to get rotation on one plane in trig is very seductive when the alternative is using vector dot products and vector cross products.
To run Madgwick_webgl just install The google-chrome browser or firefox and load up the index.html file from the unpacked tar ball.
I do not use the chrome browser that comes as a Debian package as I have had trouble posting to these forums with it. Rather I use the download from Google itself: https://support.google.com/chrome/answer/95346?hl=en
Not sure if webgl works out of the box with Firefox (It may need enabling or something) I notice it does with the Iceweasle browser in Debian Jessie. You should not have to recompile C# programs to run on Linux. Just run the given .exe file under Mono. "$ mono someprog.exe". I don't have much experience with this but it works for the HomeSpun Spin compiler, even on the Raspberry Pi:) Not really. Madgwick uses a very cunning little bit of code to calculate inverse square roots of 32 bit floats using only two float multiplies and some integer manipulation. It looks like this: Aside: We should do this in Spin. Or it should be in the F32 object. You did not search very hard. First google hit for "Euler angles" is wikipedia http://en.wikipedia.org/wiki/Euler_angles which tells you exactly what they represent in the first paragraph or two.
It is obvious now that they have nothing to do with imaginary numbers. That was a separate subject that Euler discovered --- related, but separate. I at least warned everyone that Euler was into many, many subjects and pretty much seems to have created a lot of defacto standard terminology (apparently by publishing so much).
Here is a practical paper that prefers Euler Angles for flight control..Understanding Euler Angles.
www.pololu.com/file/0J586/AN-1005-UnderstandingEulerAngles.pdf
and the same author on Understanding Quaternions
https://www.chrobotics.com/.../AN-1006-UnderstandingQuaternions.pdf
Mainly, I do believe I can get a Quaternion or a set of Euler Angles, but after that it requires a comparison with where you desire to go and at what rate. And that is the NEXT step after getting a nice gizmo presenting an image on a computer screen... a real robot in motion.
So it seems the next task is --
A. Quaternions motor control
or
B. Euler Angles to motor control
And your JavaScript demo may show more clearly how Quartenion data applies. ( I just need to keep reading and re-reading until this stuff sinks in. Reading the code may actually be clearer than reading the math essays.)
And I do appreciate that you have demonstrated that Madjwick is working and ready to be applied to motor control.