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
<serialisationFlag>LOAD_AT_STARTUP</serialisationFlag>
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
Category:Gentlenav
Category:Gyro drift