The ArduPilot development team is proud to announce the release of version 3.5.2 of APM:Plane. This is a minor release with small changes.
The main reason for this release over the recent 3.5.1 release is a fix for a bug where the px4io co-processor on a Pixhawk can run out of memory while booting. This causes the board to be unresponsive on boot. It only happens if you have a more complex servo setup and is caused by too much memory used by the IO failsafe mixer.
The second motivation for this release is to fix an issue where during a geofence altitude failsafe that happens at low speed an aircraft may dive much further than it should to gain speed. This only happened if the thrust line of the aircraft combined with low pitch integrator gain led to the aircraft not compensating sufficiently with elevator at full throttle in a TECS underspeed state. To fix this two changes have been made:
- a minimum level of integrator in the pitch controller has been added. This level has a sufficiently small time constant to avoid the problem with the TECS controller in an underspeed state.
- the underspeed state in TECS has been modified so that underspeed can end before the full target altitude has been reached, as long as the airspeed has risen sufficiently past the minimum airspeed for a sufficient period of time (by 15% above minimum airspeed for 3 seconds).
Many thanks to Marc Merlin for reporting this bug!
The default P gains for both roll and pitch have also been raised from 0.4 to 0.6. This is to help for users that fly with the default parameters. A value of 0.6 is safe for all aircraft that I have analysed logs for.
The default gains and filter frequencies of the QuadPlane code have also been adjusted to better reflect the types of aircraft users have been building.
Other changes include:
- improved QuadPlane logging for better analysis and tuning (adding RATE and QTUN messages)
- fixed a bug introduced in 3.5.1 in rangefinder landing
- added TECS logging of speed_weight and flags
- improvements to the lsm303d driver for Linux
- improvements to the waf build system
Happy flying!
Comments
@Anthony, "error velocity variance" is not documented that I found, and others seem to be puzzled by it too
http://diydrones.com/forum/topics/error-pos-vert-variance-what-does...
On my plane, it happens when the airspeed sensor is not plugged in, but generally variance messages are from EKF and because you have 2 sensors and they're not reporting something consistent.
@Anthony,
The various arming error messages are documented here:
http://ardupilot.org/plane/docs/arming-your-plane.html#diagnosing-f...
I just added an explanation for the GPS one, which was only added very recently.
I won't be able to look at the logs this evening, sorry. Hopefully I can soon. The most likely reason for the pause in takeoff is that the vertical velocity controller needs a bit of tuning. Looking at the QTUN.DCRt versus QTUN.CRt (desired and achieved climb rate) in a DF log can help work out what is going on. You will probably find that lowering Q_VZ_P a bit will smooth it out. That is the vertical velocity controller gain.
Cheers, Tridge
@ Tridge,
We now had a couple of flights, both with 3.5.0 as well as with 3.5.2. All well. But with today's flight, I got another strange message during flight, "Error velocity variance". What does this message means? It didn't affect the flight, the quadplane just went on normal, finished the test mission and landed perfectly.
I also noticed that during take off, there seem to be 3 stages:
- Quad starts, take off about 1 or 2 meters and pauses
- Increases another couple of meters and pauses again
- Increase again slightly, starts the fixed wing and goes flying.
Is that the way it should be?
Regards,
Anthony.
PS: Could you have a look at the previous logfiles? Today I had again this message about GPS 0 not fully configured. I reboot and it's gone.
The logfiles:
https://drive.google.com/open?id=0Bxps3ktVugpbTlZEM1dCeWVGOWc
@Tridge,
I got another very strange message on booting up this morning: "GPS 0 not fully configured". I re-booted and the message was gone, all worked well. You need the logfile?
By the way, what are the meaning of all those messages? I've been trying to find descriptions, explanations and possible suggestions for fixing, but cannot find anything.
no worries, good luck with the test flights!
I've changed the AUTO_FBW_STEER option so it is now only is enabled if set to a value of 42. That should make it less likely someone will enable it accidentally.
@Tridge,
That is very baffling. I can't think of any reason that option would have been set consciously. I guess we have to put that one down to user error. Sorry to send you on a wild goose chase looking for a bug that wasn't there.
We will try again with that parameter changed this afternoon and let you know how it goes.
Thanks for your help,
James
@James, I've found the problem. Your plane had the AUTO_FBW_STEER option set. That option completely disables autonomous navigation in AUTO mode. It is meant for users who want to fly manually but still use waypoint based control of relays and servos (eg. for dropping items at specific locations).
Do you know why you had that set?
@James, that older log is very useful, as it was with the 3.5.2 release version. That tells me the issue is not with the new velocity control landing code.
I still haven't found the bug, but at least this has narrowed it down a lot.
Today I decided to test out the new nav. logic "always exit loiter in AUTO towards next waypoint". I loaded an old mission that I had flown a couple of years back that have both CW and CCW LOITER_TURNS.
When it encountered a CCW loiter it turned CW. All loiters were CW. Is this a bug or is there a new way to input this information. I set the loiter radius to 1 for CW and –1 for CCW. I looked in the new documentation but could not find any information. Is this feature no longer supported?
.
-
2
-
3
-
4
-
5
-
6
of 8 Next