AttoPilot V3.0 6DOF IMU Q&A - Page 5

boyisabird · Oct 02, 2009, 11:14 AM

Hi guys, one question, one comment.

Tracker... sounds like these things are already out. Is this true? I'm assuming its basically just a rotating antenna w/ xbee or similar and small chip that does the trig to keep the antenna pointed near the plane?

Price. For what its worth, $3,000 is what federal government types can put on a credit card without having to go through a painful (and often losing to another vendor due to the possibility of a sole source justification not being approved) requisition process...

dmgoedde · Oct 03, 2009, 02:32 AM

Quote:

Originally Posted by airmcn_3

Second reason is to give you the ability to buy just the IMU and integrate it into their own system.

Bit of a clarification... it is a 6 DOF AHRS, not just an IMU sensor suite. There is a processor inside, and it spits out a complete set of attitude solution data. You may also stream into it airspeed data for full corrections of centrifugal forces. You may also configure and flash to it desired update rate, data format, baud rates, etc.

It is like a highly expanded 6 DOF sensor that Analog devices sells for $700 (ADIS16355). Theirs is only 6 DOF sensors with a marginal temp compensation performed on the gyros across mil-spec range, inter-axis alignments as part of the calibration, and the relatively advanced features of G-force corrections on the gyros. What mine adds is:
1) Fully hermetically sealed. Use it below the dew point if you wish.
2) More accurate gyro bias calibration (note the ADIS pdf spec sheet 1 sigma of bias comp on page 9, 2nd plot from top on the right... it is HUGE at about 0.25 deg/sec!!!). My 1 sigma is on the order of 0.04 deg/sec as indivicually calibrated for each assembled IMU.
3) 12 seperate corrections for intrer-axis alignment of the accels and gyros
4) 9 parameters temp-compensated. This is 3 gyro biases and both bias and scaling factors of the 3 accel axes.
5) Full AHRS solution output. Not just a compensated sensor suite.
6) Internal update rates > 200 Hz. This is now possible because I have thrown an ENTIRE 8 core Prop chip inside the AHRS and split up the tasks across several cores. No need to be conservative on the code now.

I'm happy to be finishing development of this product since work began last November.

dmgoedde · Oct 03, 2009, 02:36 AM

Quote:

Originally Posted by boyisabird

Hi guys, one question, one comment.

Tracker... sounds like these things are already out. Is this true? I'm assuming its basically just a rotating antenna w/ xbee or similar and small chip that does the trig to keep the antenna pointed near the plane?

Price. For what its worth, $3,000 is what federal government types can put on a credit card without having to go through a painful (and often losing to another vendor due to the possibility of a sole source justification not being approved) requisition process...

Tracker logic controller makes assumption that the UAV home position was locked nearby the tracker. Then, only a few bits of data in the downlinked $ATTO telem stream are required for the tracker control board to do the required trig, and tell the pan/tilt servos where to point. There are servo-specific calibrations to do in each tracker control board. The root cause need for this is the pots in each servo have a different scaling factor.

Team Melbourne UAV used an AttoPilot Tracking antenna. My understanding of the crash is the tracker followed the UAV down to the ground!

spiggo89 · Oct 03, 2009, 02:45 AM

Quote:

Originally Posted by dmgoedde

1) Fully hermetically sealed. Use it below the dew point if you wish.

Does this mean that there is a vacuum present inside the seal? If not howcome the internal air doesn't dew too?

Quote:

Originally Posted by dmgoedde

2) More accurate gyro bias calibration (note the ADIS pdf spec sheet 1 sigma of bias comp on page 9, 2nd plot from top on the right... it is HUGE at about 0.25 deg/sec!!!). My 1 sigma is on the order of 0.04 deg/sec as indivicually calibrated for each assembled IMU.

Would you mind elaborating on how you were able to get it so low?

Quote:

Originally Posted by dmgoedde

3) 12 seperate corrections for intrer-axis alignment of the accels and gyros

4) 9 parameters temp-compensated. This is 3 gyro biases and both bias and scaling factors of the 3 accel axes.

Again, more details would be appreciated

Quote:

Originally Posted by dmgoedde

5) Full AHRS solution output. Not just a compensated sensor suite.

Is this the equivalent to a commercial Kalman IMU? (e.g. the x-sens mti-g)

Quote:

Originally Posted by dmgoedde

