Thanks for the ball bot link. Brilliant. Just what I had in mind.
Yes, I have seen balancing bots done with ping and IR distance sensors.
It may not be a Kalman filter exactly but you certainly have balance sensors and hopefully a brain to process their data.
Yeah, that's my point. Seems my primary balance sensor is some goo floating around in some tubes in my ears. Then I have other inputs like the pressure on my heel and toes or vision. They don't always agree:)
As for my brain, God knows what is in there but for sure there is no Kalman filter. Even if the results might look like one.
Now, balancing a bot on two wheels or a ball is the same inverted pendulum problem as propelling a rocket, like a Saturn V, for example. As far as I know they did not have the computational power in Saturn V days to do Kalman filters and such. Ergo, it can be done without it.
Whilst we are at it the Concord was stabilized by a bunch of op amps.
Hence my search for the most simple circuitry that can do this.
Of course now a days the most simple circuitry may not make any sense when huge piles of compute power are available in MCUs very cheaply and the software is available for free.
Except of course if you want to do something I have not seen yet which is an inverted pendulum that balances in both the x and y directions. E.i. a bot riding on a ball.
It is possible that all these accelerometers, gyros, kalman filters and so on are overkill. I have seen such balancing bots managing to stay upright with nothing but a "bang-bang" controller. No micros or funky algorithms at all. Sorry I cannot find a link to such at the moment.
Seems I manage to stand upright and walk and for sure is no kalman filter anywhere in my body.
Well, one can indeed build a balancing bot without gyros. But they are pretty well restricted to flat ground. People have used ultra-sonics and IR distance sensors... often in pairs. There are even flight controllers that locate the horizon by use of heat sensors to recognize the difference between sky and ground.
Of course, when you have a robot that flies or swims, measuring distances to surface become difficult.
The Kalman filter seems to be more of an ivory tower approach rather than a pragmatic working configuration.
I have been reading one developer's other projects including an analog balancing bot. Visit 'Dale's Homemade Robots' for a rather creative and understated site by a master builder. He tends to mix analog with digital solutions in a way that makes sense.
Which is hardly surprising because the first thing it does is normalize the acceleration measurement by taking the square root of a_x squared + a_y squared + a_z squared, which is zero, and the dividing by it !
Basically if your IMU ever get's into free fall with all accelerations equal zero this code explodes.
That aside, I guess all we have to figure out where to put the fixed point. Anyone up to analysing that code and telling us what the number ranges are likely to be (apart from that 1/0 above) ?
Edit: Wait up a minute. What's going on with those global variables in there. They are never used because the parameters to filterUpdate have the same names.
Edit: A crude way to get the number ranges would be to write this out in Ada and run it against some test data. Then change the number types to fixed and see how many bits we need. Ada will flip out when something overflows. One could do this is C I guess by putting out of range checks in the fixed point math functions.
You are going to drive me crazy. First it was OpenWRT and routers now you have me itching to get hold of a bunch of accelerometers, gyros and magnetometers and see what can be done with this code.
The ultimate conclusion of that could be the worlds first self balancing router, how cool would that be
This new code takes care of the divide by zero issue I discussed in the original code as posted by Loopy.
There is a fully working example with sensor and output handling code for the mbed here: http://mbed.org/cookbook/IMU. But note that this uses the old buggy version of Madgwick's code.
That mbed code does demonstrate how to get roll, pitch and yaw out of the quaternian that Madgewick's algorithm computes.
I keep seeing that Madgwick's code is supposed to be open source. But I see no copyright notice or licence in any of the downloads. Except that I notice that Aaron Berk on the mbed page has slapped:
* @author Aaron Berk
*
* @section LICENSE
*
* Copyright (c) 2010 ARM Limited
On to his copy of the old buggy code followed by what looks like the BSD license.
I am still awaiting delivery of devices to test a 9DoF scheme. I ordered the HoverFly device with the Propeller on board as it cut through a lot of wiring. But DealExtreme has cheap 6Dof and 9Dof devices, delivers to Taiwan, and with Free shipping. So I purchased alternatives. One can get involved very cheaply with a DealExtreme device.
So far, I have just been hoping that F32 from Obex and/or Gcc maths will carry the day.
It seems it all goes to the problems of divide by zero or multiply by zero when you are working with sine and cosine. The phenomenum is referred to as 'gimbal lock'.
I have downloaded a lot of papers in search of the right code.
Madgwick seems to be the winner and one author claims to getting sampling rates into the thousands of Hz with an array of AVR chips (Arduinos and enhanced Arduino clones). Madgwick in his paper is far more conservative at something like 10 Hz.
Mahoney is 6Dof... okay, but you will find that Yaw readings are useless and an accelerometer just wanders on that axis... so the magnetic compass in 9Dof resolves the yaw problems.
It seems to me that if an Arduino work-alike clocked at 96Mhz can get sampiling rates into the fives of thousands, the Propeller might be able do likewise.
I am not going to post all the articles and links here. Some are obviously copyrighted and it just will lead to a huge speculative debate. Try to focus on what Madgwick is generating in open-source code. I think there may be GIT hub repositories that will be more productive than the 'blog-o-sphere'. Heater has apparently provided a trail of links to follow.
...one author claims to getting sampling rates into the thousands of Hz...
The is something I don't understand about these crazy claims for thousands of updates per second. Basically it sounds kind of pointless.
1) How fast to these sensors sample and how fast can we get the samples out of them. I would have thought there is no point in iterating the filter any faster than that. Just need one snap shot of the sensor readings and one iteration of the filter on that.
2) How fast, what frequencies, can we expect in these sensor readings? Even if they sample very fast a big heavy mass like a quadcopter acted on by the wind and it's motors cannot be accelerating faster than some maximum. There no point in iterating faster than what is required to measure those signals down to the noise levels of the signals. In fact bandwidth limiting those signals may be advantages in terms of remove high frequency noise. Like motor vibration for example.
3) What about jitter? If you are sampling a signal it's best to do it at an accurate fixed repetition rate (sample rate). Jitter in you sampling time is actually introducing noise into your input data. Are those guys taking care of this by sampling on some interrupt. Are they taking care that that interrupt is a high priority so that it's timing is not jittered by other activity on the processor? Or are they just running around in the typical Arduino sketch loop that will jitter all over the place as it handles other tasks as well?
Anyway, it's good to know that this algorithm can be run at a good lick on a small machine.
I think I would start out with this by fetching the data into an Propeller or other MCU and then forwarding it to the PC where one can experiment with the IMU algorithms.
Well, my concerns with a balancing robot is that the motor position optimally needs 250 Hz or better updates to work well. I am providing the article from GIT hub in PDF.
Madgwick's original paper mentions 10Hz updates... so falls short. But a comparative test of Madgwick and Mahoney on various devices indicated the numbers I mention.
Personally, I just want something over 250Hz for my own concerns. But for visual smoothness in graphic display 30Hz is minimal and 60Hz or more is optimal. Animation gets jumpy if too slow. Higher sample rates offer more leeway for special effect animations.
======
So I have concerns about an output bottleneck. But the I2C at 400Kb/s provides a raw data input bottleneck as well.
400Kbits/s/8 = 50 Kbytes/s and packets on data are 2 or 3 bytes.
So 50Kbytes/s/3 =1667Kpackets/s. And 9 sensors to read indicate a further reduction
@Heater
Don't be so narrow... These devices can also gather data to use for video animation. If i just lived for one project, microcontrollers would be a rather dreary world.
The topic is optimization, not 'How to build a balancing bot' per se.
The bench mark is to get Kalman filter equivalent performance out of microcontrollers that are small enough to be hand-held or on-board tiny bots.
Consider the idea that you want to animate a superhero's punch. You can take an IMU and replicate punches until you get data you like.. then apply it. You might even have multiple IMUs... one at the shoulder, one at the elbow, and one at the fist. It you want the punch in slow motion, you require a higher capture rate.
The IMU can be used in many ways ...
1. a flight controller.
2. a wireless joystick equivalent in 3 dimensional space
3. monitoring head motion in relationship to a visual display.
4. balancing robots
5. underwater ROV control
6. a camera gimbal controller
and so on.
BTW... I am NOT particularly interested in video games. But video can be a lot of other things. There are big bucks in short animated commercials or cartoons, and tons of creativity.
Loopy,
"Madgwick's original paper mentions 10Hz updates... so falls short"
Falls short how?
Yes, Madgwick's paper mentions 10Hz updates, only to say that the accuracy achieved at even that low rate may be acceptable in some applications.
The results he presents show that accuracy does not improve when going from 50Hz to 512Hz. See graphs in Figure 11. Where we are down to half a degree error. Of course it all depends on what rates of change you expect to be seeing in the system you are observing. Spin this thing at 1000 rpm and I'm sure it is never right!
Madgwick's sample rates were limited by the equipment used. The Xsens modules only allow sample logging to the PC at a max 512Hz. (Limited by their RS232 interfaces I guess). He was running his algorithm on the PC. I'm sure he only iterated it once for each sample from the Xsens.
Basically Madgwick says nothing about the performance of the code on any platform. Only that he tried to optimize the algorithm and the code for speed.
On this 6000 bogomips machine I can execute about 8 million iterations per second. I start to think 512 iterations per second might even be doable on the Propeller.
I can quite see that there are a billion uses for an IMU. What I was getting at is that the requirements on it's performance depend on the application. We cannot cover everything.
The bench mark is to get Kalman filter equivalent performance out of microcontrollers that are small enough to be hand-held or on-board tiny bots.
Sounds like a plan. Seems to have been done already, on Arduino, mbed etc. Although not on Propellers.
What we need to do is compile the available C code under propgcc and find out:
a) Does the resulting code even fit in HUB with useful space left over.
b) How fast does it run?
Okay, so it seems that the Propeller can perform.. now prove it.
In regards to noise and jitter. The original Kalman filter, and the Madgwick filter to optimize by filtering noise to some extent... just not sure what extent.
Regarding jitter and machine limitations... each situation is different.
Accelerometers for a balancing robot are best placed at the center of rotation.. otherwise you acquire added accelerations due to motion in any direction.
And I did see that the analog balancing ball robot included a 'mass dampening mount' for the IMU. He mounted it to a big chuck of steel that was glued to a chunk of neoprene rubber that was glued to a slice of hard plastic and to another chunk of neoprene rubber that was finally glued to the chassis. A clever 'old school' solution... similar to how building foundations use neoprene blocks to buffer from earthquakes.
Heater, just go to www.dx.com and buy yourself a GY-85 IMU to get started. Free shipping world-wide. (They even have a ton of Raspberry Pi stuff... ugh!~) You might also consider a Bluetooth to serial board to have a wireless link to your computer. They also have those for $6 or 7 USD.
@Heater
Take a look that the YouTube presentations in this Arduino discussion of balancing robots. There are a lot of useful observations and a demo of a Bluetooth to computer link that he used to configure PID and/or maybe with his remote controller.
It does seem the Bluetooth is for the remote control. so you might use the MR3020 that you have for the Propeller programing and configuration. It is a nice completely wireless solution.
Not quite. I have a long way to go. All I can do is read, learn and experiment. Or wait for one of the genuises on here to come up with something.
Have you seen Jason Dories thread on direction cosine matrix. I tried it as it uses the same IMU I was using in my quad copter. It seemed
stable to me.
The direction cosine matrix seems to be pretty much used as a 2 dimension array to sort out X, Y, and Z axis positioning. It can be useful in a flight controller or maybe in computer graphics. There seems to be a lot of recalculation of vector products (the dot product and the cross product).
When you rotate or flip a graphic image on a computer, the same matrix comes into play.. but in two dimensions (which might be a good place to start because it is simpler).
+++++++++
So far we have pretty much been targeting getting good position updates and have not discussed targeting moving from A to B or rotating from X to Y. So you have shifted over to a second topic, and not the only one involved in flight control.
I ordered all I need, but am still waiting for parts to arrive in the next week or so. So I cannot yet do anything hands on. Dave Hein just got his HoverFly Experimenter's Board as he is in the USA.... faster delivery. Out of the box, it came loaded with software that provides raw data outputs for all the sensors as a proof of life. .... nice to know.
And so, if you really want to get into the direction cosine matrix --
a. I am not up-to-speed on it. I just have peeked at the concept in the 2-D form for computer graphics; like zoom, rotate, and so on. I have a book that goes pretty deep into that.
b. Wikipedia is always a good place to get started with the fundamentals before you try to explore "How to" stuff. You need overview.
c. Be aware that the data is stored in a 2-D array in which the cosines represent X, Y, and Z of 3-D objects in space.
In some cases, operations are not what you might find in traditional linear matrix calculations. So try to get clear on what applies to your desired objective. (For example, the Madjwick filter is using Jabconial matrices to expedite calculation -- and they are specialized form of matrices as well.)
I think you desire understanding Vector as applied matrices.
Maybe transformation matrix is the desired topic, I am not sure, but it does look like the 3-D section applies.
++++++++++++++++++
Of course, one can use the same IMU and code as someone else and get a stable setup -- but learning what really goes on within the code begins to open up a variety of math topics.
Thanks for Jason's thread as I am seeing a lot more of what I need to know if I get into flight control. Please realize that the IMU is really a lot of overkill for a 2 wheel balance bot. I need only get data for one axis to remain upright.
~~~~~~~~~~~~~~~
Jason's thread is working with 200Hz inputs for flight control. And that is very useful in proving the Madgwick filter is worthwhile.
This link offers up food for thought in flight control.
And you really Must understand why and when Sine, Cosine, and Tan apply.
Also be aware that ArcSine, ArcCosine, and ArcTan are an entirely seperate maths... spherical geometry, not simple Trig. You may have to learn that subject as well.
Of course, one can use the same IMU and code as someone else and get a stable setup -- but learning what really goes on within the code begins to open up a variety of math topics.
Have you started to formulate a method to go about keeping a 2 wheeled robot balanced? I will be paying attention to this thread so maybe I can learn something about it from one of you genuises!
Have you started to formulate a method to go about keeping a 2 wheeled robot balanced? I will be paying attention to this thread so maybe I can learn something about it from one of you genuises!
Not exactly........
I suspect the easiest route these days is to borrow (steal) Arduino code.
Here is a teaser.
Parallax did publish a balancing bot in one of its texts, Chapter 6. But that did not incorporate an IMU.
Furthermore, since it only requires one axis (doesn't have Yaw axis stabiltiy issues), you can use a 6DoF or less and Mahoney filtering in lieu of Madjwick.
Frankly, while I have had interest for years in all this... the cheap 9Dof devices finally triggered really understanding what is what. So I am reading a lot and trying to catch up.
With one axis for balancing, there is no direction cosine matrix in play. Motion is maintained by a balance loop that is fed non-equilibrium information within limits to get forward, backward or rotational directions.
As far as I have followed all the talk here so far has been about figuring out which way you are pointing, IMU, Kallman, Madgwick etc. The output is a qaternian describing ones orientation.
When it comes down to balancing a bot, there is more to be looked at. How to control "verticalness" and remain upright. Use PID, or fuzzy logic or what?
Then one might be concerned about keeping the bot standing on the same spot or moving itself around. i.e position control. That may require a whole other control loop riding on top of the "staying up right" control loop. With its own sensors and feed back. Wheel encoders say.
Then one might want to steer left and right whist moving....how far do yo want to take this?
It might pay to look into the dynamics of the "inverted pendulum" and "inverted pendulum on a cart" to get more insight into that.
I'm kind of intrigued by the idea that a Madgwick filter outputs a quaternian. Just so happens that my favourite JavaScript library, ThreeJS, which is an API on top of webgl for doing 3D graphics in the browser recently adopted use of quaternians to describe and control 3D objects in space. Seems I could get the output from an IMU, run it through Madgwick and run that directly into an object in ThreeJS. Bingo IMU control of objects in the browser. For example browser based real time animations of your balancing bot or quadcopter motions.
Expect a Javascript version of Madgwick soon...
Loopy, I have to take issue with your statement about putting the IMU sensors at the centre of rotation of a balancing bot. Where is that? Top or bottom? Seems that when the bot is in a state of unbalance, following a disturbance say, then the base is doing most of the acceleration as it thrashes about trying to regain balance. Perhaps the head end is the more stable at that point in time.
I think I might spring for a FreeIMU board with the barometer on it at some point. That might have to wait until some other projects are out of the way...
The reason I choose that sensor is because I'm a lazy programmer and not that good at maths. With it I can choose between raw sensor data and/or filtered data. Also things such as the sampling rate.
I have been using ViewPort's DSO to monitor the sensor's output with and without motor vibration. I have tried my own basic version of a balancing bot with PID but as far as I got was it rocking back and forth under
my finger tip. But my interest in this in part comes from this guy's example of an object following balancing bot using a Raspberry Pi and another processor (you could use a Propeller)
Where is the center of rotation on a balancing bot? Through the centers of both wheels. Why is that so hard to envision?
Why is it important. While the gyros don't care, the accelerometers do. If they are off the axis, you have the addition of directional accelerations to the rotational acceleration. This is viewed roughly as a higher level of noise that must be dealt with.
Javascript? Maybe mention the Raspberry Pi while you are on pet themes. The above posting includes a balancing Raspberry Pi that is quite nice.....(blech! I want a Parallax solution.)
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. Can't seem to comprehend what Madjwick in Javascript will contribute... impress me with how stupid I am.
The reason I choose that sensor is because I'm a lazy programmer and not that good at maths. With it I can choose between raw sensor data and/or filtered data. Also things such as the sampling rate.
I have been using ViewPort's DSO to monitor the sensor's output with and without motor vibration. I have tried my own basic version of a balancing bot with PID but as far as I got was it rocking back and forth under
my finger tip. But my interest in this in part comes from this guy's example of an object following balancing bot using a Raspberry Pi and another processor (you could use a Propeller)
Rocking back and forth? That means you got it to stand up, and just need to learn a bit more.
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.
The PID motor control is a whole separate topic. But once you are satisfied with the operation without it, you can add it back in and fine tune. These things should be done in steps. You can't figure out the problem with everything working as the wobble could come from different parts of the code.
Much as I hate to admit it, the Raspberry Pi balancing bot has several nice features -- including a video camera line follower.
Comments
This little guy is closer to our level of fabrication, maybe?
Thanks for the ball bot link. Brilliant. Just what I had in mind.
Yes, I have seen balancing bots done with ping and IR distance sensors. Yeah, that's my point. Seems my primary balance sensor is some goo floating around in some tubes in my ears. Then I have other inputs like the pressure on my heel and toes or vision. They don't always agree:)
As for my brain, God knows what is in there but for sure there is no Kalman filter. Even if the results might look like one.
Now, balancing a bot on two wheels or a ball is the same inverted pendulum problem as propelling a rocket, like a Saturn V, for example. As far as I know they did not have the computational power in Saturn V days to do Kalman filters and such. Ergo, it can be done without it.
Whilst we are at it the Concord was stabilized by a bunch of op amps.
Hence my search for the most simple circuitry that can do this.
Of course now a days the most simple circuitry may not make any sense when huge piles of compute power are available in MCUs very cheaply and the software is available for free.
Thank you. Seems the robotisits on the Parallax forums are way behind the times. Very impressive.
Well, one can indeed build a balancing bot without gyros. But they are pretty well restricted to flat ground. People have used ultra-sonics and IR distance sensors... often in pairs. There are even flight controllers that locate the horizon by use of heat sensors to recognize the difference between sky and ground.
Of course, when you have a robot that flies or swims, measuring distances to surface become difficult.
The Kalman filter seems to be more of an ivory tower approach rather than a pragmatic working configuration.
In any event, the rolling ball robot has been done and done extremely well.
https://www.youtube.com/watch?v=bI06lujiD7E
I have been reading one developer's other projects including an analog balancing bot. Visit 'Dale's Homemade Robots' for a rather creative and understated site by a master builder. He tends to mix analog with digital solutions in a way that makes sense.
http://www.wa4dsy.com/robot/balancing-robot/ball-balancer
http://www.wa4dsy.com/robot/iroll
http://www.geology.smu.edu/~dpa-www/robo/nbot/
https://www.youtube.com/watch?v=n_6p-1J551Y
Add two more IMU fusion filters to the list... these seem to be 'hot' items.
Madgwick (published 2010, good for 6DOF or 9DOF and >2000Hz sample rate)
Mahoney (published earlier than Madgwick, almost as good 6DOF)
Discussed herein ===> https://github.com/kriswiner/MPU-6050/wiki/Affordable-9-DoF-Sensor-Fusion
At least as it stands you cannot just substitute fixed for float because it produces NAN as a result and fixed point cannot represent NAN.
If you initialize global variables and call the IMU function like so:
int main(int argc, char* argv[]) { a_x = 0.0; // accelerometer measurements a_y = 0.0; a_z = 0.0; w_x = 0.0; // gyroscope measurements in rad/s w_y = 0.0; w_z = 0.0; filterUpdate(0.0, 0.0, 0.0, 0.0, 0.0, 0.0); printf("%f %f %f %f %f %f\n", a_x, a_y, a_x, w_x, w_y, w_z); printf("%f %f %f %f\n", SEq_1, SEq_2, SEq_3, SEq_4); }You get: Which is hardly surprising because the first thing it does is normalize the acceleration measurement by taking the square root of a_x squared + a_y squared + a_z squared, which is zero, and the dividing by it !Basically if your IMU ever get's into free fall with all accelerations equal zero this code explodes.
That aside, I guess all we have to figure out where to put the fixed point. Anyone up to analysing that code and telling us what the number ranges are likely to be (apart from that 1/0 above) ?
Edit: Wait up a minute. What's going on with those global variables in there. They are never used because the parameters to filterUpdate have the same names.
Edit: A crude way to get the number ranges would be to write this out in Ada and run it against some test data. Then change the number types to fixed and see how many bits we need. Ada will flip out when something overflows. One could do this is C I guess by putting out of range checks in the fixed point math functions.
You are going to drive me crazy. First it was OpenWRT and routers now you have me itching to get hold of a bunch of accelerometers, gyros and magnetometers and see what can be done with this code.
The ultimate conclusion of that could be the worlds first self balancing router, how cool would that be
Seems Madgwick's IMU code repository is no longer in use: http://code.google.com/p/imumargalgorithm30042010sohm/
Updated code is now maintained here:
http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/
This new code takes care of the divide by zero issue I discussed in the original code as posted by Loopy.
There is a fully working example with sensor and output handling code for the mbed here: http://mbed.org/cookbook/IMU. But note that this uses the old buggy version of Madgwick's code.
That mbed code does demonstrate how to get roll, pitch and yaw out of the quaternian that Madgewick's algorithm computes.
* @author Aaron Berk
*
* @section LICENSE
*
* Copyright (c) 2010 ARM Limited
On to his copy of the old buggy code followed by what looks like the BSD license.
So far, I have just been hoping that F32 from Obex and/or Gcc maths will carry the day.
It seems it all goes to the problems of divide by zero or multiply by zero when you are working with sine and cosine. The phenomenum is referred to as 'gimbal lock'.
I have downloaded a lot of papers in search of the right code.
Madgwick seems to be the winner and one author claims to getting sampling rates into the thousands of Hz with an array of AVR chips (Arduinos and enhanced Arduino clones). Madgwick in his paper is far more conservative at something like 10 Hz.
Mahoney is 6Dof... okay, but you will find that Yaw readings are useless and an accelerometer just wanders on that axis... so the magnetic compass in 9Dof resolves the yaw problems.
It seems to me that if an Arduino work-alike clocked at 96Mhz can get sampiling rates into the fives of thousands, the Propeller might be able do likewise.
I am not going to post all the articles and links here. Some are obviously copyrighted and it just will lead to a huge speculative debate. Try to focus on what Madgwick is generating in open-source code. I think there may be GIT hub repositories that will be more productive than the 'blog-o-sphere'. Heater has apparently provided a trail of links to follow.
The is something I don't understand about these crazy claims for thousands of updates per second. Basically it sounds kind of pointless.
1) How fast to these sensors sample and how fast can we get the samples out of them. I would have thought there is no point in iterating the filter any faster than that. Just need one snap shot of the sensor readings and one iteration of the filter on that.
2) How fast, what frequencies, can we expect in these sensor readings? Even if they sample very fast a big heavy mass like a quadcopter acted on by the wind and it's motors cannot be accelerating faster than some maximum. There no point in iterating faster than what is required to measure those signals down to the noise levels of the signals. In fact bandwidth limiting those signals may be advantages in terms of remove high frequency noise. Like motor vibration for example.
3) What about jitter? If you are sampling a signal it's best to do it at an accurate fixed repetition rate (sample rate). Jitter in you sampling time is actually introducing noise into your input data. Are those guys taking care of this by sampling on some interrupt. Are they taking care that that interrupt is a high priority so that it's timing is not jittered by other activity on the processor? Or are they just running around in the typical Arduino sketch loop that will jitter all over the place as it handles other tasks as well?
Anyway, it's good to know that this algorithm can be run at a good lick on a small machine.
I think I would start out with this by fetching the data into an Propeller or other MCU and then forwarding it to the PC where one can experiment with the IMU algorithms.
Madgwick's original paper mentions 10Hz updates... so falls short. But a comparative test of Madgwick and Mahoney on various devices indicated the numbers I mention.
Personally, I just want something over 250Hz for my own concerns. But for visual smoothness in graphic display 30Hz is minimal and 60Hz or more is optimal. Animation gets jumpy if too slow. Higher sample rates offer more leeway for special effect animations.
======
So I have concerns about an output bottleneck. But the I2C at 400Kb/s provides a raw data input bottleneck as well.
400Kbits/s/8 = 50 Kbytes/s and packets on data are 2 or 3 bytes.
So 50Kbytes/s/3 =1667Kpackets/s. And 9 sensors to read indicate a further reduction
16.67Kpackets/second / 9 = 1.8k downloads/ second.
++++++++++++++++
So it seems that the paper is missing some key pipeline issues. Nonetheless, >1000Kpackets/s would be lovely.
What has "visual smoothness in graphic display" got to do with anything? I thought you wanted to balance a bot not make a video game?
Don't be so narrow... These devices can also gather data to use for video animation. If i just lived for one project, microcontrollers would be a rather dreary world.
The topic is optimization, not 'How to build a balancing bot' per se.
The bench mark is to get Kalman filter equivalent performance out of microcontrollers that are small enough to be hand-held or on-board tiny bots.
Consider the idea that you want to animate a superhero's punch. You can take an IMU and replicate punches until you get data you like.. then apply it. You might even have multiple IMUs... one at the shoulder, one at the elbow, and one at the fist. It you want the punch in slow motion, you require a higher capture rate.
The IMU can be used in many ways ...
1. a flight controller.
2. a wireless joystick equivalent in 3 dimensional space
3. monitoring head motion in relationship to a visual display.
4. balancing robots
5. underwater ROV control
6. a camera gimbal controller
and so on.
BTW... I am NOT particularly interested in video games. But video can be a lot of other things. There are big bucks in short animated commercials or cartoons, and tons of creativity.
"Madgwick's original paper mentions 10Hz updates... so falls short"
Falls short how?
Yes, Madgwick's paper mentions 10Hz updates, only to say that the accuracy achieved at even that low rate may be acceptable in some applications.
The results he presents show that accuracy does not improve when going from 50Hz to 512Hz. See graphs in Figure 11. Where we are down to half a degree error. Of course it all depends on what rates of change you expect to be seeing in the system you are observing. Spin this thing at 1000 rpm and I'm sure it is never right!
Madgwick's sample rates were limited by the equipment used. The Xsens modules only allow sample logging to the PC at a max 512Hz. (Limited by their RS232 interfaces I guess). He was running his algorithm on the PC. I'm sure he only iterated it once for each sample from the Xsens.
Basically Madgwick says nothing about the performance of the code on any platform. Only that he tried to optimize the algorithm and the code for speed.
On this 6000 bogomips machine I can execute about 8 million iterations per second. I start to think 512 iterations per second might even be doable on the Propeller.
What we need to do is compile the available C code under propgcc and find out:
a) Does the resulting code even fit in HUB with useful space left over.
b) How fast does it run?
Should take you about half an hour:)
In regards to noise and jitter. The original Kalman filter, and the Madgwick filter to optimize by filtering noise to some extent... just not sure what extent.
Regarding jitter and machine limitations... each situation is different.
Accelerometers for a balancing robot are best placed at the center of rotation.. otherwise you acquire added accelerations due to motion in any direction.
And I did see that the analog balancing ball robot included a 'mass dampening mount' for the IMU. He mounted it to a big chuck of steel that was glued to a chunk of neoprene rubber that was glued to a slice of hard plastic and to another chunk of neoprene rubber that was finally glued to the chassis. A clever 'old school' solution... similar to how building foundations use neoprene blocks to buffer from earthquakes.
Heater, just go to www.dx.com and buy yourself a GY-85 IMU to get started. Free shipping world-wide. (They even have a ton of Raspberry Pi stuff... ugh!~) You might also consider a Bluetooth to serial board to have a wireless link to your computer. They also have those for $6 or 7 USD.
http://www.dx.com/p/gy-85-6dof-9dof-imu-sensor-module-for-arduino-148436#.VBWGN45EEpQ
Take a look that the YouTube presentations in this Arduino discussion of balancing robots. There are a lot of useful observations and a demo of a Bluetooth to computer link that he used to configure PID and/or maybe with his remote controller.
It does seem the Bluetooth is for the remote control. so you might use the MR3020 that you have for the Propeller programing and configuration. It is a nice completely wireless solution.
And I guess I need one of these +++> http://www.dx.com/p/rechargeable-dualshock-bluetooth-wireless-sixaxis-controller-for-ps3-black-red-93529#.VBWNbI5EEpQ to complete my wifi remote control. Ugh... more shopping.
http://forum.arduino.cc/index.php/topic,58048.0.html
Not quite. I have a long way to go. All I can do is read, learn and experiment. Or wait for one of the genuises on here to come up with something.
Have you seen Jason Dories thread on direction cosine matrix. I tried it as it uses the same IMU I was using in my quad copter. It seemed
stable to me.
The direction cosine matrix seems to be pretty much used as a 2 dimension array to sort out X, Y, and Z axis positioning. It can be useful in a flight controller or maybe in computer graphics. There seems to be a lot of recalculation of vector products (the dot product and the cross product).
When you rotate or flip a graphic image on a computer, the same matrix comes into play.. but in two dimensions (which might be a good place to start because it is simpler).
+++++++++
So far we have pretty much been targeting getting good position updates and have not discussed targeting moving from A to B or rotating from X to Y. So you have shifted over to a second topic, and not the only one involved in flight control.
I ordered all I need, but am still waiting for parts to arrive in the next week or so. So I cannot yet do anything hands on. Dave Hein just got his HoverFly Experimenter's Board as he is in the USA.... faster delivery. Out of the box, it came loaded with software that provides raw data outputs for all the sensors as a proof of life. .... nice to know.
And so, if you really want to get into the direction cosine matrix --
a. I am not up-to-speed on it. I just have peeked at the concept in the 2-D form for computer graphics; like zoom, rotate, and so on. I have a book that goes pretty deep into that.
b. Wikipedia is always a good place to get started with the fundamentals before you try to explore "How to" stuff. You need overview.
c. Be aware that the data is stored in a 2-D array in which the cosines represent X, Y, and Z of 3-D objects in space.
In some cases, operations are not what you might find in traditional linear matrix calculations. So try to get clear on what applies to your desired objective. (For example, the Madjwick filter is using Jabconial matrices to expedite calculation -- and they are specialized form of matrices as well.)
http://en.wikipedia.org/wiki/Direction_cosine
The generalized math is this.. for simultaneous linear equations.
http://en.wikipedia.org/wiki/Matrix_(mathematics)
I think you desire understanding Vector as applied matrices.
Maybe transformation matrix is the desired topic, I am not sure, but it does look like the 3-D section applies.
http://en.wikipedia.org/wiki/Transformation_matrix
++++++++++++++++++
Of course, one can use the same IMU and code as someone else and get a stable setup -- but learning what really goes on within the code begins to open up a variety of math topics.
Thanks for Jason's thread as I am seeing a lot more of what I need to know if I get into flight control. Please realize that the IMU is really a lot of overkill for a 2 wheel balance bot. I need only get data for one axis to remain upright.
~~~~~~~~~~~~~~~
Jason's thread is working with 200Hz inputs for flight control. And that is very useful in proving the Madgwick filter is worthwhile.
This link offers up food for thought in flight control.
http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A77893&commentId=705844%3AComment%3A335176&xg_source=activity
And you really Must understand why and when Sine, Cosine, and Tan apply.
Also be aware that ArcSine, ArcCosine, and ArcTan are an entirely seperate maths... spherical geometry, not simple Trig. You may have to learn that subject as well.
Have you started to formulate a method to go about keeping a 2 wheeled robot balanced? I will be paying attention to this thread so maybe I can learn something about it from one of you genuises!
Not exactly........
I suspect the easiest route these days is to borrow (steal) Arduino code.
Here is a teaser.
Parallax did publish a balancing bot in one of its texts, Chapter 6. But that did not incorporate an IMU.
Furthermore, since it only requires one axis (doesn't have Yaw axis stabiltiy issues), you can use a 6DoF or less and Mahoney filtering in lieu of Madjwick.
Frankly, while I have had interest for years in all this... the cheap 9Dof devices finally triggered really understanding what is what. So I am reading a lot and trying to catch up.
With one axis for balancing, there is no direction cosine matrix in play. Motion is maintained by a balance loop that is fed non-equilibrium information within limits to get forward, backward or rotational directions.
http://www.youtube.com/v/4bj2ieD4HA0
When it comes down to balancing a bot, there is more to be looked at. How to control "verticalness" and remain upright. Use PID, or fuzzy logic or what?
Then one might be concerned about keeping the bot standing on the same spot or moving itself around. i.e position control. That may require a whole other control loop riding on top of the "staying up right" control loop. With its own sensors and feed back. Wheel encoders say.
Then one might want to steer left and right whist moving....how far do yo want to take this?
It might pay to look into the dynamics of the "inverted pendulum" and "inverted pendulum on a cart" to get more insight into that.
I'm kind of intrigued by the idea that a Madgwick filter outputs a quaternian. Just so happens that my favourite JavaScript library, ThreeJS, which is an API on top of webgl for doing 3D graphics in the browser recently adopted use of quaternians to describe and control 3D objects in space. Seems I could get the output from an IMU, run it through Madgwick and run that directly into an object in ThreeJS. Bingo IMU control of objects in the browser. For example browser based real time animations of your balancing bot or quadcopter motions.
Expect a Javascript version of Madgwick soon...
Loopy, I have to take issue with your statement about putting the IMU sensors at the centre of rotation of a balancing bot. Where is that? Top or bottom? Seems that when the bot is in a state of unbalance, following a disturbance say, then the base is doing most of the acceleration as it thrashes about trying to regain balance. Perhaps the head end is the more stable at that point in time.
I think I might spring for a FreeIMU board with the barometer on it at some point. That might have to wait until some other projects are out of the way...
I have been using ViewPort's DSO to monitor the sensor's output with and without motor vibration. I have tried my own basic version of a balancing bot with PID but as far as I got was it rocking back and forth under
my finger tip. But my interest in this in part comes from this guy's example of an object following balancing bot using a Raspberry Pi and another processor (you could use a Propeller)
Where is the center of rotation on a balancing bot? Through the centers of both wheels. Why is that so hard to envision?
Why is it important. While the gyros don't care, the accelerometers do. If they are off the axis, you have the addition of directional accelerations to the rotational acceleration. This is viewed roughly as a higher level of noise that must be dealt with.
Javascript? Maybe mention the Raspberry Pi while you are on pet themes. The above posting includes a balancing Raspberry Pi that is quite nice.....(blech! I want a Parallax solution.)
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. Can't seem to comprehend what Madjwick in Javascript will contribute... impress me with how stupid I am.
Less beer, more thought please.
Rocking back and forth? That means you got it to stand up, and just need to learn a bit more.
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.
The PID motor control is a whole separate topic. But once you are satisfied with the operation without it, you can add it back in and fine tune. These things should be done in steps. You can't figure out the problem with everything working as the wobble could come from different parts of the code.
Much as I hate to admit it, the Raspberry Pi balancing bot has several nice features -- including a video camera line follower.