I've just released ArduPlane 2.67
This release fixes a number of important bugs, as well as adding a few new features.
This release changes how the level parameters are stored in EEPROM, so it is very important that you re-level your plane after upgrading if you have MANUAL_LEVEL set to 1.
The key changes in this release are:
- fixed a bug in the uBlox GPS driver that could cause it to setup the GPS with the wrong dynamic model, using the "portable" model instead of the "Airborne-4G" model. In some cases it could also leave the GPS in its default dynamic model. This results in poor navigation, and sometimes in poor attitude control due to inaccurate acceleration correction.
- fixed a bug in the APM parameter code that resulted in the deadzone parameters of auxiliary channels not being able to be set. For example, setting RC5_DZ would actually set RC5_MIN.
- add support for using vertical velocity from a uBlox GPS as part of the DCM acceleration correction.
- added new accelerometer calibration code from Randy. This adds an optional calibration step that can be performed using the "accel" command in the setup menu in the CLI. See description below.
- allow the CLI to run over the telemetry radio link. This is particularly useful for the new accel calibration code.
- added a new secondary aileron type. I'm hoping this will resolve the ongoing issues some users have had with the secondary aileron support
- changed WIND.speed direction to match the convention that the speed is based on where the wind is coming from
- fixed handling of parameter names of 15 or 16 characters (they could appear garbled in the ground station)
- added RSSI_PIN option to set the pin that measures the receiver RSSI
- added support for showing compass health in SYS_STATUS MAVLink message
- fixed throttle disable in VFR_HUD MAVLink message to always be between 0 and 100
added new parameter APM_OFFSET (thanks to Alexey Kozin)
The new accelerometer calibration code that Randy did is particularly interesting, as it gives us a way to get the accel calibration much more accurate along all 3 axes, which should improve the attitude solution somewhat. It is not properly documented yet, but if you are feeling adventurous then try running the CLI and running the "accel" command in the setup menu. This replaces the normal levelling process.
Happy flying!
Cheers, Tridge
Replies
We have been experiencing a telemetry connection issue recently as per this conversation http://diydrones.com/forum/topics/connection-error-in-apm-mission-p...
This only seems to happen with arduplane and not arducopter, is this anything to do with the update?
Hello I have revised the code ARDUPLANE 2.6.7 and found strange that the option airspeed.use () = false is identical g.alt_control_algorithm =ALT_CONTROL_NON_AIRSPEED
to be able to use trottle control from the airspeed sensor, but classical altitude control should be returned
static void calc_throttle()
{
if (!alt_control_airspeed()) {
to old
static void calc_throttle()
{
if (!airspeed.use()) {
+ the same change in radio.pde
in this case
parameter g.alt_control_algorithm =ALT_CONTROL_NON_AIRSPEED
will disable airspeed only here:
static void calc_nav_pitch()
{
// Calculate the Pitch of the plane
// --------------------------------
if (alt_control_airspeed()) {
will only be used to control the throttle channel
Hi
I have just uploaded 2.67 to my APM 1
I was really looking forward to being able to use terminal/cli over the 3DR radio link.
I cannot get it to work yet however, are there any setting I need to change?
Good news Andrew, soon I will test it.
Thanks!
Guto
Great job Andrew. It's possible to fly away in autonomous mode, change the route manually with the radio and the plane flies in this new direction whitout wind influences (deviations)? like a fly to here but with te radio control considering that you are far for the radiomodem signal
Andrew
First Great work.
Glad to see 2.67, plan on trying the MP upload to see how it works on Sunday. Been using a complied version for a few days, testing on AMP1 for a new plane.
At this rate I'm not going to have a reason to keep Arduino compiler on my computer.
That said, You heard a but, How hard would it be to have a Mavlink message just for OSD.
Maybe like this
<message name="OSD" id="XXX">
<description>Missing values for OSD</description>
<field type="uint16_t" name="mampsused">Instead of % send mAmps used</field>
<field type="uint16_t" name="Batt2voltage">Second Battery Voltage</field>
<field type="uint16_t" name="Batt2 current">Second Battery Current</field>
<field type="uint16_t" name="Batt2mAmpused">Batt2mAmpused"</field>
</message>
I'm sure there are other values, but the few I would like to see.
I have tried to modify a few of the Mavlink message without much luck to add some of the above.
Maybe a point in the right direction. ( I believe I failed on the CRC check of the message)
Last in the release notes you talked about on manual level, reseting the values. Does the update need a full erase of the eeprom and start over?
Tridge,
A couple more comments on accelerometer offsets:
Actually, the accelerometer temperature can change quite a bit during flight.
1. The APM itself generates heat, so overall the board's temperature will rise above local ambient.
2. The voltage regulators get hot, so if the accelerometer is mounted near one, it will see an additional temperature rise.
3. If the APM is mounted inside a foamy, the foamy will act like a nice little oven. Other sources of heat such as ESC and batteries can make things toasty warm.
Overall, it is easy to get a 20 degree C temperature shift in flight, which would cause a significant shift in accelerometer offsets.
So, I think if you want precise inflight performance of the accelerometer, you have two choices: inflight temperature compensation, or inflight offset removal.
Inflight temperature compensation would require manual measurement of offsets versus temperature, because the curve is not the same for all units. That is why vectornav charges a premium for manually calibrated IMUs.
Another approach is inflight removal of accelerometer offsets. I have worked out the math for a method to do that, but have not yet had a chance to test it.
Best regards,
Bill Premerlani
Can't get HIL simulation to work with v2.67, works fine for v2.66
Hi Tridge,
I have been following Randy's new accelerometer calibration method. Nice work. I have a question, though. Are you taking into account the shift of accelerometer offsets with temperature? The MPU6000 and 6050 have 3.5% shift in X and Y accelerometer offset over the temperature range 0 to 70 degrees C, and 6% shift in Z. If the flight temperature is approximately the same as the calibration temperature, no problem. But if you calibrate indoors and then fly outside in the cold, there could be a significant offset shift unless you account for the temperature change. So, I would suppose the best thing to do would be to wait until the IMU reaches ambient temperature, and then perform the accelerometer calibration just prior to flight.
Best regards,
Bill
Best regards,
Bill
Thanks Tridge, 2.67 has fixed the differential aileron.
I re-calibrated the radio with diff set (on Ch1 & 5). Is that right or should I calibrate before diff is set to show it full PWM on those channels?
Will the APM also use this diff for automatic modes?