6) Internal update rates > 200 Hz. This is now possible because I have thrown an ENTIRE 8 core Prop chip inside the AHRS and split up the tasks across several cores. No need to be conservative on the code now.

I'm happy to be finishing development of this product since work began last November.

Nice work, and good to hear. I'm glad there are people like you helping the hobbyist community against these grubby corporations.

surf89 · Oct 03, 2009, 07:13 AM

all this sounds great. count me in as long as its not to many $$$$

Surf

kbosak · Oct 03, 2009, 08:07 AM

1.
For operation below dewpoint you need to make all hermetically sealed... Any short in digital interface is fatal anyway. Claiming that you can fly sealed IMU and unsealed digitals is same as taking unsealed IMU and letting it go. Yes it will fly perfectly for thousands of flights if there is good bias filtering algorithm.
2. Gyro accuracy error is one thing, but gyro integration error during maneuver is another.
Whatever you do, you must average towards accelerometer (or magnetometer) in order to eliminate both drifts.
I can have as much as 25deg/s gyro drift on my gyro setup over temprange, yet the Kalman filter is filtering the bias out, together with integration error, even in infinite loiter. It is just recentering the virtual gyro offset as it flies, using BOTH accelero data and gyro data (basically 'unconfirmed' accelero movements not followed by gyro are rejected and vice-versa, all is handled by the Kalman filter model).

I believe you are throwing all research in one direction, forgetting that 200Hz is inherently less resistant to vibration than lower sampling frequencies from the other autopilots. This is not the issue whether 10, 50 or 200Hz is better for calculation (200 is), the problem is that 200Hz lowpass filter has some sensitivity to 500Hz vibration as well, exactly where the things spin (30K RPM).

The real benefit is that when calibrating the sensor for temperature and using insanely high sampling frequency you are making simple filtering algorithms work better. So by choosing obsessively good gyro temp conditioning and sampling rate you can spend less time on heavy math, and time is money.

dmgoedde · Oct 03, 2009, 04:00 PM

kbosak: I started out with all the "heavy math" of auto bias tracking. It worked fine and robustly enough for many hours of flight tests in flying wings and 3D aerobatic planes. What happened is I continued to try new things and found something that is giving me better results, albeit my cuurent method is a royal pain in the arse in terms of calibration. Luckily, the calibrations don't shift by an appreciable amount over time once they are determined the first time.

25 deg/sec is rather huge over the temp range, and I assume you are talking about the upper limit of your system (flexipilot) being that which was stated in one of your spec sheets: +60 Centigrade. Yes, you can have the "Kalman Filter" use accel data and track bias, and I used to have my filter do this, however what do you do in the event of a sudden shift in the gyro bias? I used to see this, and of course it corrects out automatically but this can take time meanwhile the IMU solution can either diverge or be inaccurate. I discovered these large bias ranges and sometimes sudden jumps were more of a stress PCB layout issue. Small bias drifting is one thing, but with potential of 25 deg/sec change over your temp range is so large that I would be afraid of overloading the ability of the filter to track large temp changes all at once. Nowadays (after making countless experiments on how to best mount the gyros and PCB layout) I only see about a 2.5 deg change in bias over the entire temp sweep range of -40 C to +90C. I also discovered (then later realized it is a low-key parameter mentioned in the spec sheet) that the magnitude and orientation of G forces on the sensor affect the bias by non-trivial amounts (1 g can cause 0.25 deg/sec bias change, depending on the orientation of the gyro). So now with such a smaller 2.5 deg/sec change in bias over the -40 to +90 C range, it is rather easy to take 100 second sample averages at 14 temperature points across this range, then have a calibration table written in the autopilot for mere linear interpolation, and at any temperature already know the bias within approx +/-0.04 degrees/sec (that is a +/- 1 sigma around the mean).

It might sound ridiculous to have a hard-written calibration table for the gyros rather than automatically track bias in real time, but again I have done auto-tracking method in the past and for my needs judged it inferior to what I now do. With the hard-coded table of gyro bias versus temperature, there is ZERO wait time after powering up. There is no need to capture an initial bias and start tracking it. Quite simply, my IMU starts spiting out valid attitude data within a few milliseconds of being powered up. Another advantage is for the yaw gyro I DON'T have to rely at all on GPS heading info to track that bias. The GPS method is much less than satisfactory in windy situations. A magnetometer would be better, but I am trying to keep this initial 6 DOF IMU/AHRS with the most lenient export classification by purposefully excluding magnetometers and any ability for long duration dead reckoning navigation.

