Developer

ArduPlane 2.40-beta

Hi All,

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!

Cheers, Tridge

 

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Get well soon!

    Is the AHRS on the PIC working yet to free up some CPU time on the arduino?  I'm hoping this will give me some headroom to increase the UART from  57600 to 115200.

  • Hello Andrew. 

    I also trust you will get better soon. 

    When you are better I would appreciate it if you would shed some light on an issue I have had using ArduPlane V 2.34 and APM V 2.4.1. As I understand from some of the blogs you are one of the ArduPilot developers which has been involved in developing the magnetometer auto-calibration functions and thus assumed that you would be the best person to discuss this issue with (feel free to refer me to other developers should I be incorrect).

    My potential problem is related to the aircraft heading determination using the built in magnetometer. Let me lay the scenario... 

    Flight summary:

    FL# 1.

    Aircraft parameter file: COMPASS_AUTODEC,1 ; COMPASS_DEC,0.025 ; COMPASS_LEARN,0

    COMPASS_OFS_X,-70.415
    COMPASS_OFS_Y,42.016
    COMPASS_OFS_Z,53.466
    Result:

    Good Manual, Stabilize and FBW-A mode however reported heading was inconsistent with track provided by GPS with between 45 and 180 degree differences. As a result auto mode did not produce good results with the aircraft failing to attain the correct track and hold the track defined by the waypoints in the flight plan.

    I have attached the telemetry file (2012-05-26 09-37-25.tlog)  for this flight. 

    FL# 2.

    Aircraft parameter file: COMPASS_AUTODEC,0 ; COMPASS_DEC,0.025 ; COMPASS_LEARN,1

    COMPASS_OFS_X,-121.259
    COMPASS_OFS_Y,35.9
    COMPASS_OFS_Z,180.167


    Result:

    Good Manual, Stabilize and FBW-A mode with consistent GPS track and reported heading. As a result auto mode produced good results with the aircraft attaining and holding the correct track.

    I have attached the telemetry file (2012-05-26 10-39-13.tlog)  for this flight. 

     

    Note. I then used the results of this flight and using APM Planner performed a magnetometer log calibration to obtain settings for FL#3 detailed below:

    FL# 3.

    Aircraft parameter file: COMPASS_AUTODEC,0 ; COMPASS_DEC,0.025 ; COMPASS_LEARN,0

    COMPASS_OFS_X,-71.541

    COMPASS_OFS_Y,105.917
    COMPASS_OFS_Z,167.521

    Result:

    Good Manual mode however reported heading was inconsistent with track provided by GPS with between 45 and 180 degree differences. As a result auto mode did not produce good results with the aircraft failing to attain the correct track and hold the track defined by the waypoints in the flight plan. There were several occasions where the reported heading jumped 180 degrees especially at the transition from manual to auto which necessitated a switch to manual to avoid the aircraft from flying beyond visual line of sight, 

    I have attached the telemetry file (2012-05-30 09-39-44.tlog)  for this flight.

    Issues

    From the telemetry one can clearly see that the reported heading is inconsistent with the direction the aircraft is flying in as observed from the ground track. There are a number of occasions where the reported heading (or bearing) jumps 180 degrees which really confuses auto mode as the lateral control attempts to steer the aircraft in the bearing to the waypoint resulting in the aircraft flying away rather than towards the waypoint.

    I expected the log calibration to produce good results with the offsets computed by APM Planner obtained using the telemetry log from FL#2 and therefore I set COMPASS_LEAR to 0. It did not behave as expected.  

    Observation of the parameters refreshed from APM after the flight revealed that the offsets had changed slightly to:

    COMPASS_OFS_X,-69.287
    COMPASS_OFS_Y,107.03
    COMPASS_OFS_Z,167.601

    This indicates that the software did adjust the settings whilst in flight although the settings (as I understand them (COMPASS_LEARN,0)) should not have allowed this.

    Would you please provide a brief explanation of what the difference is between COMPASS_AUTODEC and COMPASS_LEARN and whether the software computes the reported heading differently when in manual as compared with auto mode and why I may have experienced the anomalies in reported heading?

    Thanks

    Grant

     

    2012-05-26 09-37-25.tlog

    2012-05-26 10-39-13.tlog

    2012-05-30 09-39-44.tlog

  • Best wishes for your health.  I'll keep you in my prayers.

This reply was deleted.

Activity