IMU nose Dive problem/solution
Here is my theory:
I did some quick number crunching on some equations and found that it totally makes sense that pitch would "depart reality" more-so than roll and very rapidly as both him and I have both observed.
(edit)
For a 30deg AOB turn at about 1.5g's total the attitude solution if improperly estimated would be off in roll a couple of deg and about 30deg in pitch causing this nose dive affect.
(correction)
For a 60deg AOB turn at 2G's the estimation in pitch was off by 10 deg if centripetal was incorrectly calculated. The error would be in the positive direction causing the stabilty loop to push the nose over causing the "imu nose dive problem"
I was extremely surprised at how quickly pitch departed at very shallow angles of bank. So this lead me to suspect one thing beings my math modeled exactly what I was seeing in the air....centripetal. Here are the pitfalls I evaluated:
Gps latency
Gps bandwidth
Propper velocity mapping into components
So I will discuss in order
Latency. GPS has it...big surprise well how much is it and how much can it affect the solution. Depending on the module I have read 10seconds to about 0.5. Well for my Ublox it was about 0.75 to 1.5 depending upon the rep rate selected and positional accuracy (number of sats). I plotted it out and you can see how poorly the centripetal was accounted for in my "car test run". It's ok but in its worst case scenario could be off as much as 13 deg....which is better than 45deg with no centripetal at all for the runs I did. However 13 off and 1.5 seconds late quickly would cause things to go south
GPS bandwidth. Its at best 4Hz....need I say more. You are going to miss changes in speed quite a bit and loose a lot of accuracy. Also note the graph where GPS clearly is reporting the wrong speed at the wrong time
Velocity mapping: This is how you map the velocity into the actual body velocities. Most people assume that the speed reported from the GPS is always out of nose of the airplane. This is mostly true except for in climbs. It is safe to assume that the v velocity (out the wing) is zero but not the w (out the belly of the aircraft). The total of u and w are the SOG from GPS and you must break them up. I'm pretty sure the imudevboard code does this but if it doesn't this is another large source for mis calculation
----------------------------------------------------
All of these things together are issues that can clearly throw off one thing....Centripetal estimation which was why we determined there was a 30deg offset in our crappy estimation. So with that solved (use airspeed instead) the problem goes away. I have hours of flight time on my IMU both with and without GPS and the nonGPS filter has yet to diverge from reality under self stabilized flight. GPS filter on the other hand....it depended on the airplane the autopilot....amongst a lot of other random variables that never made sense like calendar day. Some days it was fine and others it wasn't on the same aircraft which leads me to my next topic.
Noise/Vibration:
Gyro drift is due to temperature. When I tried to follow the drift using an integrator in software we had issues. Same idea and same effects and just as random. Some days fine and some days not. The filter DCM or what have you is a very dynamic thing and if you try to model a temperature drift with an integrator (in my humble opinion) it will only work assuming that your other estimations are perfect. Else the other errors will map into your temp compensation.....which does happen no denying it. Its ok if your gyros don't move that much with temperature and you keep an eye on the integrator however its way too unpredictable of a problem to assume your error state is a fixed target....It simply isn't.
I run a temperature comp on my gyros and get repeatable results every time. With my comp equations the end result is a gyro that will hold itself +- 5 deg for 5 min or so. There are a lot of other tricks here like circuit noise reduction and oversampling that can be done but this is huge if you want to keep your solution converged.
As far as vibration.....If a gyro gave crap results because of vibration then it wouldn't be any use in a 6dof filter. Your accelerometers produce noise with vibration and hence the reason we use gyros. I just don't see any room for allowance of gyros to be noisy in vibration. Pick good gyros and temp comp them and so many problems dwindle away very quickly
-----------------------------------------------------------------------------------------------------------------
update: addressing the airspeed question
My acceleration model
Best Regards and good luck in the IMU world
-Ryan
-
Comment by Scott Plunkett on October 14, 2009 at 4:34pm -
Ryan - you mentioned both in the podcast and in this response, the use of airspeed in your calculations - I am very curious about this approach. Could you elaborate? Share with us the sensor types you use, placement of probes etc.? I'm not sure I even understand from the brief description how the math would work.
-
Comment by automatik on October 14, 2009 at 5:01pm -
@Ryan - how did you do temp compensation of gyros? (on board temp monitoring and correlation or....)
-
Developer Comment by Ryan Beall on October 14, 2009 at 5:06pm -
the gyros have a voltage out proportional to temp on the chip.....convert that to a temp and compare it to the voltage out....least squares fit a curve and that's it. So for a given temp there is a given voltage associated that gets subtracted. ie:
gyro_volts_out = gyro_volts - gyro_temp_comp(gyro_temp);
gyro_deg = gyro_volts_out * gyro_scale;
-
Developer Comment by Ryan Beall on October 14, 2009 at 5:24pm -
@Scott , I updated the post with a pic of my kinematics model. Its fairly accurate for conventional aircraft, making only the assumptions that make sense. As far as the pressure side of things....any sensor will do as long as you get your units all to agree and its calibrated fairly accurate (I temp comp this as well). You can see the pressure sensor on my mother board. I just run a fuel tube type line up to a solid pushrod holder type tube out on the leading edge of my wing about 3" out and away from the prop.
-
Comment by Jack Crossfire on October 14, 2009 at 5:51pm -
It was real nasty in helicopters. Blade vortex interaction would cause vibration in certain headings but not others, so it would hover in 1 heading & fly away after turning. If blade tracking wasn't spot on, it would also fly away. Using plastic blades instead of carbon fiber improved the BVI matter.
BVI is so noisy, it was our tests in BVI vibration that got us kicked off the golf course.
Fortunately now that IMU's R everywhere, people won't have to go through the process of discovery we went through.
Having all these sensors on the main board is a recipe for drift because of the temperature change between ambient air & computer. Mount them where they're close to the ambient temperature.
-
Comment by Jack Crossfire on October 14, 2009 at 6:01pm
-
Here's the video of a full size rotor blade flexing as it passes through the tail rotor vortices. In a CF model blade, all that energy goes straight to the IMU.
-
Comment by Rana on October 14, 2009 at 7:05pm -
Hi Ryan !
Hats off to you for your incredible work !
Bill, in his poscast has indicated a bout the sucess stories by a test pilot in India (It's me) with red board on different planes.
I am able to use the red board in my Wingdragon 3CH Electric Pusher Plane, Wingdragon Sportster 4CH Electric Pusher Plane, Standard 40 size aileron trainer powered with OS46 and then powered with OS55 nitro engines. Finally I have succesfully flight tested the red board in my "Ultimate Nitro Pusher plane" you can see it in my blog.
What precaution I took is I took only balanced props for my planes then put the red board away from the propulsion device motor / engine, preferably at place which was having least vibration or no vibration.
I used foam rubber and raw cotton for the housing housing of the board, which not only absorbs the vibrations but also increase the boards imunity towards temperature due to sun light, while the plane is airborn.
Your findings and results are incredible !
Your suggestion to use airspeed sensor seems quite good !
I would equest Billu Bhaiya (Mr. Bill Premerlani) to comment on your findings and solution.
Thanks & Best Regards
Rana
-
Comment by Rana on October 14, 2009 at 7:08pm
-
Oh my God !
Jack how did you do that !!!
How you could put the camera on the rotor of the heli !
-
Comment by Garry Qualls on October 14, 2009 at 8:04pm -
The MEMS gyros vs. vibration issue seems to be a recurring theme around here. I'll try to explain what happens. Any MEMS gyro or accelerometer will have bits inside that are flexible because those bits bend when they are accelerated, in proportion to the amount of the acceleration. Any flexible structure will have resonant frequencies and if you shake something at one of those frequencies, it will vibrate with larger and larger deflections (resonate). At that point, the deflections don't have anything to do with how much acceleration is being experienced, just how much energy has been absorbed from your shaking. Think Tacoma Narrows Bridge. So any MEMS gyro will have resonant frequencies that will render parts of it useless and likely make it pump out useless noise. Figure 7 in this paper:
http://www.coventor.com/pdfs/APCOM07_scene3D_full_paper.pdf
shows a nice illustration of a vibrational analysis of part of a MEMS gyro and a plot of its frequency response. The plot for that design shows three resonant frequencies in the neighborhood of 17 or 18 kHz and they show the "mode shape" for the lowest of the three frequencies. That paper is worth checking out just to see how complicated things are inside one of these little gyros. Ideally, every gyro data sheet would list the first few resonant frequencies that cause problems so people could make informed decisions. I hope this helps...
-
Comment by Rana on October 14, 2009 at 8:29pm
-
Nice write up Garry !
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Documentation Editors
51 members
-
Agricultural UAVs
136 members
-
Japan ArduCopter Group
51 members
-
ArduRover User Group
185 members
-
Moderators
24 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
You need to be a member of DIY Drones to add comments!
Join DIY Drones