It would take pretty gross condensation of moisture to cause the digital electronics to fail, e.g. shorts of logic lines to source or drain. I am MUCH more worried about something I feel is 1000X more sensitive: faint traces of moisture on the analog pins of the gyros/accels/filter caps/ADC sample pins causing voltage level shifts. My IMU (the "Goedde Filter") is handling integers to 20 bit resolution on 5V gyros and 3.3V accels. I did this to ensure the math resolution is down in the noise of the sensors. There are tricks involved in my method that do real time estimation of a least squares linear fit on the incoming ADC samples as they are clocked in from the ADC. As I mentioned, I admit 20 bit integers were chosen to ensure the math resolution is well within the noise of the sensors so that I avoid stupid integer math errors; I need to keep the noise nice and white and Gaussian (it's a hopeful assumption, but it appears to hold true). If you look at what a 20 bit resolution is on 5 volts, it would be s step size of around 5 uV (that's micro Volts) and 3.3uV for the accels. It is worthwhile to do everything possible to keep it all bone dry. In a similar vein, the 2 channel OpAmp used in the FMA sensors (the AD8552) uses ~1000x voltage multiplication from the raw thermopile levels, and in the spec sheet Analog Devices mentions certain special PCB layout techniques and mentions it worthwhile to apply coatings to the PCB to prevent adventitious moisture from shifting voltage levels. If you have ever cracked open an FMA sensor head, you will notice they read the spec sheet of the OpAmp and used a silicone conformal lacquer.

Coatings can cause side effects in their own right. As a chemist experienced in air-free and moisture-free synthesis and having used special techniques to dry solvents down to the ppb level of moisture, I can tell you that there is at least ppm or ppt moisture levels in any liquid or solution you buy. So putting a conformal coating on electronics might prevent them from gross moisture, but will actually ADD traces of moisture. Coatings can also change the stress behavior of the circuit or analog component. So, I opted for no coatings, researched the best PCB layouts, and chose to hermetically seal the IMU.

No vacuum inside the package. I live in Arizona and most of the year the relative humidity is < 10%, with dew points below freezing. Even this is not good enough however because if the IMU were sealed with this atmosphere inside then condensation frost might happen at -30 or -40 C. So I do several things:

1) Fully test the assembled device (but not calibrate yet)
2) Anneal at 135 C to relieve solder stresses from the hand assembly portion
3) Clean the HELL out of it, then inspect
4) Bake at 100 C for extended time period (there is even moisture in the device packaging materials, and possibly within the PCB FR4 fiberglass layup as well, not to mention volatile solvents from the cleaning process)
5) Immediately after baking, solder on the hermetic seal.
6) Use alcohol to wipe off residue of flux from the outside where the last solder joints were made
7) Anneal at 135 C again due to the last solder joints.
8) Extensive calibration.

I considered adding some sort of moisture "getter" inside the sealed AHRS package, but don't think that is really required.

Overall, I took this crazy route based on data from a long development process. I also have heard from a military UAV maker that they are unhappy that the autopilots they have used in Afghanistan don't work if you let the UAV sit on the tarmac in full sun and the UAV temps up to 60+ C. They mentioned elaborate schemes of pumping air conditioning into the UAV avionics bay prior to launch. I also thought it kind of funny that IMUs use sensitive analog components and this would preclude, in a practical sense, usage below the dew point.... certainly not down to bottom of the mil spec range of -40 C. So why not kill the problems at their root cause, and allow operation over the entire range?

Regarding 200+ Hz IMU iteration and rejection of vibration comment - there is nothing of value in that statement. The high rate of the IMU loop is for the purpose of high-fidelity integration of the 3-axis gyros to propagate the model forward in time. This is why I went to the pain of carefully optimized code and fast integer math to make the code fast in a single 20 MIPS core, and the special 3D nature of the way gyro rates update the model in a method without singularities, and why I even break down certain self-referencing equations into quarter steps running at over 800 Hz.

The ADXRS610 gyros are specially designed to be essentially immune to vibration. They have a dual sensor structure per gyro. they have an internal impedence on the rate output of 180 k Ohms, and I use an external cap of 2.2 nF. Therefore the -3db bandwidth is 401 Hz. No problems there. Now to the Accels: internal impedence of 32 k Ohms and I chose external cap of 0.22uF. -3db bandwidth works out to 23 Hz. THIS is why my IMU has been proven in many flights to be essentially immune to vibration; the 23 Hz bandwidth is absorbing 100+ Hz harmonics of the motor and airframe. You just don't need fast bandwidth on the accels because the model is primarily driven by predicitions from the gyros, which are themselves pretty much immune to vibration.

