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:

  • new APM_Control attitude controllers.
  • new TECS speed/height controller from Paul Riseborough.
  • two new flight modes, ACRO and CRUISE
  • new camera trigger by distance system, for better aerial mapping
  • dozens of small fixes and improvements from two months of development
  • lots more documentation, including tuning guides for all the new parameters

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

After a suggestion from Thomas in the 2.73 release thread, we have added a 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:

  • added new GND_ALT_OFFSET parameter for ground station barometric correction
  • made it possible to set the failsafe battery voltage and battery level at runtime via parameters
  • added MIXING_GAIN parameter for controlling the elevon and v-tail mixers
  • fixed stick mixing range in AUTO modes  (thanks Soren!)
  • fixed mode logging in dataflash
  • added support for the EagleTree I2C airspeed sensor on PX4
  • added new RCMAP_* parameters for re-mapping control channels (good for DSM and SBUS receivers on PX4)
  • made it possible to configure board orientation at runtime, to make setup easier without rebooting
  • switched to new task scheduler for more accurate internal timing
  • added a new RELAY_PIN parameter for setting up camera trigger via a digital pin
  • added secondary rudder support, useful for when a separate servo is used for a nosewheel and the rudder, or for v-tail planes with nosewheels
  • fixed RTL glide slope when starting above the target RTL altitude. Descent should now be smooth over long distances. Many thanks to Kitsen13 for raising this.
  • fixed a bug with FBWB airspeed control. Many thanks to Gabor for reporting this
  • Added FS_LONG_TIMEOUT and FS_SHORT_TIMEOUT parameters. Many thanks for the suggestion by Aleck
  • fixed handling of deadzone parameters on RC channels. Many thanks to Soren for reporting this
  • many small C++ fixes from NeuroCopter. This sort of detailed review of our code is much appreciated!
  • fixed analog in handling with some unusual devices - thanks to Andi for noticing this!
  • added support for apparent versus true airspeed calculations based on pressure altitude, for better flight control at higher altitudes
  • avoid writing unchanged bytes to EEPROM, for faster updates and less wear on the chip
  • cope better with large yaw changes in the AHRS code
  • improved the reliability of USB connections on PX4
  • added PX4 support for RELAY (thanks to Marco Bauer)
  • fixed handling of high spin rates in AHRS (thanks Jurgen!)
  • removed support for the old APM1 1280 based boards.

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.

Happy flying!

Views: 59799

Reply to This

Replies to This Discussion

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.

Cheers, Tridge

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)

Hi Pieter,

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!)

Cheers, Tridge

All right,
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.

Tomas

 

Hi,

I have tried to finetune my PIDs. 

"I" seams doing nothing for me.

Did i miss something? :)

Thx,

Gábor

an adequate solution to the "failing airspeed sensor" problem is enabling the use of a backup sensor, and adding a CUSUM detection loop.

http://en.wikipedia.org/wiki/CUSUM

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.

Does the air pressure change with the volume of air, or just the ram air pressure? I don't think so since there is no air moving through the system, just static pressure. In that case, less redundant but also less expensive and simpler would be 2 pitot tubes sharing the same airspeed sensor. It wouldn't require any coding at all, and is virtually free if you use brass tubings. This would also help keep your missions going after a rough landing that bangs up one tube.

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.

You have a good point, but the future of UAVs depend on reliability, safety, and redundancy just like manned aircraft.
I agree the redundant servos to different control surfaces, powered by different sources is more important. This would take care of failing servos, control surfaces, and a lot of wiring. There is already code to deal with a failing GPS, but this is also a critical area. It shouldn't lead to an immediate catastrophic event like a failed airspeed could. What else did you mention... BEC - never use them. UBEC - must have at least two, they are cheap. APM - not much we can do about this other than planning redundant power sources which I do with a $30 BatShare. Someday there will be code for running 2 separate APMs in parallel. Yes that's ridiculous for a $1000 Bixler, but some of these UAVs can get very expensive and more importantly heavy and potentially dangerous if flown over persons or property. I applaud any development to increase redundancy and safety. It will pay dividends in a few years when the FAA hands down its certification requirements.
Everyone must choose the level of risk they are comfortable working with depending on the plane, the mission, and the operator.

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. :)

Tomas

 

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service