I've just released ArduPlane 2.40-beta. The jump in version number reflects the size of some of the changes.
Unfortunately (due to ill health) I have not actually flight tested this release. I normally try to flight test every release, but I probably won't be able to go flying for a couple of weeks, but I think the changes are very worthwhile to make available to users. So I'd really appreciate some feedback on flight tests of this release. That is also why I have labelled this a 'beta' release. I will wait till I've had some good flight test reports before doing the final of 2.40. I have of course tested the code in the simulator, but real flight tests are essential as well.
The changes in this release are:
- switch to MAVLink 1.0 for telemetry. This has been pending for quite some time, and it is nice to finally get it done. The reason it took so long is we needed some coordination between the various bits of code that deal with MAVLink in APM (the ground stations, autotest, ArduPlane itself etc). The various pieces finally came together and we can now support MAVLink 1.0 properly. This doesn't change the features of APM significantly, but it does prepare us for telemetry improvements in the future.
- UBlox GPS driver fixes. The UBlox GPS driver got a number of bug fixes related to losing protocol lock in the serial protocol between the APM and the GPS. This was particularly important for a UBlox that was configured to send any messages that the APM parser didn't understand. Those extra messages could cause the parser to lose protocol sync and thus lose GPS lock. If you use a UBlox GPS I highly recommend upgrading to this release.
- sped up eeprom erase using chip erase
- Added ARSPD_USE parameter. This is useful when first setting up an airspeed sensor. The existing ARSPD_ENABLE parameter only allowed you to enable/disable airspeed and if enabled then it would be used for flight control. With ARSPD_USE you can now enable the airspeed sensor but not ask APM to use it for flight control (by setting ARSPD_ENABLE to 1 and ARSPD_USE to 0). That allows you to log your airspeed data without using it for flight control, which means you can validate the airspeed sensor is working correctly without risking your airframe if it is badly calibrated.
- fixed an ELEVON_REVERSE bug. The ELEVON_REVERSE parameter was being applied to only one channel, whereas it should be applied to both channels. If you use elevons then please be careful to carefully test your setup before your next flight!
Also, my apologies for being somewhat slow to respond to some threads on the forum. Until my health improves I'm likely to be slow in answering questions. I'm relying on others in the community to help out!