Also, I chose accels with +/- 11g range. If I were to have chosen +/- 2g or +/- 3g accels like others, then there is the danger when near the limit of the signal (with +/- noise) being clipped on one end of the noise distribution. This would seriously screw up the IMU model in high G manuevers. I saw this in my early IMU work using +/- 3g accels with 100Hz data logging to SD card. Whenever any one of the accel axes saturated the IMU model solution "blew up". Using +/- 11g accels will allow sustained banking turns of well over 60 degrees, but ONLY IF the effect of these g forces on the gyros is accounted for.

This is SUCH a nifty and fun thing to have done for development. 2009 has been a strange year in part due to the IMU development. Part mystery novel, part horror story.

dmgoedde · Oct 03, 2009, 04:16 PM

Quote:

Originally Posted by kbosak

I believe you are throwing all research in one direction, forgetting that 200Hz is inherently less resistant to vibration than lower sampling frequencies from the other autopilots. This is not the issue whether 10, 50 or 200Hz is better for calculation (200 is), the problem is that 200Hz lowpass filter has some sensitivity to 500Hz vibration as well, exactly where the things spin (30K RPM).

This is the source of the misunderstanding....
1) I am not using any sort of Kalman Filter.
2) When I described 200Hz, I was not describing the bandpass of the accels. The 200Hz refers to the fact that my IMU code cycles through 200 times / sec.

My IMU is not inherently less vibration resistant than others. In fact I am quite certain it is more so by a fair margin based on close conversations with others that have used the main systems. Also, I have used the IMU in a grossly mis-balanced prop situation on a 20 ounce e-Foamy of Chris (airmcn_3) and we were not able to confude the IMU. With finger on the IMU and motor running, the buzzing was so strong so as to make your finger numb. Not only did it keep the attitude solution in flight like this, we did bizarre non-UAV things like 400' vertical climb with snap rolls, and recovery from inverted flight all without incident.

Chris - were we EVER able too confuse the IMU over those 5 weeks of testing? Oh yeah, it was 115 F then also.

dmgoedde · Oct 03, 2009, 04:38 PM

Quote:

Originally Posted by spiggo89

Nice work, and good to hear. I'm glad there are people like you helping the hobbyist community against these grubby corporations.

I AM a grubby corporation. But this is to be expected. The amount of time and money I have blown on development is about 100X anything a part-time hobbysist would do. I have large debts to make up, otherwise all this was a giant waste of personal money. If I wanted to make a simple IMU that works "OK" under standard conditions, then I was 100% done 9 months ago. Back then my IMU was self-tracking of all gyro biases, and it all fit on a 1" x 1" single sided PCB and none of the gyros were mounted orthogonal to the main board. There were no factory calibrations, and no corrections applied for inter-axis misalignment between the sensors. It all would have been fine in high wing trainers and was even tested mostly in small flying wings.

BUT - my goal was to screw with the established autopilot companies, and even exceed them in respect of the torture-ability of the IMU. I wasn't trying to just introduce another IMU that passes the generic test of working near room temperature and calling +/- 5 to 10 degree attitude in flight as "OK" (Page 3 under "Attitude Estimation Error: Roll and Pitch"). In a sense, thermopiles spoiled me because they are immune to G forces and vibration, and have an inherent accuracy around 1-2 degrees. In most situations thermopile attitude sensing exceeds any IMU. So, here I am trying to make my initial 6 DOF IMU "perfect" and handling all effects and conditions.

Inter-axis misalignments:
Even if the sensor packages are mounted perfectly orthogonal, the internal sensing structures might be off a couple degrees. It's all described in the spec sheets of these sensors. This means in practice the sensing axes are NOT orthognal, and therefore rotation intended to be purely along one axis actually "maps" onto the other two axes by some small amount. Typically the effect is somewhere around +/-10 parts per thousand (example: 100 deg/sec in one axis causes an apparent rotation of 1 deg/sec on another axis). Same goes for the 3 accel axis. This is not something you have to track continually in flight, instead it can be measured and calibrated out at the factory.

