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!
Replies
Hi Paul and Tridge,
I would sincerely appreciate you thoughts on the attached tlog. I ran a short mission this morning, that I RTL'd at WP2 due to Telem rssi getting low. All went well with regard to basic navigation and altitude control. However, you will note the plane is in a chronic shallow right bank and the plane heading (red line, compass, I believe) is pointing the wrong direction for the wind.
I still have a few magnets on the plane so that may be causing a compass error, although, I did use the 60sec compass calibration procedure. Compass declination set manually and no auto calibrate.(some suggest to turn this off, so I did. Your thoughts?) Also, with the "Level" function non-op, the plane may not be leveled correctly. Your thoughts would be appreciated.
Plane EZ Star I, APM 2.5.2 FW ver 2.74b, MP 1.2.62, 3DR telem, VTx 1.2GHz, ublox GPS, modified rudder to give larger control surface for more authority. No airspeed sensor.
I also seem to be gaining altitude while in FBWA. I will try to lower the pitch compensation for this one.
Thanks,
Steven
2013-07-30 06-44-21.tlog
Really like the new firmware. Thanks for the hard work as always.
Couple of things. Since upgrading to 2.74 and 2.74b when I enter the terminal to test my airspeed, i get zero values. Checked with 2 different airspeed sensors. When I go back to 2.73, no problem. Interesting though, if I go and do a preflight check, the airspeed is correct in all three versions, just not in the terminal on 2.74 or 2.74b. I also changed ports reading the sensor from A0 to A5, reflashed the firmware, etc... Maybed to do with how I am powering the board which is via th input rail only (all power is segregated) but in 2.73 this doesn't matter so not sure why in 2.74 it would.
Paul, two quick questions: (testing an X5 at the moment)
When the plane hits a waypoint radius it rocks from side to side about 3 times rapidly as if 'indecisive' before setting into the chosen direction of turn. How can I get rid of this?
Still getting a loss of height at the entry into a turn, also while in Loiter there's a regular increase and decrease in height. I've increased PTCH2SRV_RLL to 1.2, can I go higher and is this likely to solve it?
Hi,
I have tried to finetune my PIDs.
"I" seams doing nothing for me.
Did i miss something? :)
Thx,
Gábor
Hi guys, an update here, I have flown with the latest firmware now and had the same throttling issues. I then adjusted the pitch dampening to .5 an dthe time const to 10 then everything was fine.
The plane is flying very well but I have the two issues to solve which I am sure I will find in the wiki
1) After flying in manual mode and adjusting trims I imagine there is somewhere to reset the trims so that I can then centre my trims again... this way the AP is not fighting my trims all the time especially if you have stick mixing enbled which I do.
2) I still lost some altitude in turns but that pitch to roll compensation is now not available.... anywhere I can tweek this? I realize that I theoretically need to increase my pitch P but any more than I have now it over compensates in FBWA mode (in the graph the actual pitch moves before the nav pitch if I add anymore)
3) finally I had to put the D term to zero otherwise I was getting occilations.... in the MP when you hover over it the text says that most airframes should have zero D term... but this does not really follow along the new method of tuning where you would increase D until occilation then cut it in half.... I found my pitch occilation even with .001 a tiny bit... with 0 it's gone....
4) auto launch was a disaster 3 out of 3 attempts... one it did not pich up enough, the second time it pitched up too much, third time it rolled hard left. When you put in auto launch parameters it asked for pitch angle, I put in say 25 but in the MP at the bottom the take off angle is 15 no matter what number you put in... I changed that to 30 and that's when it pitched up way too high.... something is buggy here...
5) Finally for the grid pattern I have some suggestions as to how this should work... if there is somewhere I could post how to do a proper workflow for a good grid with wind that would be great.... some simple points are.... the grid should be perpendicular to the wind direction, the plane should start it's first leg on the down wind side so that the plane always turns upwind, finally the box should be rotatable by simply drawing a line on the map in the direction of the wind... then the box should align itself perpendicular to this. I can better explain all this.
Thanks guys, if I don't reply to this it's because it's lost in the barrage of emails I get from this subscription........
Steve
Had a much better flight today after my issues in this post, thanks Tridge and Paul for the advice
(I changed:
- PTCH2SRV_P from 0.6 to 0.9
- TECS_TIME_CONST from 5 to 10,
- TECS_PTCH_DAMP. from 0 to 0.2,
- THR_SLEWRATE 0 to 100.
- Added an Airspeed Sensor)
This is a single loiter (clockwise) in a 20-25km/h westerly wind (left in this picture), the plane was pushed downwind and then tightened up the turn greatly when turning back into wind. (Also, not sure why there seem to be two circles for the same loiter point):
Log attached, any improvement suggestions or insight from the log very welcome...
2013-07-27 07-53-22.tlog
While using this system with an air speed sensor, how will the flight control system react (/detect)on a air speed data failure?
The nature of failure might be gradual (e.g. Caused by preciptation) or sudden (bumble bee collision).
Sooner or later a pitot tube obstruction will occur to somebody and evaluating the possible consequences in advance seems desirable.
I have a feature request for Arduplane. Could it be possible to set the homeposition with a stick combination or a switch or something like that?
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. So it would be great to have the possibility to land, to do a stick combination (like arming a copter) and so reste the home position to the place where the plane stands.
Another reason to do so would be a change of the starting position without wanting to unplug the battery because afterwwards it would last several minutes to get a fix again. So if there would be a stick combination to reset the home position this could help a lot.
Thanks to all devs. This has been a very nice out-of-the-box firmware for me.
I just need to get my head around fine-tuning the TECS, which leads me to the following:
In the ArduCopter code there is an option to assign a channel for adjusting pre-determined parameters while flying. This is mainly used for tuning, but can also be used for setting i.e. navigation speed.
Also in the ArduCopter code, two channels (Ch.7 and Ch.8) can be used for quick selections of various functions, like CamTrig, Save WP, RTL and others.
Any plans on introducing similar functionality in ArduPlane?
/TIA
Jan.
Andrew,
If you can give higher priority to OSD horizon data, please do it.
It is only "running after" things but never seams to catch up.
Also after two spins CRUISE mode got a bit lost.
I have the COG arrow bottom middle. I think it reacted too fast for COG changes.
Here is the video about:
Thx,
Gábor
-
11
-
12
-
13
-
14
-
15
of 19 Next