I've just released ArduPlane 2.73 as a bug fix release for several important bugs in 2.72
The main reasons for this release are:
This release does not contain the new attitude controllers that I previously said would be in 2.73. Paul and I decided that it would be better to hold those over to the next release, and get this release out with just the above critical bug fixes.
The airspeed problem stemmed from a changed introduced in 2.72 to make ArduPlane automatically scale analog inputs with board voltage. That change was good for voltage and current sensing, but it added a lot of noise to airspeed sensing as the 3DR airspeed sensor is ratiometric (the sensor output scales with the supply voltage). The fix was to add support for ratiometric analog inputs. This release also fixes a bug in the airspeed ratio handling. To confirm the fix I have been driving around in my car with an APM2 and PX4 logging airspeed and GPS speed - that test confirmed the airspeed sensing is now accurate.
The flyaway bug in L1 was caused by an unusual situation where the previous waypoint was equal to the next waypoint, which can happen when a mission is interrupted and restarted. The L1 controller would then level the wings and fly straight ahead until the operator intervened. The bug fix was to make the L1 controller detect this situation and track directly to the next waypoint. I don't think many users would have seen this bug, but it definitely could happen and warranted a bug fix release.
The GPS handling bug was related to the MTK GPS, which can be very slow to report loss of GPS lock, which could lead to very poor attitude from DCM and even a crash if the plane tries to turn while the GPS is reporting incorrect velocity information. The fix was to watch the satellite count, and stop using the GPS velocity for accelerometer correction when it had less than 6 satellites. This is selectable with the new AHRS_GPS_MINSATS option.
While this release doesn't have the new attitude controllers I decided to leave in some other smaller changes that have been made since the 2.72 release that I consider to be low risk, including:
Of these, perhaps the most useful is the ELEVON_OUTPUT option. That makes it possible to setup your transmitter with normal aileron/elevator and get the APM to do a software elevon mixer on output. That gives better control in FBWA mode than the previous elevon options.
I recommend that all users of 2.72 upgrade to 2.73. Happy flying!
Hey Andrew.. When you guys do new software do you guys do any QA behind the scenes? I have someone asking me. They're concerned the software is being thrown out to the modelers to test on their own. Feel free to pvt me if you wish.
why did you remove manual level.
I was wondering the same...
I think it was removed as an OPTION.
It is now always manual_level.
This is the only option ever used for level on a plane.
At least I presume that is what was meant. I have never tried to not use manual_level.
When i open "Arduplane Level" the "Manual Level is disabled even when i enabled it last time.
How can i know that it's always manual or always auto ??
I am about to maiden my X-8 with APM2.5 but wonder what good starting points are for PID settings?
Any chance you can advise?
The answer of "why I remove the manual level" is very simply, I have never paid atention to this option.
It was my fault...
Yesterday I understood this part of the set up looking for a solution to my problem as I have informed before.
With your questions I now realize that I should enable the manual level also....
As Tommy said when you open the MP the manual level option is disabled as default...
I will enable, now
Thank you for all the support.
As Monroe said, there is a lot of testing done, but as with any complex piece of software there are things that are missed.
Basic testing takes the following forms:
I have a bunch of different planes I test with, but time limitations mean I usually test new releases on only 2 planes. Right now I'm using a Phoenix Tiger60 and a Bixler2. I also often fly with friends who use APM on a SkyWalker 1900, a Ugly Stick, a Boomerang and a Queen Bee.
One of the problems we have with testing is that the software has builtin redundancy. That is good for users, but makes testing harder, as when something isn't working then the plane normally still flies well. It often takes some careful log analysis to see a problem, as it may only be an issue for users in some specific situations.
I certainly can't claim that every feature is tested before every release, and the history of bugs we've had in ArduPlane makes it obvious that bugs do slip through. I'm constantly trying to improve the processes to reduce the number of bugs, but as with all software there will be bugs.
Still, I usually fly the latest development code 3 days a week, usually several flights each day. That amounts to quite a few hours of testing, which when combined with a huge amount of simulator testing does catch most things.
One thing I'd like to establish if possible for ArduPlane is a group of volunteers who are willing to do regular testing of the latest development code, so more people test before release. Let me know if you are interested!
PS: If you want to know if I'm doing flight testing, look for the green sedan in the carpark here: http://weather.cmac.org.au/videos.html :-)
I have to second Andrew's remarks about testing devices that have built-in redundancy. It is time consuming. If you don't specifically fail all the n-1 redundant pathways and test n times then the device passes despite containing a fault. Sounds obvious I know, but it is not always so easy to achieve in practice, especially when there are multiple redundant pathways.
We had the same problem when testing redundant systems in several satellite payloads. We actually had 255 possible combinations and a limited number of test hours available before launch. Reviewing the calculated and historical reliability of each module allowed us to reduce the number of combinations down to 8 that would have the highest probability of failure on orbit.
Sound like an absolute nightmare!
Also sounds like the only sensible approach to such a difficult problem with the added time constraints that you had!