As an example using gyros, consider that the yaw rate should be zero if only pitch or roll rate is present but no yawing is happening. In reality, any non-zero rate in another axis maps into yaw and causes the yaw sensor to respond. In careful tests of isolated movements, I measure what fraction of motion in each axis maps into the other two axes, then these corrections go into a table. In the IMU code the raw analog data of each gyro is bias corrected then scaled into an angular rate. Next, depending on the raw rates in the other two axes, we know how much should be mapping into this axis of interest, and corrections are applied. In practice this is NOT a giant complex problem requiring insane math skills to correct. It is SIMPLE: other axis' rates map into the other axes by a certian ratio. In reality the ratio has to do with sine of the angular dipping into one axis of another. 0 misalignment causes 0 mapping of one rate onto the other sensor. 0.5 degrees would cause 8.73 parts per thousand of one axis rotation being mapped into the other. Here is an example from a data table entry in the Atto IMU code, in part per thousand:

RollCorrect_Pitch = 18
RollCorrect_Yaw = -13
PitchCorrect_Roll = -31
PitchCorrect_Yaw = 21
YawCorrect_Roll = -14
YawCorrect_Pitch = -6

So there you have it: in one fell swoop all 3 gyros are corrected for inter-axis misalignment that comes from both sources of error: PCB and package misalignment, and internal sensor structure alignment.

dmgoedde · Oct 03, 2009, 05:15 PM

Quote:

Originally Posted by dmgoedde

I AM a grubby corporation.

Let me elaborate a bit:

$5000 for an IMU autopilot might seem like a lot, especially when you know the components only cost $300 to turn out a copy, and maybe another $500 in PCB assembly, workmanship and calibration. Also, $5000 is far above the average person's hobby budget. Also, there are things like the Ardu-IMU floating around for $100. All these things make average hobby UAV people get angry or just confused, and think the autopilot companies are raping people.

Consider this: there is insurance, huge development costs, business costs, taxes, and after all this a company needs to pay off debt and turn a profit. What the company gives in return is a professionally designed and developed product that has gaurantees to work, otherwise it is replaced or fixed. When someone pays $5000 for an autopilot you'd better be sure they aren't interested in coding or having to configure Linux on their machine to support it, load firmware, screw around with XML clode lines. No, they expect to install it, use a GUI or simple interface to get it customized for the airframe, and then they expect it to work.

Also consider, the calibrated Analog Devices ADIS 6 DOF sensor suite I alluded to earlier sells for $700. My AHRS meets and exceeds all of their specs, adds a slew of additional corrections, and includes a configurable setup and internal high powered 32 bit processor for a complete and very accurate attitude solution. It accepts speed data for full centrifugal corrections, therefore the attitude accuracy specs are the same in level flight or loiters... there is no difference. So based on simple logic, the unit I described would have to sell for > than the $700 price of the ADIS sensor. With configurable setup and full attitude solution it is in the performance ballpark of the $4000+ stand alone AHRS units already out there. Of course it won't retail for $4000, but also not anywhere near as low as $700.

kbosak · Oct 03, 2009, 07:02 PM

Quote:

Originally Posted by dmgoedde

Small bias drifting is one thing, but with potential of 25 deg/sec change over your temp range is so large that I would be afraid of overloading the ability of the filter to track large temp changes all at once.

For me it works as designed.

Quote:

Originally Posted by dmgoedde

So now with such a smaller 2.5 deg/sec change in bias over the -40 to +90 C range, it is rather easy to take 100 second sample averages at 14 temperature points across this range, then have a calibration table written in the autopilot for mere linear interpolation, and at any temperature already know the bias within approx +/-0.04 degrees/sec (that is a +/- 1 sigma around the mean).

Of course pre-adjusting the input this way is best. But a well adjusted Kalman is filtering it out event without temp compensation on very bad gyro.
So the temp based pre-adjustment is not absolutely necessary using classic IMU implementation and even current mass market gyros.

Quote:

Originally Posted by dmgoedde

It would take pretty gross condensation of moisture to cause the digital electronics to fail, e.g. shorts of logic lines to source or drain. I am MUCH more worried about something I feel is 1000X more sensitive: faint traces of moisture on the analog pins of the gyros/accels/filter caps/ADC sample pins causing voltage level shifts. My IMU (the "Goedde Filter") is handling integers to 20 bit resolution on 5V gyros and 3.3V accels.

Analog signal conditioning in FLEXIPILOT handles this OK.
Analog filter design with proper choice of impedances is the key.

Quote:

Originally Posted by dmgoedde

