Gyro drift

Location of IMU
https://groups.google.com/forum/#!topic/uavdevboard/MqzXKiuaGAQ nov 2013 Regarding location of any IMU in general, including UDB in particular, there are two sensors to think about, the gyros and the accelerometers.

As far as the gyros are concerned, there are no restrictions at all on location, since the rotation rate is the same at any location on the plane.

It is only the accelerometers that you need to think about, because of unaccounted for centrifugal effects. The acceleration of the IMU is equal to the acceleration of the center of gravity, plus the centrifugal acceleration of the IMU with respect to the center of gravity, due to rotation of the plane.

The only location where the accelerometers do not experience an unaccounted for centrifugal effect is the center of gravity. So, ideally, that is where you would mount the IMU.

However, the unaccounted centrifugal acceleration is usually small, so you can get away with mounting an IMU anywhere on the plane, as long as it is not too far from center of gravity.

Most of the error arises from yaw rate. The unaccounted for acceleration in meters/sec/sec is W*W*R, where W is the yaw rate in radians per second, and R is distance from center of gravity in meters.

Mounting the IMU in front of or behind center of gravity will generate pitch error. Mounting the IMU off the side will generate roll error. But as long as you keep the offset less than about 12 inches, you should be fine.

For example, lets suppose you put your plane into a continuous tight turn at 60 degrees/sec (6 seconds for a full turn). That is about 1 radian per second. Suppose you mount the IMU 12 inches off center radially. That will generate an acceleration on the IMU of about 0.333 meters/sec/sec, or about 0.0333 g, which will generate an equivalent tilt error of about 2 degree. Nothing to worry about.

Notice that I keep using the phrase "unaccounted for centrifugal effect". That is because there is already a centrifugal compensation computation to account for centrifugal effects, that assumes the IMU is mounted at the center of gravity.

Actually, it is theoretically possible to account for the acceleration effect of mounting the IMU very far away from the center of gravity, all you need to know is the 3D location of the IMU with respect to center of gravity. But as far as I know, none of the popular autopilots let you do that.

Gyro calibration
gyro calibration

https://groups.google.com/forum/#!topic/uavdevboard/BUKwxV12cv4

What I like to get is to calibrate acc/gyros @home and store this parameters in EPROM, it could be done because most copters are calibrated that way. My impression was that it is somewhere ready in MP code.

Now I understand you. This is going to need a bit of explaining. There is documentation for it but it was never intended for users at this level, only more basic users and developers.

If you look in the parameter database here you will find the serialization flags https://code.google.com/p/gentlenav/source/browse/trunk/Tools/pyparam/ParameterDatabase.xml#26

The important flag for you is LOAD_AT_STARTUP

Now if you go here you will find the block describing the IMU data https://code.google.com/p/gentlenav/source/browse/trunk/Tools/pyparam/ParameterDatabase.xml#500

add the line to this file LOAD_AT_STARTUP

and save the file

Now in this directory you will need to run pyparam.py. This will automagically generate the code tables in matrixpilot. https://code.google.com/p/gentlenav/source/browse/#svn%2Ftrunk%2FTools%2Fpyparam

after this you will need to re-compile. Don't forget to switch on the eeprom option here: https://code.google.com/p/gentlenav/source/browse/trunk/libUDB/nv_memory_options.h

Now you need to run mavproxy with a script looking a little like this: mavproxy.py --master=COM3 --baudrate=57600 --target-system=55 --aircraft=XXXLsim --target-component=1 --source-system=253 --out=localhost:25999 --out=localhost:14550 --streamrate=1

You will find mavproxy here: https://code.google.com/p/gentlenav/source/browse/#svn%2Ftrunk%2FTools%2FMAVLink%2FMAVProxy Mavproxy will open a terminal window. It will show when it has connected to the autopilot over telemetry.

Now for the horrible bit but only because it is in re-development and not committed to trunk yet. mavproxy runs modules. There is a special module for writing eeprom data to UDB. You start this by typing "module load pgui" into the mavproxy terminal.

You will need python 2.7 to run this but you will need python for lots of the tools we created. You will also need pyserial and wxpython. the wiki here has some details on that: https://code.google.com/p/pyfedit/wiki/Installation

There is a slightly different way using qgroundcontrol. You can connect with QGC and ask it to do a store calibration. Then all memory areas marked with the STORE_CALIB flag will be saved.

To be honest, most of us would rather do a calibration on startup. It removes the temperature offsets and sensor drift. I go to the trouble of saving IMU data just in the case of inflight reboot

/Matt - show quoted text -

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.

Oversample to eliminate white noise
https://groups.google.com/group/uavdevboard-dev/browse_thread/thread/32e2298370fade75#

oversample gyro signals to remove white no