- Apr 25, 2012
-
-
Adam M Rivera authored
-
- Apr 23, 2012
-
-
Andrew Tridgell authored
this buffers up _omega_I changes in _omega_I_sum over a period of 10 seconds, applying the slope limit only when _omega_I_sum is transferred to _omega_I. The result is a huge improvement in the ability of _omega_I to track gyro drift over the long term.
-
Andrew Tridgell authored
the 'drop z' method reduced the impact of noise on omegaI, but it also made us more sensitive to errors in accelerometer calibration and scaling, as demonstated by the logs from Gabor here: http://diydrones.com/xn/detail/705844:Comment:834373 Simulation testing shows that the other noise suppression methods applied in the DCM code, in particular the slope limiting on omegaI the removal of the weighting and the upcoming use of a _omega_I_sum buffer have reduced the impact of noise enough that we can now safely include z in the acceleration calculation.
-
- Apr 16, 2012
-
-
Andrew Tridgell authored
this allows users to change the yaw gain in DCM
-
- Mar 29, 2012
-
-
Andrew Tridgell authored
when a user first connects with USB, and later switches to the telemetry port without restarting we were getting zero for error_yaw in the logs, as AHRS.get_error_yaw() was being called twice. This ensures we give the last value after the counter is reset
-
- Mar 19, 2012
-
-
Andrew Tridgell authored
this allows us to use a tested and optimised rotation method
-
Andrew Tridgell authored
-
Andrew Tridgell authored
this is the first step to creating a general AHRS class for ArduPilot
-
- Mar 11, 2012
-
-
Andrew Tridgell authored
-
- Mar 09, 2012
-
-
Andrew Tridgell authored
this cleans up the separation of drift rates and proportional correction from yaw source and accelerometers, allow the yaw to run at a different rate to the accel correction
-
Andrew Tridgell authored
we get linear accelerations of more than 1g when turning corners
-
Andrew Tridgell authored
-
Andrew Tridgell authored
this combines the functionality of the 'fast' DCM with the normal one, and also speeds up both the yaw drift correction and the matrix update code
-
Andrew Tridgell authored
-
Andrew Tridgell authored
sorry Randy!
-
Andrew Tridgell authored
this should improve drift correction for ArduCopter
-
Andrew Tridgell authored
-
Andrew Tridgell authored
the z accel is the noisest, and seems to do more harm than good. Using just x and y is sufficient for drift correction by assuming the vector length
-
Andrew Tridgell authored
possibly not needed, but convenient to be able to test with different values
-
Andrew Tridgell authored
-
Andrew Tridgell authored
this can be a local error variable in common with the yaw code. This saves 12 bytes in the object.
-
- Feb 26, 2012
-
-
Andrew Tridgell authored
we were only disabling null offsets when we didn't have a compass, which doesn't make much sense!
-
- Feb 25, 2012
-
-
Andrew Tridgell authored
we need to ensure the compass null offsets code doesn't see a sudden yaw change, or it will change the offsets by a large amount very suddenly
-
Andrew Tridgell authored
-
Andrew Tridgell authored
wait till we reach 1m/s before we reset _have_initial_yaw. This prevents us continually resetting the DCM matrix if our ground speed is close to 3m/s.
-
Andrew Tridgell authored
in_motion is not a good name now it is also used for the compass The error_course and heading component values don't need to be part of the DCM object, they can be on the stack to reduce the memory usage a bit
-
Andrew Tridgell authored
When we first get a compass reading or we first start motion we need to setup the DCM matrix with the right yaw. This uses rotation_matrix_from_euler() to get a DCM matrix corresponding to our current roll/pitch, but with the correct yaw
-
- Feb 24, 2012
-
-
Andrew Tridgell authored
this makes the code a bit easier to read
-
Andrew Tridgell authored
this makes the code a bit easier to understand
-
Andrew Tridgell authored
use is_nan() on the matrix rather than just on c.x, and add safe_asin() to the (unused) OUTPUTMODE==2 code.
-
Andrew Tridgell authored
when we get a bad DCM error we can recover a matrix corresponding to the current attitude, making it more likely that the aircraft will be able to recover
-
- Feb 23, 2012
-
-
Andrew Tridgell authored
This allows us to detect NaN, otherwise NaN values were considered 'in range'
-
- Feb 22, 2012
-
-
Andrew Tridgell authored
The asin() in the pitch calculation can only take values between -1 and 1. This change ensures that the value is in range, and if it isn't then we force a normalization. If that fails we reset the matrix
-
Andrew Tridgell authored
when DCM blows up, we need to reset a lot more variables to ensure that any NaN values don't persist
-
Andrew Tridgell authored
The sqrt() costs about 44usec on a 2560, which is small enough for us not to worry about the speed. This also changes the range of values where we declare a blowup to much less likely, which means we can cope with larger delta_t glitches
-
- Feb 18, 2012
-
-
Andrew Tridgell authored
if we don't have a GPS or the GPS doesn't have a good lock then we can't rely on the ground speed for adjusting the acceleration vector
-
- Feb 14, 2012
-
-
Andrew Tridgell authored
I have seen normalisation errors during simulation runs, but have not yet tracked down the cause. This log message may help track things down.
-
- Jan 13, 2012
-
-
Andrew Tridgell authored
when compass is disabled _compass is NULL
-
- Jan 12, 2012
-
-
Doug Weibel authored
This is a fix for an interesting bug when a DCM matrix reset was added to the ground start. This bug only showed up if (A) a ground start were performed after an air start or due to use of the "Calibrate Gryo" action, (B) if the current orientation were sufficiently different from 0/0/0, and (C.) if the particular magnetometer had sufficiently large offsets. Why did resetting the DCM matrix to 0/0/0 pitch/roll/yaw at ground start cause a bug? The magnetometer offset nulling determines the proper offsets for the magnetometer by comparing the observed change in the magnetic field vector with the expected change due to rotation as calculated from the rotation in the DCM matrix. This comparison is made at 10Hz, and then filtered with a weight based on the amount of rotation to estimate the offsets. Normally it would take considerable time at normal in-flight rotation rates for the offset estimate to converge. If a DCM matrix reset occurs when the offset nulling algorithm is up and running, the algorithm sees the DCM reset as a instantaneous rotation, however the magnetic field vector did not change at all. Under certain conditions the algorithm would interpret this as indicating that the offset(s) should be very large. Since the "rotation" could also have been large the filter weighting would be large and it was possible for a large erroneous estimate of the offset(s) to be made based on this single (bad) data point. To fix this bug methods were added to the compass object to start and stop the offset nulling algorithm. Further, when the algorithm is started, it is set up to get fresh samples. The DCM matrix reset method now calls these new methods to stop the offset nulling before resetting the matrix, and resume after the matrix has been reset.
-
- Dec 28, 2011
-
-
Andrew Tridgell authored
-