So why not kill the problems at their root cause, and allow operation over the entire range?

Because major operators operate in the desert...

spiggo89 · Oct 03, 2009, 09:42 PM

Quote:

Originally Posted by dmgoedde

So why not kill the problems at their root cause, and allow operation over the entire range?

Quote:

Originally Posted by kbosak

Because major operators operate in the desert...

I'd put this down to a lack of understanding of the English language?

Mecha · Oct 03, 2009, 11:46 PM

will Atto3.xx have autonomous takeoff/landing option? or deep stall landing?

Paul_BB · Oct 04, 2009, 04:24 AM

Quote:

Originally Posted by kbosak

For me it works as designed.

I agree, EKF is at least 10x more performant then any complementary filter (CF).
By the way, somebody I met compared the Extended KF with the Unscented KF and told me (To Be Confirmed...) that the UKF brings another order of magnitude in performance.
While I found that the computational load of the EKF is maybe 100x greater than the one of the CF (in case of a 7 states EKF), this guy told me that the computational load of the UKF is not so bigger than the EKF one (for the same number of states), about twice as big.
Can you describe your EKF (number of states, decoupling etc..) if this information is not secret ?

kbosak · Oct 04, 2009, 05:47 AM

I am using EKF with a few states, but cannot tell details as it is going commercial.
Sorry. Until I am sure I have something significantly better than any competing product, I am not announcing it. Anyway I hesitate to speak openly too much about HOW to make things. I am pointing the general directions that there are trade-offs and no single way to design. From the user point of view, this just.. works. It is off here or there when you shake it in random way, but it is not Ice Shaker IMU.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Alert F-86 pre order list	TFLG	Inland Slope Rebels	97	May 30, 2007 11:10 AM
Castle Creations Open Discussion V3.0	Patrick del Castillo	Castle Creations	150	Jan 02, 2007 08:54 AM
Discussion Shrike Pre-order List Is Now Closed	SkyKing RC	Slope	0	Nov 23, 2006 06:49 PM
Notice that the A-10 is now Avail for Pre-order from Online shops	Etonic	Parkflyers	6	Feb 22, 2003 11:50 AM
Pre-Order the GWS Zero Now.	gbagley	Aircraft - Electric - Airplanes (FS/W)	0	Mar 11, 2002 11:30 PM

Oct 02, 2009, 11:14 AM	#61
boyisabird Registered User Join Date: Aug 2008 Location: Bay Area, CA Posts: 14	Hi guys, one question, one comment. Tracker... sounds like these things are already out. Is this true? I'm assuming its basically just a rotating antenna w/ xbee or similar and small chip that does the trig to keep the antenna pointed near the plane? Price. For what its worth, $3,000 is what federal government types can put on a credit card without having to go through a painful (and often losing to another vendor due to the possibility of a sole source justification not being approved) requisition process...

Oct 03, 2009, 07:13 AM	#65
surf89 Registered User Join Date: Oct 2009 Posts: 4	all this sounds great. count me in as long as its not to many $$$$ Surf

Oct 03, 2009, 08:07 AM	#66
kbosak Registered User Join Date: Jun 2007 Location: Wrocław, Poland Posts: 552	1. For operation below dewpoint you need to make all hermetically sealed... Any short in digital interface is fatal anyway. Claiming that you can fly sealed IMU and unsealed digitals is same as taking unsealed IMU and letting it go. Yes it will fly perfectly for thousands of flights if there is good bias filtering algorithm. 2. Gyro accuracy error is one thing, but gyro integration error during maneuver is another. Whatever you do, you must average towards accelerometer (or magnetometer) in order to eliminate both drifts. I can have as much as 25deg/s gyro drift on my gyro setup over temprange, yet the Kalman filter is filtering the bias out, together with integration error, even in infinite loiter. It is just recentering the virtual gyro offset as it flies, using BOTH accelero data and gyro data (basically 'unconfirmed' accelero movements not followed by gyro are rejected and vice-versa, all is handled by the Kalman filter model). I believe you are throwing all research in one direction, forgetting that 200Hz is inherently less resistant to vibration than lower sampling frequencies from the other autopilots. This is not the issue whether 10, 50 or 200Hz is better for calculation (200 is), the problem is that 200Hz lowpass filter has some sensitivity to 500Hz vibration as well, exactly where the things spin (30K RPM). The real benefit is that when calibrating the sensor for temperature and using insanely high sampling frequency you are making simple filtering algorithms work better. So by choosing obsessively good gyro temp conditioning and sampling rate you can spend less time on heavy math, and time is money.

