Servers by jDrones

APM:Plane 2.78 released

(tridge) #1

I’ve just released APM:Plane 2.78. This is a bug fix release for a number of important issues found in the 2.77 release.
The changes in this release are
[color=#0000FF]Fixed sensor start-up on the APM1[/color]
I’m embarrassed to say that I didn’t test the APM1 for the 2.77 release as my APM1 had died. It was a trivial fix, and the APM1 is working again in 2.78
[color=#0000FF]Pixhawk Barometer fix[/color]
Fixed a potentially serious bug on Pixhawk if the board is flown in high temperature environments. If the board temperature gets above 65 degrees C then some boards would get bad barometric readings, thus giving bad altitude readings. This fix was a change in the GPIO settings on the SPI bus used to talk to the MS5611 barometer. Many thanks to Darrell Burkey for supplying the log file that found this bug.
[color=#0000FF]Fixed LED behavior on Pixhawk[/color]
The large 3 color LED should now correctly display the failsafe and GPS status
[color=#0000FF]Improved PX4 and Pixhawk compass calibration[/color]
We now run a strap calibration on every boot which improves compass accuracy by a small amount
[color=#0000FF]Added RSSI_RANGE parameter[/color]
This allows you to scale your RSSI input to match your receiver
[color=#0000FF]Fixed GPS health status in MAVLink[/color]
The GPS health bit will now show as unhealthy if the GPS does not have 3D lock. Thanks to Iskess for reporting this issue!
Thanks to everyone who gave feedback on 2.77, much appreciated!
Happy flying!

(tridge) #2

I’ve just released a bug fix for 2.78, which is called 2.78b. This fixes a bug in the new RSSI_RANGE option spotted by forum member Valince.
The bug was that RSSI_RANGE used the same parameter key in EEPROM as the RC1 parameter set. That is an important bug, as setting RSSI_RANGE would cause the RC1_MIN parameter to be reset to its default value of 1100 on the next boot. Additionally, setting RC1_MIN would cause RSSI_RANGE to reset to its default value of 5.0.
Many thanks to Valince for spotting this bug!
I’ve now pushed a change to our parameter handling code to automatically check for this type of error on every boot, so it can’t happen again in the future.
Cheers, Tridge