* Previously, the ELEVON_REVERSE parameter was equivelant in function to the
ELEVON_CH1_REVERSE parameter. These parameter values are found in
g.reverse_elevons and g.reverse_ch1_elevon, and used to map to the radio_out
channels in ArduPlane/Attitude.pde
* It seems the author's intent was for ELEVON_REVERSE to change the sign for
the combination of pitch & roll into ch1 & ch2, as there are already
parameters which change just the sign of ch1 and just the sign of ch2.
* Discovered this bug because I happened to build an elevon airframe which was
not possible to setup with the existing ELEVON_ and RCn_REV parameters.
* This will break existing elevon setups if the user used ELEVON_REVERSE
instead of ELEVON_CH1_REVERSE, since they were previously interchangable.
when we send a GPS_RAW message, set the usec field to the time we got
the fix from the GPS, not the current time. This makes it possible for
aerial photo processing to be more accurate, as the usec field with
more accurately reflect the planes position/time pair
setting ARSPD_ENABLE to 1 and ARSPD_USE to 0 allows the airspeed
sensor to be initialised and logged without it being used for flight
control. This is very useful when initially testing an airspeed sensor
in a new plane. It also makes it possible to enable/disable the use of
the airspeed sensor during a flight at any time.
building with TELEMETRY_UART2=ENABLED allows you to use the solder
bridge on the APM2 to enable telemetry on UART2. This allows both USB
telemetry and a radio at the same time.
the GPS_STATUS message is a massive waste of bandwidth, but it is the
only message that tells us the number of visible satellites. So only
send it if that information changes.
This makes MAVLink work better at low baud rates
the 128 byte serial transmit buffer was causing significant problems
with queueing of mavlink messages. With 256 bytes we can fit a lot
more messages out in each pass of the code, which makes telemetry more
efficient
As we discussed on the dev call, we now have enough free ram for this
to be worthwhile
when MANUAL_LEVEL is set to 1, we don't do accelerometer levelling at
startup, and instead used the values saved in the EEPROM. This makes
it easier to do levelling on the bench, or once for a series of
flights for the day
this disables the compass in DCM if MAG_ENABLE is changed in
flight. Without this we would use a fixed yaw once the compass is
disabled
This also makes sure we don't pass the compass to DCM till we have
done a read. This ensures we have a good compass fix for the initial
DCM heading
when we are in the final stages of a landing (less than 2 seconds from
landing waypoint, or less than 3m above landing altitude) we switch
the navigation to use a fixed course. The code previously used the
crosstrack_bearing for this, but this can lead to a large nav_roll in
this final stage of the approach, which can put a wing into the
runway. In autotest we were seeing a nav_roll value of -45 degrees as
we crossed the transition point for the landing, which often led to a
crash.
This changes the code to use the current yaw_sensor value instead,
which is much less likely to lead to large rolls in the final landing
stages.
hold_course is either -1 (for disabled) or a course to hold for
takeoff/landing. This makes the code a bit clearer.
It also resets hold_course in all non-auto modes, to ensure it isn't
used
If you include airspeed, throttle or groundspeed changes in a mission
then those should not be saved to EEPROM, as otherwise if you restart
and re-fly the mission you will be starting with different parameters
to the ones you used for the first flight.
This is particularly important for setting the target airspeed when
coming in for a landing. You typically set a low target, but if you
fly again the next day I think it would be a real surprise to find
that your loiter airspeed has then changed to the value from the
landing part of your last mission.
This one can be argued either way, but I think that not saving these
changes is the more conservative choice, and better fits the
'principal of least surprise'
Fixes compatibility for APM2. Also a significant update to the battery monitoring code: We previously had monitoring modes for individual cell voltages for 3 and 4 cell lipos. These have been removed as they were never really supported (the cell voltages were computed but were not reported or recorded anywhere). Also, some clean-up/prep work was done for supporting monitoring 2 separate battery packs. The CLI battery and current monitoring tests were consolidated into 1 test.
changed
Since the magnetometer offsets are not available through the MAVLink parameter interface (since they are an AP_Var vector) this little feature allows them to be reset from the CLI. Useful if you somehow get bad offsets or if you change magnetometer. If you have a bad set of large offset values I have seen issues with the nulling algorithm have trouble converging to the proper values. I have never seen it have trouble converging from 0/0/0, so this could be a useful feature from time to time.
Fixes compatibility for APM2. Also a significant update to the battery monitoring code: We previously had monitoring modes for individual cell voltages for 3 and 4 cell lipos. These have been removed as they were never really supported (the cell voltages were computed but were not reported or recorded anywhere). Also, some clean-up/prep work was done for supporting monitoring 2 separate battery packs. The CLI battery and current monitoring tests were consolidated into 1 test.
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.
Andrew Tridgell
rmackay9
Amilcar Lucas
Jason Short
Michael Oborne
Pat Hickey
James Goppert
Adam M Rivera
Phil
Sandro Benigno
analoguedevices
Doug Weibel