Gyro drift

Magnetometer
Mount magnetometer in wingtip away from any metal parts as far as possible. Matrixpilot does magnetometer calibration on the ground. Metal and magnetism interferes with the magnetometer.

Inirtial dead reckoning
http://www.diydrones.com/profiles/blogs/let-s-talk-about-inertial-dead-reckoning

Comment by William Premerlani on Sunday

Hobby grade gyros and accelerometers have enough bias and drift to require fit compensation. The situation is more difficult with accelerometers than for gyros, since their signals have to be integrated twice to get position, whereas gyros have to be integrated only once to get attitude. Also, accelerometers measure acceleration minus gravity, so you have to account for gravity.

Because you have to integrate accelerometer signals twice, any residual bias causes a position error that grows with the square of time, so it does not take long before uncompensated dead reckoning based on accelerometers becomes unusable.

There is another technique for long-term dead reckoning without GPS that does not rely so much on the accelerometers, that is based on airspeed and windspeed, if you have a pitot tube and a magnetometer. In that case, the position error grows only linearly with time. With that technique, you have to measure windspeed somehow, and that requires GPS. But if GPS fails after you measure windspeed, you can proceed without GPS, using the last measured value of windspeed.

Short term dead reckoning is performed by MatrixPilot. MatrixPilot is described here and here. The dead-reckoning technique that MatrixPilot uses is described here, and the accelerometer bias compensation is described here and here.

Bill Premerlani

http://diydrones.com/forum/topics/an-improved-method-for-accounting-for-acceleration-in-gyro-roll

http://www.diydrones.com/profiles/blogs/a-simple-deadreckoning

http://www.diydrones.com/page/uav-devboard

http://code.google.com/p/gentlenav/

http://www.diydrones.com/profiles/blogs/acceleration-compensation-flight-testing

post 31
https://groups.google.com/group/uavdevboard/browse_frm/thread/4f752c6dac37f3d3#

post 31

Regarding the gyro drift, there are only two ways that the gyro drift can change with time, either temperature effect or voltage effect. You report no temperature problem, so perhaps there is a voltage problem. If the voltage of the UDB power supply drops below 4.0 volts, the gyros will drift quite a bit.

Regarding RTH, I notice that you are using the rudder for navigation, but not the ailerons. For your plane, you might be better to use the ailerons for navigation rather than the rudder. I suggest you set AILERON_NAVIGATION to 1 and set a value for YAWKP_AILERON.

If you do use the rudder instead of the aileron, we have found that it is very important to set a value for ROLLKP_RUDDER. (I see that you have it set to zero.) It reduces the tendency for the navigation control to create a "dutch roll".

Regarding the magnetometer, I recommend to forget about the magnetometer. It really does not help much with an airplane, and it can actually make things worse, because the magnetometer is subject to magnetic interference from the motor, battery, ESC and power wires.

Regarding the FMA, I have no opinion, I have never used one.

Finally, I think you probably have the polarity of the servo channels set correctly, but it is worth double checking. If you get the polarity set correctly, it takes care of both stabilization polarity and navigation polarity. So, the following checks with check everything:

1. If you roll the plane, stabilization should raise the aileron on the higher wing, and lower it on the lower wing. 2. If you pitch down, the elevator should raise up. 3. If you set a value for ROLLKP_RUDDER, rolling the plane 90 degrees should deflect the rudder upward.

For tuning the gains, keep in mind that most of the gains are feedback stabilization gains, intended to keep the plane flying straight, level, and smoothly.

The only two navigation gains are YAWKP_AILERON and YAWKP_RUDDER.

The general approach for tuning the gains is to first get everything except the YAWKP gains set by doing stabilization flights only. You can do a lot of this on the ground: verify that the deflections are about what you would expect.

Once you the stabilization gains set, then adjust the YAWKP gains. My approach is to set them rather on the high side at first, and then back off, but others have other strategies, perhaps they will make some suggestions.

Finally, the community here can help you a great deal more once you start capturing the telemetry data.

Best regards, Bill

On Sat, Jun 16, 2012 at 7:02 AM, Andrius Narbutas <

bb
Andrius,

One more comment about rudder navigation and aileron stabilization: the aileron stabilization is going to fight the rudder navigation. When the rudder starts turning the plane in one direction, aileron stabilization will turn it back the other way in an attempt to level the plane. Rudder navigation is best suited for planes without ailerons. In your case, if you want to make your plane behave like an EZStar without ailerons, you would have to "lock" the ailerons.

If the orientation of the UDB with respect to your plane matches the orientation option that you set in your options.h file, then the polarity settings will take care of both stabilization and navigation at the same time. I looked at your setup from one of your videos, and looked at your options.h file, it looks like you have the board mounted in the "standard" position, with the GPS connector oriented toward the nose of the plane, so that should be ok. Unless for some reason you have turned the board around some time after you showed us the setup video.

I notice that in your options.h file you are using two aileron output channels. I have never worked with that option, possibly that is the source of the issue. (But I would think it would have the same effect on both stabilization and navigation.)

I am still puzzled about the gyro drift. Your roll-pitch-yaw demo showed that the gyro offsets were very small, so the drift compensation used in MatrixPilot should "lock" on perfectly. I cannot think of any way that would cause you to see so much roll or pitch error.

At this point I am out of ideas. The next step would be for one of the other developers and/or test pilots to make some suggestions.

Also, at this point, I cannot help you much further without looking at some telemetry. I think you said you are waiting for an OpenLog? When you get one, I would be very interested in looking at the data.

Best regards,