APM:Plane 3.1.1 released

The ardupilot development team is proud to announce the release of version 3.1.1 of APM:Plane. This is primarily a bugfix release with a small number of new features.

The main bug fixed in this release is a bug that could affect saving parameters and mission items in the FRAM/eeprom storage of PX4v1/Pixhawk/VRBrain. The bug has been in the code since January 2013
and did not cause problems very often (which is why it hasn’t been noticed till now), but when it does happen it causes changes to parameters or mission items not to be saved on a reboot.

[color=#000080]Other changes in this release:[/color]

[ul][li]support for using a Lidar for landing for terrain altitude (see the RNGFND_LANDING parameter)[/li]
[li]improvements in the landing approach code, especially the glide slope calculation[/li]
[li]added LAND_FLAP_PERCENT and TKOFF_FLAP_PCNT parameters, to control the amount of flaps to use on takeoff and landing[/li]
[li]the default WP_RADIUS has been raised from 30 to 90. Note that the L1 controller may choose to turn after the WP_RADIUS is reached. The WP_RADIUS only controls the earliest point at which the turn can happen, so a larger WP_RADIUS usually leads to better flight paths, especially for faster aircraft.[/li]
[li]send gyro and accel status separately to the GCS (thanks to Randy)[/li]
[li]support setting the acceptance radius in mission waypoints (in parameter 2), which allows for better control of waypoints where actions such as servo release will happen[/li]
[li]fixed GPS time offset in HIL[/li]
[li]added RELAY_DEFAULT parameter, allowing control of relay state on boot[/li]
[li]fixed sdcard logging on PX4v1[/li]
[li]added GPS_SBAS_MODE and GPS_MIN_ELEV parameters for better control of the use of SBAS and the GPS elevation mask for advanced users[/li][/ul]
Happy flying!

Thanks - at least the Desktop-Airframe is working as expected :wink:

I just did a compass cal for my dual compass setup. I noticed that the compass calibration is now rounded of to a whole number. If this due to a change in the Pixhawk firmware or is that done in the Mission Planner. Is that a problem or is that the new norm?


Please help me understand the acceptance radius for waypoints.
Let me ask the question in the context of a problem I have had. While mapping 1cm resolution my flight lines are very close together. Using default WP Radius, the WP Radii overlap each other a lot. When flying, the WP would sequence quickly past the turning points, before the plane even had a chance to turn. This would result in the plane turning the wrong direction towards the WP at the other end of the flight line. I can create a graphic if my description is failing.

So now to my question. There are two purposes I see for the WP Radius. 1) Where the turn is allowed to start, and 2) when to sequence to the next WP (or command). Does the Acceptance Radius adjust #2?
Can I leave a larger WP Radius, but prevent premature sequencing by using a smaller Acceptance Radius?

Even i have been having the same problem, were you able to solve the issue? any luck.

What problem are you referring to?


is there now the function ROI integraded?

I want to point my camera on the APM to the point that I specify in the Mission Planner. Unfortunately, this feature is so far only possible in the copter and not on the plane. Is now incorporated this feature? The manual tracking is a bit stressful.

Best regards

Hello I can´t get the I2C Airspeed working with VRUBrain 5.1 and the latest Beta. Are the any known issues?
Is there a specific community for VRBrain. I did not know if its a board specific issue.
Cheers Gregor