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:
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
Tags:
Permalink Reply by Jake Stew on June 8, 2012 at 7:39am Best wishes for your health. I'll keep you in my prayers.
Permalink Reply by Grant Olivier on June 10, 2012 at 2:18am 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

Hi Grant,
First I should say that I'm glad to hear the default config (learn enabled, and autodec on) worked well for you!
I'll see if I can clear up some of your questions.
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 know you are focusing on the compass offset settings, but I should point out that the differences in flight characteristics could be caused by something else. I'm not saying its not bad compass offsets, I'd just like to point out some other possibilities.
First off, I notice from your logs that some other parameters were changed between the flights, such as ARSP2PTCH_I, the waypoints, HDNG2RLL_I, the pitch and roll limits, the trim throttle, the Xtrack gain, and the loiter radius. That is quite a few changes and it is possible they interacted to produce the different flight characteristics.
To understand how, I better explain something about how a compass works. A compass produces a 3D vector pointing at the magnetic north pole (when properly calibrated). That by itself doesn't actually tell you your heading! To get a heading from that you also need to know your roll/pitch, which combines with the mag vector via a bit of trigonometry to produce a heading. So its perfectly possible that the 'magnetic heading' shown in the logs can be inaccurate not due to the compass itself being wrong, but due to APM not having an accurate roll/pitch estimate. The instant roll/pitch estimate of APM during turns is often off by quite a lot (unfortunately, and that is something we are working on!) which can lead to poor magnetic heading.
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.601This 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.
you are correct that when COMPASS_LEARN is zero that APM will not change compass offsets itself. Looking at your logs for that flight I see that the COMPASS_LEARN parameter was changed during the flight:
2012-05-30 15:58:54.78: PARAM_SET {target_system : 2, target_component : 1, param_id : COMPASS_LEARN, param_value : 1.0}
2012-05-30 16:02:03.47: PARAM_SET {target_system : 2, target_component : 1, param_id : COMPASS_LEARN, param_value : 0.0}
during the 3 minutes when it was set to 1, the offsets changed. Perhaps you were loading saved parameter files?
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?
COMPASS_AUTODEC and COMPASS_LEARN operate on completely different things. The COMPASS_AUTODEC is used to set the magnetic declination of the compass, which is the difference between magnetic and grid north for your location (in radians). The COMPASS_LEARN parameter tells APM to learn the calibration of the compass for local magnetic conditions, such as metal in your airframe.
There is no difference in how heading is computed between manual and auto modes.
As to why you got such large heading discrepancies, that is non trivial to answer I'm afraid. You've done the right thing by giving me logs, but right now I don't have time to analyze them properly to tell you exactly what happened (that sort of analysis typically takes a few hours at least, and I just don't have the time for that right now, sorry!)
What I can tell you from a brief look at the logs is that I suspect you had an issue more with your accelerometers and gyros than with your compass. The worst discrepancies come at a time when you seem to have some fairly extreme vibration along the X axis of the APM (ie. movement forwards and backwards along the line of the fuselage). How is the APM mounted? The vibration on the Y axis is much less.
The gyros were also suffering from vibration, especially for rotation about the X axis:
both the above graphs are from 20120530093944.tlog from your 3rd flight. The gyro scale is in milli-radians per second. The accel scale is in milli-gravities, so 1000 is 1g.
I know its terribly easy to just blame vibration, and I'm not sure that the vibration is definitely the cause of the issues in this case, but it is something that you should be able to fix with a bit of careful mounting.
Cheers, Tridge
Hi Andrew, this is my feedback on flight test of this release, 2.40-beta.
All went well regarding STAB, FBWA, RTL and AUTO. Only problem was the DO_JUMP command of the Mission that did not work... I'm not sure why.
Setup:
- Bixler with stock motor and Master Airscrew 3 blades 6x4 propeller, 2.6 mAh 3s, Spektrum DX8 radio
- APM2 (with MediaTek MT3329 10Hz GPS) and ... of course... ArduPlane 2.40-beta
- MinimOSD (firmware 1.9 MAVLink 1.0)
- GoPro and Video Tx
Take care and hope you will get better soon!
Cheers,
-Eric
This is the video of the flight:

Hi Eagle,
Thanks for the test report!
There haven't been any changes in how DO_JUMP is implemented, so I can't explain that, sorry. I'm glad to hear the rest of it went well!
Cheers, Tridge
No problem Andrew. Regarding DO_JUMP... the problem is probably sitting in front of this keyboard at this time. New test are scheduled this weekend.
Take care Sir.
-Eric
Permalink Reply by Simon Howroyd on June 15, 2012 at 3:45am 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.

Hi Simon,
The DMP AHRS is not in this release. It also would make no difference so what UART rate you can use. ArduPlane has plenty of spare CPU at the moment on the AVR2560 and you could quite happily run both telemetry UARTs at 115200 without impacting anything.
Cheers, Tridge
Permalink Reply by Simon Howroyd on June 16, 2012 at 3:43am Hi Tridge,
Thanks, I am new to ArduPilot and am going off what heresay is floating around my workplace. I was under the impression that the UART was running at 57600 and not 115200 for a reason that it was killing the processor.
We are doing offboard control using ardupilot and the faster the data rate the better, upping attitude messages from 10Hz to 20Hz would make a huge difference.
Thanks for your help, I will up the rate and see what happens!
Si
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.4 members
5 members
180 members
24 members
1283 members
© 2013 Created by Chris Anderson.
Powered by