Oct 03, 2009, 04:00 PM	#67
dmgoedde dmgoedde Join Date: Aug 2007 Location: Gilbert Arizona Posts: 1,428	kbosak: I started out with all the "heavy math" of auto bias tracking. It worked fine and robustly enough for many hours of flight tests in flying wings and 3D aerobatic planes. What happened is I continued to try new things and found something that is giving me better results, albeit my cuurent method is a royal pain in the arse in terms of calibration. Luckily, the calibrations don't shift by an appreciable amount over time once they are determined the first time. 25 deg/sec is rather huge over the temp range, and I assume you are talking about the upper limit of your system (flexipilot) being that which was stated in one of your spec sheets: +60 Centigrade. Yes, you can have the "Kalman Filter" use accel data and track bias, and I used to have my filter do this, however what do you do in the event of a sudden shift in the gyro bias? I used to see this, and of course it corrects out automatically but this can take time meanwhile the IMU solution can either diverge or be inaccurate. I discovered these large bias ranges and sometimes sudden jumps were more of a stress PCB layout issue. Small bias drifting is one thing, but with potential of 25 deg/sec change over your temp range is so large that I would be afraid of overloading the ability of the filter to track large temp changes all at once. Nowadays (after making countless experiments on how to best mount the gyros and PCB layout) I only see about a 2.5 deg change in bias over the entire temp sweep range of -40 C to +90C. I also discovered (then later realized it is a low-key parameter mentioned in the spec sheet) that the magnitude and orientation of G forces on the sensor affect the bias by non-trivial amounts (1 g can cause 0.25 deg/sec bias change, depending on the orientation of the gyro). So now with such a smaller 2.5 deg/sec change in bias over the -40 to +90 C range, it is rather easy to take 100 second sample averages at 14 temperature points across this range, then have a calibration table written in the autopilot for mere linear interpolation, and at any temperature already know the bias within approx +/-0.04 degrees/sec (that is a +/- 1 sigma around the mean). It might sound ridiculous to have a hard-written calibration table for the gyros rather than automatically track bias in real time, but again I have done auto-tracking method in the past and for my needs judged it inferior to what I now do. With the hard-coded table of gyro bias versus temperature, there is ZERO wait time after powering up. There is no need to capture an initial bias and start tracking it. Quite simply, my IMU starts spiting out valid attitude data within a few milliseconds of being powered up. Another advantage is for the yaw gyro I DON'T have to rely at all on GPS heading info to track that bias. The GPS method is much less than satisfactory in windy situations. A magnetometer would be better, but I am trying to keep this initial 6 DOF IMU/AHRS with the most lenient export classification by purposefully excluding magnetometers and any ability for long duration dead reckoning navigation. It would take pretty gross condensation of moisture to cause the digital electronics to fail, e.g. shorts of logic lines to source or drain. I am MUCH more worried about something I feel is 1000X more sensitive: faint traces of moisture on the analog pins of the gyros/accels/filter caps/ADC sample pins causing voltage level shifts. My IMU (the "Goedde Filter") is handling integers to 20 bit resolution on 5V gyros and 3.3V accels. I did this to ensure the math resolution is down in the noise of the sensors. There are tricks involved in my method that do real time estimation of a least squares linear fit on the incoming ADC samples as they are clocked in from the ADC. As I mentioned, I admit 20 bit integers were chosen to ensure the math resolution is well within the noise of the sensors so that I avoid stupid integer math errors; I need to keep the noise nice and white and Gaussian (it's a hopeful assumption, but it appears to hold true). If you look at what a 20 bit resolution is on 5 volts, it would be s step size of around 5 uV (that's micro Volts) and 3.3uV for the accels. It is worthwhile to do everything possible to keep it all bone dry. In a similar vein, the 2 channel OpAmp used in the FMA sensors (the AD8552) uses ~1000x voltage multiplication from the raw thermopile levels, and in the spec sheet Analog Devices mentions certain special PCB layout techniques and mentions it worthwhile to apply coatings to the PCB to prevent adventitious moisture from shifting voltage levels. If you have ever cracked open an FMA sensor head, you will notice they read the spec sheet of the OpAmp and used a silicone conformal lacquer. Coatings can cause side effects in their own right. As a chemist experienced in air-free and moisture-free synthesis and having used special techniques to dry solvents down to the ppb level of moisture, I can tell you that there is at least ppm or ppt moisture levels in any liquid or solution you buy. So putting a conformal coating on electronics might prevent them from gross moisture, but will actually ADD traces of moisture. Coatings can also change the stress behavior of the circuit or analog component. So, I opted for no coatings, researched the best PCB layouts, and chose to hermetically seal the IMU. No vacuum inside the package. I live in Arizona and most of the year the relative humidity is < 10%, with dew points below freezing. Even this is not good enough however because if the IMU were sealed with this atmosphere inside then condensation frost might happen at -30 or -40 C. So I do several things: 1) Fully test the assembled device (but not calibrate yet) 2) Anneal at 135 C to relieve solder stresses from the hand assembly portion 3) Clean the HELL out of it, then inspect 4) Bake at 100 C for extended time period (there is even moisture in the device packaging materials, and possibly within the PCB FR4 fiberglass layup as well, not to mention volatile solvents from the cleaning process) 5) Immediately after baking, solder on the hermetic seal. 6) Use alcohol to wipe off residue of flux from the outside where the last solder joints were made 7) Anneal at 135 C again due to the last solder joints. 8) Extensive calibration. I considered adding some sort of moisture "getter" inside the sealed AHRS package, but don't think that is really required. Overall, I took this crazy route based on data from a long development process. I also have heard from a military UAV maker that they are unhappy that the autopilots they have used in Afghanistan don't work if you let the UAV sit on the tarmac in full sun and the UAV temps up to 60+ C. They mentioned elaborate schemes of pumping air conditioning into the UAV avionics bay prior to launch. I also thought it kind of funny that IMUs use sensitive analog components and this would preclude, in a practical sense, usage below the dew point.... certainly not down to bottom of the mil spec range of -40 C. So why not kill the problems at their root cause, and allow operation over the entire range? Regarding 200+ Hz IMU iteration and rejection of vibration comment - there is nothing of value in that statement. The high rate of the IMU loop is for the purpose of high-fidelity integration of the 3-axis gyros to propagate the model forward in time. This is why I went to the pain of carefully optimized code and fast integer math to make the code fast in a single 20 MIPS core, and the special 3D nature of the way gyro rates update the model in a method without singularities, and why I even break down certain self-referencing equations into quarter steps running at over 800 Hz. The ADXRS610 gyros are specially designed to be essentially immune to vibration. They have a dual sensor structure per gyro. they have an internal impedence on the rate output of 180 k Ohms, and I use an external cap of 2.2 nF. Therefore the -3db bandwidth is 401 Hz. No problems there. Now to the Accels: internal impedence of 32 k Ohms and I chose external cap of 0.22uF. -3db bandwidth works out to 23 Hz. THIS is why my IMU has been proven in many flights to be essentially immune to vibration; the 23 Hz bandwidth is absorbing 100+ Hz harmonics of the motor and airframe. You just don't need fast bandwidth on the accels because the model is primarily driven by predicitions from the gyros, which are themselves pretty much immune to vibration. Also, I chose accels with +/- 11g range. If I were to have chosen +/- 2g or +/- 3g accels like others, then there is the danger when near the limit of the signal (with +/- noise) being clipped on one end of the noise distribution. This would seriously screw up the IMU model in high G manuevers. I saw this in my early IMU work using +/- 3g accels with 100Hz data logging to SD card. Whenever any one of the accel axes saturated the IMU model solution "blew up". Using +/- 11g accels will allow sustained banking turns of well over 60 degrees, but ONLY IF the effect of these g forces on the gyros is accounted for. This is SUCH a nifty and fun thing to have done for development. 2009 has been a strange year in part due to the IMU development. Part mystery novel, part horror story.

Oct 03, 2009, 11:46 PM	#73
Mecha Registered User Join Date: Jul 2008 Posts: 157	will Atto3.xx have autonomous takeoff/landing option? or deep stall landing?

Oct 04, 2009, 05:47 AM	#75
kbosak Registered User Join Date: Jun 2007 Location: Wrocław, Poland Posts: 552	I am using EKF with a few states, but cannot tell details as it is going commercial. Sorry. Until I am sure I have something significantly better than any competing product, I am not announcing it. Anyway I hesitate to speak openly too much about HOW to make things. I am pointing the general directions that there are trade-offs and no single way to design. From the user point of view, this just.. works. It is off here or there when you shake it in random way, but it is not Ice Shaker IMU.