Propeller 9-DOF Experimenter board LIMITED QUANTY
Photronix
Posts: 16
A few years ago Hoverfly developed a servo based gimbal controller called the HoverflyGIMBAL that performed well and was adopted by many multirotor filmers. As technology changes quickly this product had a short life as brushless gimbals came on the market. Well we still have about 80 of these boards in stock and not much hope of finding them a gimbal to actuate. So Hoverfly would like to make these surplus boards available to the Parallax community at far below their original retail value (and cost unfortunately).
Each board contains a Parallax Propeller, and ITG-3200 3-axis Gyroscope, ADXL345 3-axis accelerometer, and a HMC5883L 3-axis magnetometer. There are 3 transistor driven outputs for servo control and 3 inputs/outputs.
The Sparkfun Razor IMU is $74.95 including an ATmega328 and these same three sensors. We would like to make the HoverflyGIMBAL available to you for $70 including shipping.
Details:
-Parallax Propeller
-RGB LED
-Accepts from 5v-28v
-5V and 3.3V regulation (onboard jumper for greater than 6V operation)
-3 Digital I/O
-3 Transistor driven digital outputs (0 to 5V)
-ITG-3200 Gyroscope (connected via I2C)
-ADXL345 Accelerometer (connected via I2C)
-HMC5883L Magnetometer (connected via I2C)
-Demo SPIN program
-Micro USB with onboard FTDI (board can operate on USB power alone)
-Schematic
Use it to experiment with these three motion sensors or flash the gimbal firmware and build a gimbal.
Please visit our store to purchase your before they are gone forever.
http://www.shop.hoverflytech.com/products/hoverflygimbal-experimenter-board
Free standard shipping in the US until the end of September. Use code at checkout: XPBSHIP14
Al Ducharme
CEO and President
Hoverfly Technologies, Inc.
Each board contains a Parallax Propeller, and ITG-3200 3-axis Gyroscope, ADXL345 3-axis accelerometer, and a HMC5883L 3-axis magnetometer. There are 3 transistor driven outputs for servo control and 3 inputs/outputs.
The Sparkfun Razor IMU is $74.95 including an ATmega328 and these same three sensors. We would like to make the HoverflyGIMBAL available to you for $70 including shipping.
Details:
-Parallax Propeller
-RGB LED
-Accepts from 5v-28v
-5V and 3.3V regulation (onboard jumper for greater than 6V operation)
-3 Digital I/O
-3 Transistor driven digital outputs (0 to 5V)
-ITG-3200 Gyroscope (connected via I2C)
-ADXL345 Accelerometer (connected via I2C)
-HMC5883L Magnetometer (connected via I2C)
-Demo SPIN program
-Micro USB with onboard FTDI (board can operate on USB power alone)
-Schematic
Use it to experiment with these three motion sensors or flash the gimbal firmware and build a gimbal.
Please visit our store to purchase your before they are gone forever.
http://www.shop.hoverflytech.com/products/hoverflygimbal-experimenter-board
Free standard shipping in the US until the end of September. Use code at checkout: XPBSHIP14
Al Ducharme
CEO and President
Hoverfly Technologies, Inc.
Comments
If you haven't ordered yours but are considering it....they are going fast.
9DOFHoverflyExperimenterBoard.zip
9DOFExperimenterSCH.pdf
It doesn't even have to be a Kalman filter as I see there are other alternatives that might even be a smaller faster bit of code.
Question. What is SensorDriver.cons in the SensorDriver.SPIN file?
That was a mistake. Its now corrected. Please re-download the ZIP.
My order just went in.
Jim
9DOF may be more sensors than one really needs for 'most things', but having them available is assuring. I am beginning to wonder about pairing the yaw gyro with yaw compass for better tracking. Apparently the yaw accelerometer does not offer useful data under normal circumstances.
I am already pondering if some of the i/o might interface an SDcard for more ambitious programs.
Kalman filters seem not very feasible on microcontrollers, so other sensor fusion solutions are very interesting.
It seems to be a very helpful resource. 'General MEMS Sensor Model'.
It seems that for data rates > 100Hz for a single sensor, a uM-FPU3.1 is deployed. I suppose that some of the i/o pins on the HoverFly might allow for that to be attached. It is SPI or I2C interface.
http://www.parallax.com/product/604-00050
http://www.micromegacorp.com/products.html
http://obex.parallax.com/object/17
Kalman filters are just too slow for the kind of real-time results that people want. Along came a newer filter, the Mahoney filter that applied to 6 DOF, and this has since been improved upon for 9 DOF devices (also called MARG).by Madgwick.
Madgwick seems to have published a paper in 2010 that can be downloaded from the web that extended Mahoney's 6DOF solution to 9DOF. But the best part is that he provided C code for both 6DOF IMU devices and 9DOF MARG devices,
So this seems to be a very good fit with the HoverFly Experimenter's Board. One can begin with either Catalina C or SimpleIDE/gcc. It may work well without a FPU.
Not only is the performance excellent, the configuration is far less involved than Kalman filters.
.Samples at rates >2000Hz may actually be feasible.
What I provided is just the beginning code and it apparently has been much improved. One site openly declares that Madgwick is open-source, so that should ease some concerns.
Everything seems to have been developing in C with testing on Arduino or Arduino clones. It would be nice to see a Propeller solution entering the arena. It should perform comparatively well and there has been at least one blog that has demonstrated that both code and processor speed can significantly enhance Madgwick.
I have high hopes that the Propeller will have Cogs left over for PID motor control.
You might want to purchase a cheap Bluetooth interface from DealExtreme for initial development.
http://www.dx.com/p/jy-mcu-arduino-bluetooth-wireless-serial-port-module-104299
That would allow you a wireless link to a desktop computer which would display your data graphically.
http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/
http://mbed.org/users/aberk/code/IMUfilter_HelloWorld/
This offer is only until the end of September... there is still time if someone wants one.
Heater came up with more recent and up-to-date links for Madgwick code. What I posted above was his first proof of concept, works but very conservative hardware setup. Some flaws have been removed and it now runs faster, reputed to run up to 5000Hz if everything is right.
I only need about 250Hz. And for quadflyers, 200Hz seems acceptible.
Spent a bit of time today learning about the differences between the Kalman filter, the Complimentary filter, and the Mahoney and Madjwich (which are close together). Also tried to fill in gaps on my knowledge of matrix mathematics, though one doesn't need all of that to get this working.
====
On a more practical note, I see the Hoverfly 18 pin output is really set up with only 6 i/o connections. All i/o to the Propeller has 10K resistors which with protect the Propeller if inputs are 5V logic.
Of the six, 3 deliver only 5V output, and 3 can go either 3.3V output or 5/3.3V input.
My situation is that I need 4 outputs to run an L293 Twin H-bridge. So I guess I will use the 3 dedicated 5V outputs and adapt one of the others witha transistor to do the same. It is not a big chore.
That will leave me with 2 i/o for other stuff, maybe an ADC chip for multiple IR collision avoidings. It seems 16 i/o on the Propeller remain unavailable. None the less, it is possible to use what you have to drive a quad-copter or fixed-wing aircraft and maybe include a GPS device.
(From the Spin file)
Like it says in the file, move it around for some groovy colors from the RGB LED.
I envision the cog workload laid out like this:
Main:
- Main flight control
- Read remote inputs
- Run motor outputs
- Comm object
- Serial debug channel
- extra : SD data logger (?)
Gimbal:
- Read all sensors
- DCM IMU code
- Float math
- Comm object
- extra : altimeter ?
- extra : GPS ?
My existing DCM solution is at the point where it either needed a PASM rewrite or a 2nd chip to make it work, and I was already leaning toward the 2nd chip, but not looking forward to setting up another set of boards. This should make a nice shortcut.
In the back of my mind, I have been looking and those figures and a bit concerned. I think I need to have 200Hz iterations to my motor control.
It seems I could fudge a bit and provide good Gyro updated on every cycle while providing the Acel values 4 times before revision. Any comments?
Loopy, 200Hz should be more than enough, and 100Hz is probably sufficient, though faster is better. Probably the biggest limiting factor in your control loop will be the slew rate of your motors.
For what application do you need a 200Hz iteration rate?
If it's for a balancing bot my gut feeling is that 50Hz is a plenty fast enough sample rate.
My reasoning is that one only needs to sample at twice the expected bandwidth of the system you are trying to control. Nyquist and all that. Perhaps 3 of 4 times faster for good measure.
So, how fast to we expect the bot to be moving under the influence of gravity and it's drive motors? Certainly not up in the hundreds of hertz.
Anything above that frequency is just noise, motor vibration for example, and not contributing anything to the accuracy of control.
Having said that if I were using analogue sensors I would filter their output to a 10 or 20 hertz bandwidth before they entered the control circuitry. To get rid of the noise. Similarly when using digital sensors it may be beneficial to sample them as fast as they can go and digitally filter that sample stream down to the required 10 or 20 Hz.
So actually perhaps it's better to do the opposite of what you suggest. Read the gyro at it's 200Hz rate, filter than down to a 50Hz roll off, a moving average, and combine that with the 50Hz accelerometer rate. Run the control loop at 50Hz. All in nice lock step.
The nbot, for example, runs it's control loop at 20Hz.
I have not thought about copters but again it would surprise me if a 200Hz control loop rate were required especially for big machines. How fast can you change the speed of the motors for example? I don't think you can noticeably cycle the thrust at 200Hz if only due to rotor and blade inertia. Anyone done any tests on this?
Or do you mean actual motor control? (As opposed to the higher level attitude control). That may be a slightly different issue. But again my guess is ample rate requirements are dictated by the response of the system, motors, wheel inertia etc.
Controlling the gimbaled rocket motors on the Saturn V was "easy" compared to trying to do it on a small model rocket. Because the Saturn V was over 300 feet long it would take several seconds for it to fall over. So the time constant is on the order of seconds, and relatively slow hydraulic cylinders were used to position the rocket motors. A small model rocket will fall over in less than a second, so the actuators must react must faster -- on the order of 10s of milliseconds.
Thanks Dave. That was a typo. Fixed my post.
I got excited with one blog that claimed 5000Hz updates was feasible with Madgwick filters, but I guess that was done with input from a data file rather than real world sensors.
I don't need to push the device to race horse break neck limits. I just want to get started with some realistic figures. And even then, I suspect some of you are far ahead of me with all this. I will try to learn at my own pace, and maybe help other slow pokes to move ahead.
As best as I can recall, there was no justification --- I just made a mental note that the project seemed successful and worth emulation. It may well have been the analog balancing bot in Dale's Homegrown Robots.
Now that I have been assured that slower rates will suffice for just about any project one might desire with an IMU, I can let it go.
Dale's bot is analog so there is no idea of sample rates in there. Looking at his schematic I don't see any filtering of the the accel and gyro inputs so I guess the whole system is operating at whatever the bandwidth is achieved by the sensors, op amps, motors, masses combination. That is limited by the lowest bandwidth item in the loop which the mechanical stuff so guess it's a few tens of hertz.
Where running the control loop at too high a rate, or having too much bandwidth if it is analogue, might hurt is when there is noise on the sensors. Motor vibrations or general thumps and bumps of riding over rough terrain say. Then you end up controlling according to a signal that is not really relevant to the attitude control job at hand.
I can't really offer a more refined explanation for my feeling that a high repetition rate of the control loop is pointless if not detrimental. It's just that if the forces and masses involved in the mechanics of the thing mean that it cannot physically be made to oscillate meaningfully above a certain frequency then there seems to be no point in trying to control it at frequencies orders of magnitude above that.
However, at risk of seeming to contradict myself, perhaps it is better to run that Madgwick filter at as high a rate as the sensor inputs can deliver or your processor will allow. The filter's job is to merge gyro, accel and magnetometer data into single orientation. My first guess is that it would be better to allow that filter to chew on as much data as you can feed it. Throwing information away can't be good right?
Thing is I don't see that it is necessary that the filter and the attitude control loop all run at the same iteration rate. They are different subsystems. Perhaps "over sampling" at the input and filtering is a good thing.
On the other hand Madgwick himself says that the filter did not work noticeably better at high frequencies. I don't know what the limits are there. Is it the accuracy or bandwidth of the sensors themselves?
It may well be the best way to find out is to build the bot and implement ones best guess at a control system given the information we have available. It would be great to be able to tweak around with iteration rates and see what the reality about them is.
I'm going to read the Madgwick paper again. Not that I stand a chance of understanding 99% of it but his conclusions are interesting. That should get me to sleep tonight.
The justifications I've seen for running a high-speed control loop vary. The systems tend to have some built in latency, so if you read your sensors, then do some calculations, then send some servo output values, with a 50hz update, it might actually be 25hz (2 loops) by the time your sensor readings start affecting the motors. With a 200hz update rate, the time gap between when you take a reading and when it's applied is much smaller, which can lead to a "tighter" control feel. This would be much more relevant on small quads, or quads with variable pitch props, or quads using UltraESC or similar high-rate controllers. On a larger quad using normal motor controllers it's probably wasteful to run the flight code above 100hz, but I haven't tested that.
Interesting, thank you.
What size is your copter? How heavy is it?
It's not clear to me how upping the control iteration rate helps overcome the latency, mostly in spinning up and down the motors I would guess, at least past a certain point. But I can't argue with real world experience.
Welcome ... I noticed that you have been a contributor to DIY Drone and the 2011 Propeller DCM thread -- both very helpful.
@Heater
I don't keep copious notes, I just print to PDF whatever on the web seems a worthwhile reference. So I can't quite locate the 200hz motor control rate. Dale's analog balancing computer has a triangular wave generator that may be 200Hz.
In any event, it occurred to me that fixed wing R/C airplanes have long done very well with servos that update at 50Hz. And there have been successful balancing bots using continuous rotations R/C servos. So I am no longer concerned with pushing data rates to higher extremes.
+++++++++++
The maths in Madgwick has been a very interesting research project.
I needed to get up to speed with a general background on matrix maths and determinants, especially with a focus on square matrices and in combination with vector maths. I happen to have a hard copy of 'A History of Mathematics, 2 ed.'; Boyer, Merzbach; so I have been using that to help out... and it has.
Matrix maths is part of 'modern algebra' and most of the development has been done since the 1800s. Traditionally, it was thought there as one and only one algebra - the real number algebra that is faithfully taught in high school. But with matrices, that began to be challenged, and C.S. Peirce managed to demonstrate that as many as 162 algebras were possible, and that all but 3 were not really worth considering as 'true algebras'.
The three that were worthwhile were: [a] real number algebra; complex number algebra (known for representing the imaginary number components and widely used in electronics); and [c] quaternion algebra (which is very handy with vectors and applies to a Jacobian matrix),
So it seem that quaternion algebra eliminates the use of more computing burden than trying to apply trig and angles.
There is a lot of interesting history as the maths were developed so recently and represent a core subject for 'rocket science'. C.S. Pierce was rather notorious as he got kicked out of John Hopkins University for refusing to give up his live in lady friend while still married to his first wife. http://en.wikipedia.org/wiki/Charles_Sanders_Peirce He had gotten into Harvard by publishing and extending work on matrix maths that his father had started, much of what put Harvard into the same class as British and German universities that were leading in the subject. But C.S. Pierce went off the deep end with a mystical pursuit of the idea that everything could be represented in Threes. He even contributed a major concept to Linguistics and Semiotics in terms of three categories of symbolic representation. But in the end, nobody wanted to fit the whole world into patterns of threes, so he ended in disrupt.
Nonetheless, his Three Algebras seem to be core to representing the physical world and moving through it. So I am very interested to learn more about Quaternions, and the 3rd algebra. I wasn't aware of how significant this was. It seems to have been what triggered Pierce's mystical passion for three-ness.
Since the output of the Madgwick filter is a Quaternion format, there is a necessary step in converting that output to useful motor response in computer code. Apparently the is a desire to move from that to a Cosine matrix. I haven't gotten into that yet. It is in 2011 thread in the Propeller forum under the heading of Propeller DCM (Directional Cosine Matrix). That brings you back into Roll, Pitch, and Yaw from the Quaternion format.
It is all a very interesting puzzle. I suspect the same maths are very useful for study of the motions of sub-atomic particles or astronomical observations. In fact, there are some astronomers of note involved in the history of matrix maths.
So... by playing with programing a quad-copter, one may actually be acquiring kit for a career in serious study in leading edge science research. We still have a lot to learn about what the lowly electron does and why some materials are ferromagnetic while their alloys and other materials resist being ferromagnetic. Some of this may apply to charged particles.
I found this great lecture about Quaternions by Dr Bryan Duggan of the Dublin Institute of Technology.
https://www.youtube.com/watch?v=LB6U849kwXc&list=UUyCtwxWozKoX3iMd75S3N1g
It's part of a game developers course. The lecture does not go deep into Quaternion maths but covers everything we need to know to use them. Check out the brilliant "Quaternion Poem".
Then the is this nice intro to quaternions: https://www.youtube.com/watch?v=dttFiVn0rvc&list=PLW3Zl3wyJwWNWsJIPZrmY19urkYHXOH3N from Jorge Rodriguez https://www.youtube.com/user/BSVino.
Seems the game developers are learning all that useful maths we need to fly quadcopters and balance bots in the real world! I found a way to convert a Quaternion into Euler angles here: http://mbed.org/users/aberk/code/IMUfilter/file/8a920397b510/IMUfilter.cpp Note: that the actual Madgwick filter in there is the buggy one that produces NaNs.
void IMUfilter::computeEuler(void){ //Quaternion describing orientation of sensor relative to earth. double ESq_1, ESq_2, ESq_3, ESq_4; //Quaternion describing orientation of sensor relative to auxiliary frame. double ASq_1, ASq_2, ASq_3, ASq_4; //Compute the quaternion conjugate. ESq_1 = SEq_1; ESq_2 = -SEq_2; ESq_3 = -SEq_3; ESq_4 = -SEq_4; //Compute the quaternion product. ASq_1 = ESq_1 * AEq_1 - ESq_2 * AEq_2 - ESq_3 * AEq_3 - ESq_4 * AEq_4; ASq_2 = ESq_1 * AEq_2 + ESq_2 * AEq_1 + ESq_3 * AEq_4 - ESq_4 * AEq_3; ASq_3 = ESq_1 * AEq_3 - ESq_2 * AEq_4 + ESq_3 * AEq_1 + ESq_4 * AEq_2; ASq_4 = ESq_1 * AEq_4 + ESq_2 * AEq_3 - ESq_3 * AEq_2 + ESq_4 * AEq_1; //Compute the Euler angles from the quaternion. phi = atan2(2 * ASq_3 * ASq_4 - 2 * ASq_1 * ASq_2, 2 * ASq_1 * ASq_1 + 2 * ASq_4 * ASq_4 - 1); theta = asin(2 * ASq_2 * ASq_3 - 2 * ASq_1 * ASq_3); psi = atan2(2 * ASq_2 * ASq_3 - 2 * ASq_1 * ASq_4, 2 * ASq_1 * ASq_1 + 2 * ASq_2 * ASq_2 - 1); }That at least gets you the angle of tilt of a balancing bot to use. Yes indeed. Turns out that when we put man on the moon NASA did not use quaternions in the navigation/guidance systems. As a result they had to have big red warning messages when the Lunar Lander system got into attitudes the "old" maths could not handle (gimble lock). The usefulness of quaternions has only been discovered relatively recently. Certainly it was not covered in any of the maths we did back in uni in the late 1970's.Too late for a career change for me but I must say Loopy, you do have a way of finding juicy challenges for this old brain. Fascinating.
P.S. Do check out the young Dr Sebastian Madgwick himself demoing his IMU/AHRS here :https://www.youtube.com/watch?v=BXsGWoOMtmU&list=UUZdLJBtwk1MK7lxG_xRHI2Q and here https://www.youtube.com/watch?v=ZYyyaJgKsDg&index=29&list=UUZdLJBtwk1MK7lxG_xRHI2Q he has a ton of other interesting videos there as well.
http://3dgep.com/understanding-quaternions/
One must wade through algebra and complex numbers to get to quaternions.
At least I have found what a tuple is useful for in computing - both complex numbers and quaternions tend to rely on paired values.
(I also came across some work on octonions (aka biquaternions http://en.wikipedia.org/wiki/Biquaternion), but I strongly suspect they will only be useful for jumps thorugh hyperspace. I will set that aside for now.
=========
Too late for a career change? I am 66 with a Bachelors in Fine Arts and an incomplete Masters in TESOL. You just have to have the desire and the knowledge will unfold.
BTW, Sir William Rowan Hamilton is credited with the creation of quaternions, Charles Sanders Pierce just extended the recognition of their usefulness.
Once again, we see that if you want to be truly famous -- become a mathematician... long remembered after the world will have forgotten Lady Gaga.
++++++++++
Most amazing is I am actually beginning to be able to visualize what this stuff does.. a very big WoW.