I recently got SparkFun's 6 IMU board and played with it a bit. Basically I connected Arduino and Razor 6DOF board and ported DCM code. Code is ArduIMU v13 but just made to work with Razor board. I am not sure what to think about gyros on that board as it takes them a while to "warm-up". Below you can see run from cold start for over an hour and "zoom' on first minute or so (just raw ADC values). On the link referenced above, you can see same data plots for both gyros and accelerometers.
I also modified ArduIMU Labview code - mainly that "cube" is within main window rather then separate one. I haven't compiled the code but whoever has LabVIEW should be able to run it (developed with version 8.5)
Sorry guys, I haven't checked this thread in a couple days.
To answer the question "how arduimu programmers solved the problem?", the answer is to change the hardware to remove the high pass filter. Otherwise having the gyros is useless. All you get is the compensation algorithms in the DCM dragging the output back towards reality. I suppose that theoretically you could implement a software filter to reconstruct the proper gyro output (e.g. undoing what the high pass filter did), but that is a lot of unnecessary software overhead. We are going to replace the capacitors with "zero ohm resistors" and remove the 1Mohm resistors - in other words remove the high pass filters.
Yesterday I did some 'vibration' tests on the bench. Remember that Razor board is connected to Arduino in the 'shield' configuration - I'll post proper description and pictures of the setup little later. Arduono/razor was placed inside cabin in the vicinity of the leading edge. No padding of any kind was used. Plane was suspended from the ceiling, but had a retaining block of styrofoam towards the tail of plane ( to keep it from swaying) - hopefully this will be more clear once I get the setup pictures.
Gy x4 data can't be easily see so here it is as a separate plot
Notice that magnitude of Gy in comparison to Gx and Gz especially in the 'top half' of the throttle regime. Although plane did not swing wildly, I am not 100% yet if this is artifact of test setup or propagation of vibrations in the plane body - or combo of both....
Also observe that magnitude reduces at half throttle...
Hi Doug, what you wrote in arduimu thread is exactly the issue I've been trying to describe here, same problem. It would be interesting to know, how Arduimu programmers solved it. As far as I can tell, no Razor or Arduimu v2 should be capable of guiding plane when circling waypoints, probably also cannot do T3 circuits well. However, they should be able to fly straight line (do RTL). This is just a guess, as I do not have experience with them.
Solution for Razor is easy for me - disable high-pass filter by shorting high-pass filter capacitors. If you study gyro docs, then high-pass filter is marked as optional there, you can just take it away. Not sure about arduimu, as if there already is algorithm in place in code which deals with high-pass filter effects, then just disabling high-pass filter does not do any good. After all, you can compensate for high-pass in code, its just makes life more difficult, imo.
@Doug
From your comment T - that's exactly what I saw too. If you look at the next to last plot on my post from November 8, 2009 at 11:41am , - right in the middle - it's obvious 'decay' behavior (you can also see it in the first 'big jolt' movement as well, although not as pronounced. Andrus seems to have interesting ideas/opinions on what is going on....
Hey guys - I've got a pre-release of the ArduIMU+ Flat board and I think there is an analog filtering problem. Looks like there have been a few people in this thread who could make more sense of it than I. Please see my last comment (with data) in the "ArduIMU+ V2 (Flat) now available for preorder.." thread.
The high pass filter doesn't set well with me.....just don't like it.
Don't like the 1MOHM's RF pickup ability or the effective output
impedance imposed upon the 1X rate during ADC sampling (as mentioned by Andrus above).
Or the wacky, but somewhat cool way, the IC backfeeds VREF out
of the 4X input pin for highpass reset. It's all too messy.
Let the drift through, DCM should take care of it.
Automatik,
Thank you very much for running the tests with the Xbee. This is useful information. It looks like a 9" separation between the Xbee and the gyros is a good rule of thumb.
Bill
Hi, very interesting plots. Natural question arises, why amplified outputs are not on exactly on vref's. As you mentioned, you may have been affecting them with measurements, as resistor to vref from output is one megabyte and ADC input impendance can easily affect it.It would be perhaps interesting to connect ADC inputs together and see, if their readings are same or different or change adc inputs, but thats just me being curious.
Now, you mentioned that gyro outputs "slowly settle" after movement - I would bet that this is because of capacitors indeed, both low-pass and high-pass filters play there. Bigger effect comes from filter with lower cutoff frequency, i.e. from high-pass filter in this case. I should be easy to understand, why is that - if there is gyro output voltage change, then filter capacitor starts to charge and its voltage increases. When gyro output returns to zero, then capacitor starts to discharge and its voltage drops smootly. Low-pass filter is not an issue here, as its integrates gyro output - it will make sharp movement to look like slower one, but you still know, how big the total movement was. If there is movement during 1 microsecond, but you sample with 100Hz, then you may miss that movement, unless you have suitable low.pass filter, which records the movement for you in its capacitor. Even though it will seem, that movement lasted longer and was with less intensity, your DCM logic is still happy.
High-pass filter, however, causes issues here, it causes DCM to lose movement data if movement lasts longer than high-pass filter period.
Low-pass filter, btw, can help you to overcome saturation issue with 4x outputs in case they are caused by sharp movements (should not be an issue once your IMU gets off the ground). Increasing long.pass filter period (putting bigger capacitor) may smooth out those movements.
In general I think that you are fine, you just need to accept the fact, that gyros do drift and you need to compensate, and once you try to rotate your board for, say, 10 sec, and log that, then you will want to disable these high-pass filters there.
I'm planning to order gyros LPY0503 and LPR0503 in order to see how they behave (sparkfun says, that they are 30 deg/sec, but this applies to 4x amplified output; they are 120deg/sec unamplified). Your experiments are therefore very interesting, as Razor uses similar gyros. IT would be perhaps interesing to see, do these gyros settle faster initially if you reset them shortly after power-on with HP input.
So in short, it appears that having Xbee by Razor IMU board on Arduino will affect amplified gyro output, while there is no significant effect on non-amplified gyro output, cross correlated with separation distance between them and XBee power output level. Longer the distance and/or lower the power - the better.
At 200mW XBee power level and separation distance of 9" I could not see any noticeable effect.
Comments
To answer the question "how arduimu programmers solved the problem?", the answer is to change the hardware to remove the high pass filter. Otherwise having the gyros is useless. All you get is the compensation algorithms in the DCM dragging the output back towards reality. I suppose that theoretically you could implement a software filter to reconstruct the proper gyro output (e.g. undoing what the high pass filter did), but that is a lot of unnecessary software overhead. We are going to replace the capacitors with "zero ohm resistors" and remove the 1Mohm resistors - in other words remove the high pass filters.
Gy x4 data can't be easily see so here it is as a separate plot
Notice that magnitude of Gy in comparison to Gx and Gz especially in the 'top half' of the throttle regime. Although plane did not swing wildly, I am not 100% yet if this is artifact of test setup or propagation of vibrations in the plane body - or combo of both....
Also observe that magnitude reduces at half throttle...
Solution for Razor is easy for me - disable high-pass filter by shorting high-pass filter capacitors. If you study gyro docs, then high-pass filter is marked as optional there, you can just take it away. Not sure about arduimu, as if there already is algorithm in place in code which deals with high-pass filter effects, then just disabling high-pass filter does not do any good. After all, you can compensate for high-pass in code, its just makes life more difficult, imo.
From your comment T - that's exactly what I saw too. If you look at the next to last plot on my post from November 8, 2009 at 11:41am , - right in the middle - it's obvious 'decay' behavior (you can also see it in the first 'big jolt' movement as well, although not as pronounced. Andrus seems to have interesting ideas/opinions on what is going on....
Don't like the 1MOHM's RF pickup ability or the effective output
impedance imposed upon the 1X rate during ADC sampling (as mentioned by Andrus above).
Or the wacky, but somewhat cool way, the IC backfeeds VREF out
of the 4X input pin for highpass reset. It's all too messy.
Let the drift through, DCM should take care of it.
Thank you very much for running the tests with the Xbee. This is useful information. It looks like a 9" separation between the Xbee and the gyros is a good rule of thumb.
Bill
Now, you mentioned that gyro outputs "slowly settle" after movement - I would bet that this is because of capacitors indeed, both low-pass and high-pass filters play there. Bigger effect comes from filter with lower cutoff frequency, i.e. from high-pass filter in this case. I should be easy to understand, why is that - if there is gyro output voltage change, then filter capacitor starts to charge and its voltage increases. When gyro output returns to zero, then capacitor starts to discharge and its voltage drops smootly. Low-pass filter is not an issue here, as its integrates gyro output - it will make sharp movement to look like slower one, but you still know, how big the total movement was. If there is movement during 1 microsecond, but you sample with 100Hz, then you may miss that movement, unless you have suitable low.pass filter, which records the movement for you in its capacitor. Even though it will seem, that movement lasted longer and was with less intensity, your DCM logic is still happy.
High-pass filter, however, causes issues here, it causes DCM to lose movement data if movement lasts longer than high-pass filter period.
Low-pass filter, btw, can help you to overcome saturation issue with 4x outputs in case they are caused by sharp movements (should not be an issue once your IMU gets off the ground). Increasing long.pass filter period (putting bigger capacitor) may smooth out those movements.
In general I think that you are fine, you just need to accept the fact, that gyros do drift and you need to compensate, and once you try to rotate your board for, say, 10 sec, and log that, then you will want to disable these high-pass filters there.
I'm planning to order gyros LPY0503 and LPR0503 in order to see how they behave (sparkfun says, that they are 30 deg/sec, but this applies to 4x amplified output; they are 120deg/sec unamplified). Your experiments are therefore very interesting, as Razor uses similar gyros. IT would be perhaps interesing to see, do these gyros settle faster initially if you reset them shortly after power-on with HP input.
separation at 9"
So in short, it appears that having Xbee by Razor IMU board on Arduino will affect amplified gyro output, while there is no significant effect on non-amplified gyro output, cross correlated with separation distance between them and XBee power output level. Longer the distance and/or lower the power - the better.
At 200mW XBee power level and separation distance of 9" I could not see any noticeable effect.
-
1
-
2
-
3
-
4
of 4 Next