The APM dev team is delighted to announce the release of APM:Plane 2.74, a major new release with a lot of new features. This release is recommended for anyone flying fixed wing aircraft with an APM2 or PX4.
There are a lot of changes in this release, but some of the highlights are:
Scroll down for a more complete list of changes, but before that I'd like to give you a bit more detail on the highlights above.
New Attitude Controllers
The new "APM_Control" attitude controllers have been in development for a long time. Originally developed by Jon Challinger last year, they were extended by Paul Riseborough and made compatible with the existing parameter names. The key advantage of these new controllers is their improved handling of noise, and much better ability to tune for your aircraft. There is a new tuning guide in the wiki which gives detailed instructions on how to make the most of the new capabilities.
One of the big effects you will see with the new attitude controllers is better handling of pitch compensation in turns. The new PTCH2SRV_RLL parameter makes tuning for flat turns much easier, which has been a major source of frustration in the past.
The new controllers also handle sensor noise much better, especially if you use any D term in your roll or pitch controllers.
New Speed/Height Controller
The new TECS speed/height controller is the second major controller change in this release, and will make a world of difference for aircraft with an airspeed sensor. After a lot of testing I decided to make TECS the default in this release, although you can switch back to the old controllers using the ALT_CTRL_ALG parameter if need be. If for some reason you find you do need these old controllers then please let me know, as I am planning on removing the old controllers in the next release.
The previous airspeed controller for speed/height suffered from a major problem that it gave absolute priority to airspeed. If the aircraft could not achieve the target airspeed you had set then it would dive to gain speed, even to the point of diving into the ground. This made it quite fragile, and you had to be very sure of your airspeed configuration.
The new controller operates over a range of airspeed values, set using the ARSPD_FBW_MIN and ARSPD_FBW_MAX parameters. That controller will try to meet both the airspeed and altitude demands of the mission, but if it can't reach the target speed it will happily fly a bit slower, as long as it doesn't get below ARSPD_FBW_MIN. You can control the relative priorities of speed versus height using the TECS_SPDWEIGHT parameter. See the full tuning guide for details.
New ACRO flight mode
This modes brings rate controlled stabilization to APM:Plane, and should help give you an "on rails" manual flight experience. It is a lot of fun to fly, but it is not for beginners!
We're planning on expanding the ACRO mode in future releases. Right now it is great for "locked in" flying, and also good for loops and handles inverted flight very nicely. It doesn't yet handle knife-edge or prop-hanging.
New CRUISE flight mode
After a suggestion from Hein, we now have a new CRUISE flight mode. This mode is ideal for longer distance flying without a pre-programmed mission. It is like FBWB, but also does ground track heading hold, with heading update via aileron or rudder.
I've been testing CRUISE at my local flying field, and it is the easiest mode to fly in APM. Just steer the plane around the sky, and when you stop steering it locks onto a ground track and holds it. It isn't a good mode for takeoff and landing, but once you are in the air it is great.
New camera trigger system
When using APM for aerial mapping where you want photos taken at regular distances, the previous system was to setup a grid mission with a "camera trigger" mission item at regular intervals within the mission. That worked, but led to overly large and complex missions. You can now just set a single parameter CAM_TRIGG_DIST to the number of meters of flight between photos, and the APM will take care of when to trigger the camera. This makes for much simpler missions, and also works in other flight modes, including FBWB and CRUISE.
Lots of smaller changes
As is usual with a new release after a couple of months of development there were a lot of smaller improvements based on feedback from users. Many thanks to everyone who gave feedback and contributed patches!
Here is a partial list of the changes:
This new release has a lot of new features that should improve the flying experience for all APM users. The APM dev teams wishes all APM users many enjoyable flights, and we hope you have as much fun flying this release as we had making it.
Would be great because APM1 with the MTK GPS needs some time to get GPS lock. When I do not want to wait and just want to fly a short round in manual or stabilize mode, till GPS lock is done, I do not really know where it has locked and where is the home position
I don't suggest you takeoff without GPS lock. The problem is that (unless you have an airspeed sensor) the APM won't have any way to properly estimate centripetal acceleration, so your attitude estimate could degrade badly. Put more simply, the APM could lose track of which way is up.
When the APM loses GPS in flight for a few minutes it can use the speed estimate it had before it lost GPS lock to try to account for centripetal acceleration. If it has never had GPS lock it can't do this.
Thanks Paul, much appreciated. For me this kind of technical analysis in very valuable and many of us I think don't even know even where to start.
The complexity, sheer volume of new and old parameters and the amount of time needed to tune each one means that I (and many others), have left quite a few of them on their defaults.
I'll try your suggestions when I get a chance to fly again
BTW, my calculated stall speed is 6.2m/s, I haven't yet measured it though. (1.4kg, 46dm² wing area, 12%Clark-Y)
Currently the AHRS_WIND_MAX parameter is only used to limit the IMU based airspeed estimate if you don't have an airspeed sensor. If you do have an airspeed sensor enabled and it fails then you could easily crash as a result.
Paul and I have discussed some strategies for coping with airspeed sensor failure, but we haven't yet settled on a good solution. So for now if you have an airspeed sensor failure then the operator needs to intervene and takeover in a manual throttle mode (eg. FBWA) or disable the airspeed sensor (if you are quick enough!)
Then the tag descriptor of that one is wrong. In advanced parameters it states that setting that parameter will allow the APM to cope with a failing airspeed sensor.
Well, at least it saved a poor bumblebee from being sacrificed for my experiment.
Well, anyway - all your comments on the subject are very valuable since now the current situation is clearified; Air speed data fault MAY currently result in a crash. Knowing this is much preferable compared to believing there is an automatic back-up - which would lead to a false feeling of safety.
Please consider that a pitot tube obstruction should not neccesarily be assumed to indicate underspeed.
A fairly airtight obstruction (from the very start or during later flight phase) would rather enclose the current pressure inside the tube / sensor. During a climbout this leads to an increasing difference between pitot tube pressure and static pressure, which falsly interprets as an air speed increase - tricking system to increase rate of climb / reduce throttle - and there you are.
Some basic info here (including failures): http://en.wikipedia.org/wiki/Pitot-static_system
Paul, I agree that at the present stage of development, the risk assessment/ priorities you mentioned may be just right. Though IMO as soon as we figured out how to detect and handle an air-speed data loss it should be regarded as fairly significant. There is already your well documented non air-speed based algorithms, so the question is what conditions should trigger an alert / reversion. Maybe I might contribute somehow in this process. Maybe better to have that conversation in a dedicated thread?
Airliners have the "luxuary" of tripled/ quadrupled air data systems and computer voting to detect and resolve air data failures. Plus reliable sensor fusion from IMU and GPS - and angle of attack sensors. Even then things can get pretty hairy, especially when there are two faulty systems winning the vote over the working one... Tried that in a full flight simulator, just like the vast part of collegues around the world, in the after math of AF447 disaster.
I have tried to finetune my PIDs.
"I" seams doing nothing for me.
Did i miss something? :)
an adequate solution to the "failing airspeed sensor" problem is enabling the use of a backup sensor, and adding a CUSUM detection loop.
I would not mind buying another airspeed kit for this purpose, and I'm sure others won't mind too.
It adds an extra layer of protection, so the plane does not crash if it gets a complete obstruction of one of the pitot tubes.
Seriously, is a failing airspeed sensor that much of a likelihood? What are the chances of hitting a bumble-bee in flight? Has anyone ever reported a failed airspeed sensor? There are SO many other components that are more likely to fail...like that mass-produced elevator servo, the mass-produced servo extension cables, the BEC, ESC, APM, GPS, etc.
Spending time worrying about or working on elaborate solutions for a one in a thousand chance of failing or blocked airspeed sensor seems a waste, IMHO.
Very well said.
The safety of ourselves and (more importantly) others should be our top priority, and I think we should take every effort in securing that safety before we go out flying.
The future of our hobby depends on it, because accidents (with or without personal injury) attract negative attention what could lead to legal banishment.
In my upcoming X8 project I considered to use the two parallel pitot tubes connected to the one sensor. For FOD obstructions that might help saving the day. Though again, it might provide a false sense of safety, unless one very carefully inspect the two tubes before every flight, since one of the tubes might already be invisibly clogged wwhich might pass totally unnoticed. Until a second tube failure... Maybe you think I exaggerate, and I willingly admit this is statistically unlikely to occur. Still, it would, some unlucky day. Having two independant systems with dual sensors adds the possibility of automatic detection and discrimination, as Paul mentioned. Maybe something for next generation hardware and firmware?
Graham, I get your point. Please notice that the unfortunate Bumble bee mentioned is just a symbolic example of obstruction. I would say the likelyness of a UAV pitot tube hitting an object in flight is unknown, we lack statistics for occurances.
Furthermore, the probability of such an occurance varies greatly with flying conditions. For instance insect (or even bird) population density in the flown airspace and UAV velocity. A slow flyer in a clear winter day is less exposed than a ducted fan plane screaming through a mosquito infested swamp somewhere. But both situations is plausible as APM installations.
Anyone that have operated a full scale flyer or RC helicopter in bug season knows what I mean...
Now the obstruction can also occur on ground, when the craft is stored. There are insects that prefers dark tubular spaces to build a nest inside, or to leave their eggs inside...
In short, there are many reasons why all serious flyers use pitot covers during their ground stay. And there are reasons why thoroughly designed UAVs like the Pteryx choose not to include an airspeed sensor at all. But I think that a mature air speed system brings so many advantages that it easily justifies it´s precense in advanced auto pilot solutions.
I also agree with @iskess. The motivation here is not mainly to save a hobby usage Bixler from disappearing into a swamp. But the prospect of loosing a $10000 UAV during a commercial mission makes this single point failure problem more interesting.
To conclude, if the APM auto pilot is only ment for hobby usage then the air speed failure probability may not be so important. Though if we are aiming for professional or semi professional applications, also to be flown/ completed during some degree of preciptation, we cannot afford to ignore this problem. And obviously Paul and Tridge have already been pondering how to work it out. :)