The ardupilot development team is proud to announce the release of version 3.1.0 of APM:Plane. This is a major release with a lot of new features and bug fixes.
The biggest change in this release is the addition of automatic terrain following. Terrain following allows the autopilot to guide the aircraft over varying terrain at a constant height above the ground using an on-board terrain database. Uses include safer RTL, more accurate and easier photo mapping and much easier mission planning in hilly areas.
There have also been a lot of updates to auto takeoff, especially for tail dragger aircraft. It is now much easier to get the steering right for a tail dragger on takeoff.
Another big change is the support of Linux based autopilots, starting with the PXF cape for the BeagleBoneBlack and the Erle robotics autopilot.
[color=#000080]Full list of changes in this release[/color]
[ul][li]added terrain following support. See plane.ardupilot.com/wiki/common- … following/[/li]
[li]added support for higher baudrates on telemetry ports, to make it easier to use high rate telemetry to companion boards. Rates of up to 1.5MBit are now supported to companion boards.[/li]
[li]added new takeoff code, including new parameters TKOFF_TDRAG_ELEV, TKOFF_TDRAG_SPD1, TKOFF_ROTATE_SPD, TKOFF_THR_SLEW and TKOFF_THR_MAX. This gives fine grained control of auto takeoff for tail dragger aircraft.[/li]
[li]overhauled glide slope code to fix glide slope handling in many situations. This makes transitions between different altitudes much smoother.[/li]
[li]prevent early waypoint completion for straight ahead waypoints. This makes for more accurate servo release at specific locations, for applications such as dropping water bottles.[/li]
[li]added MAV_CMD_DO_INVERTED_FLIGHT command in missions, to change from normal to inverted flight in AUTO (thanks to Philip Rowse for testing of this feature).[/li]
[li]new Rangefinder code with support for a wider range of rangefinder types including a range of Lidars (thanks to Allyson Kreft)[/li]
[li]added support for FrSky telemetry via SERIAL2_PROTOCOL parameter (thanks to Matthias Badaire)
added new STAB_PITCH_DOWN parameter to improve low throttle behaviour in FBWA mode, making a stall less likely in FBWA mode (thanks to Jack Pittar for the idea).[/li]
[li]added GLIDE_SLOPE_MIN parameter for better handling of small altitude deviations in AUTO. This makes for more accurate altitude tracking in AUTO.[/li]
[li]added support for Linux based autopilots, initially with the PXF BeagleBoneBlack cape and the Erle robotics board. Support for more boards is expected in future releases. Thanks to Victor, Sid and Anuj for their great work on the Linux port. See diydrones.com/profiles/blogs/fir … t-on-linux for details.[/li]
[li]prevent cross-tracking on some waypoint types, such as when initially entering AUTO or when the user commands a change of target waypoint.[/li]
[li]fixed servo demo on startup (thanks to Klrill-ka)[/li]
[li]added AFS (Advanced Failsafe) support on 32 bit boards by default. See plane.ardupilot.com/wiki/advance … iguration/[/li]
[li]added support for monitoring voltage of a 2nd battery via BATTERY2 MAVLink message[/li]
[li]added airspeed sensor support in HIL[/li]
[li]fixed HIL on APM2. HIL should now work again on all boards.[/li]
[li]added StorageManager library, which expands available FRAM storage on Pixhawk to 16 kByte. This allows for 724 waypoints, 50 rally points and 84 fence points on Pixhawk.[/li]
[li]improved steering on landing, so the plane is actively steered right through the landing.[/li]
[li]improved reporting of magnetometer and barometer errors to the GCS[/li]
[li]added FBWA_TDRAG_CHAN parameter, for easier FBWA takeoffs of tail draggers, and better testing of steering tuning for auto takeoff.[/li]
[li]fixed failsafe pass through with no RC input (thanks to Klrill-ka)[/li]
[li]fixed a bug in automatic flow control detection for serial ports in Pixhawk[/li]
[li]fixed use of FMU servo pins as digital inputs on Pixhawk[/li]
[li]imported latest updates for VRBrain boards (thanks to Emile Castelnuovo and Luca Micheletti)[/li]
[li]updates to the Piksi GPS support (thanks to Niels Joubert)[/li]
[li]improved gyro estimate in DCM (thanks to Jon Challinger)[/li]
[li]improved position projection in DCM in wind (thanks to Przemek Lekston)[/li]
[li]several updates to AP_NavEKF for more robust handling of errors (thanks to Paul Riseborough)[/li]
[li]improved simulation of rangefinders in SITL[/li]
[li]lots of small code cleanups thanks to Daniel Frenzel[/li]
[li]initial support for NavIO board from Mikhail Avkhimenia[/li]
[li]fixed logging of RCOU for up to 12 channels (thanks to Emile Castelnuovo)[/li]
[li]code cleanups from Silvia Nunezrivero[/li]
[li]improved parameter download speed on radio links with no flow control[/li][/ul]
Many thanks to everyone who contributed to this release, especially our beta testers Marco, Paul, Philip and Iam.
Cool Stuff in this 3.1.0!
What about flying wing with three control surfaces (elevon, flaps, spoiler)
and consequent mix, in a future release? Aka butterfly ><, to use spoilers
for brake on large wing at landing, with flaps deployed also.
Thank you for the update.
I just tried the Terrain Following feature on the ground. I can’t seem to get “ter_pend” to zero. In fact it stays at 18 and doesn’t budge.
Also, in MP, if I use Terrain and then the Elevation Graph, there is no indication of following terrain. I must be doing something simple incorrectly.
I have the feature enabled.
Any help appreciated.
@Icarus, can you post a tlog of it failing to get the terrain data?
The most likely issue is that the USGS site where we get the terrain data from is down (the site it dds.cr.usgs.gov/srtm/). It hasn’t been very reliable lately. I’m hoping we can setup a mirror on firmware.diydrones.com.
Cheers, Tridge
[quote=“tamiris”]
What about flying wing with three control surfaces (elevon, flaps, spoiler)
and consequent mix, in a future release? Aka butterfly ><, to use spoilers
for brake on large wing at landing, with flaps deployed also.[/quote]
you could do that with two flaps channels now, one reversed. Not very elegant perhaps, but it should work.
Cheers, Tridge
Hi Tridge,
Thanks for excellent work here. I’ve been “wishing” for terrain following for a long time, as I fly in an area with numerous hills.
However, I’ve tried to initiate the feature but without success. I followed the Wiki above but never see “ter_pend” go to zero or for that matter, move at all.
I assume in Flight Planner one selects terrain? I then do an “elevation graph” to check that I’m not running into any mountains and it would appear the plane will clip peaks.
Another odd thing is when I “read” the Flight Plan back from the PH, I don’t get terrain any longer I get relative or absolute???
Any help or more detail in the wiki would be appreciated.
Thank you!
I flew 3.1.0 for a few flights this morning and the AUTO mode was not nearly as smooth as 3.0.3. I really noticed that it used a lot of throttle and rapid pitch change on transitions to WP’s of different altitude. It does not gradually climb and descend between waypoints. This is with the exact same mission that I was flying with 3.0.3.
I think there must be a bug in the navigation altitude control logic. Log file attached.
I solved the problem. Turns out that the new GLIDE_SLOPE_MIN parameter was messing up my missions.
The default is 15 meters, which means that if the difference between waypoints is 15 meters or less it will make an abrupt altitude change. I had several waypoints that were 5 meters difference and one that was 15 meters. It would actually shut off the motor and dive 15 meters as soon as it passed the previous waypoint.
I change it to 1 and just got back from flying half an hour. Now 3.1.0 is smoother than 3.0.3 just they way it is suppose to be.
The default value should have been something that gave similar performance to the previous version. The default value of 15 meters sounds way too high to me and I don’t see and useful purpose of such a large number.
What about the ability to enable the status LEDs. I am still not using my plane but LEDs installed. Since I lost the last one due to arming error.
All the best,
John
[quote=“Icarus”]Hi Tridge,
Thanks for excellent work here. I’ve been “wishing” for terrain following for a long time, as I fly in an area with numerous hills.
However, I’ve tried to initiate the feature but without success. I followed the Wiki above but never see “ter_pend” go to zero or for that matter, move at all.
I assume in Flight Planner one selects terrain? I then do an “elevation graph” to check that I’m not running into any mountains and it would appear the plane will clip peaks.
Another odd thing is when I “read” the Flight Plan back from the PH, I don’t get terrain any longer I get relative or absolute???
Any help or more detail in the wiki would be appreciated.
Thank you![/quote]
These are all Mission Planner issues that I have raised on GitHub #573 and #566.
There is no visual indication of terrain following in MP. The Elevation Graph shows only Relative Altitude. Feel free to write a comment on the GitHub posts linked above.
[quote=“RC Mike”]The default value should have been something that gave similar performance to the previous version. The default value of 15 meters sounds way too high to me and I don’t see and useful purpose of such a large number.
[/quote]
I’m glad you’ve tracked it down!
The reason for the 15m value is that some planes were never achieving the desired altitude. If they are a few meters below altitude at one waypoint, then try to slowly climb up to the next, but lose some altitude in turns then they on average flew a few meters below the target. This particularly happens for people with poorly tuned pitch loops.
Cheers, Tridge
[quote=“astrojohn”]What about the ability to enable the status LEDs. I am still not using my plane but LEDs installed. Since I lost the last one due to arming error.
[/quote]
You mean the APM2 LEDs?
We already use the bright LEDs on Pixhawk, and also support the I2C ToshibaLED on APM2. I’ve never tried the old APM2 LED code. Have you thought about getting a I2C ToshibaLED ?
Cheers, Tridge
I found another advantage of lowering the GLIDE_SLOPE_MIN to 1. It actually increased my flight time slightly.
When set to 15 it uses up the battery faster because it has lots of high power surges to make small altitude corrections. It does have instant altitude corrections. The value that’s best it probably depends on your airplane and level of tuning. With Autotune their is no excuse for having a badly tuned airplane.
It depends what you are trying to achieve.
For my planes I really care about always being at the right altitude as I’m using the plane for search and rescue, and if the plane is too low then we don’t get the coverage of the ground we have planned for with the mission track spacing. So if the plane is 10m too low I really want it to gain altitude immediately, not slowly over a long mission leg (my mission legs are around 2km long).
If what you care about is maximizing flight time and smoothness then a lower value will be better.
Cheers, Tridge
