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
Oh OK, thank you for the clarification!
@Andrew, 65535 is the right value for logging when armed in plane. The link you gave is for copter which is a bit different.
Cheers, Tridge
@Andrew Tridgell
Are you sure the correct LOG_BITMASK number is 65535? I have here:
http://ardupilot.org/copter/docs/parameters.html
That the number is supposed to be 655358. Is this correct? Also, I have accidentally put the 65535 number as the LOG_BITMASK setting and my Pixhawk stopped recording data on the dataflash log.
Thanks a lot. Simple fix. Appreciate your ultra fast reply. The more I use the QuadPlane, the more I like it.
@Anthony,
The reason it slowed down is really just poor documentation for the quadplane code :-)
The slow down happened after it left waypoint 30 and started heading for waypoint 31. Waypoint 31 is a NAV_VTOL_LAND command, so it had started its landing. Waypoint 30 is 380 meters from waypoint 31.
As soon as it started on waypoint 31 it engaged the vertical lift motors as it was then starting towards the VTOL landing. In the current quadplane code it is up to the user to set the distance over which it does the landing based on the distance between the last waypoint and the landing point. It is not smart enough to say "that is much too far to travel in a hover, lets keep using fixed wing flight for a while".
That sort of logic of automatically working out at what distance from the landing point it needs to engage the quad motors is something I am working on, but isn't available yet. For now you need to another another intermediate waypoint at a distance appropriate for your aircraft. For this aircraft that would be about 100m. For your larger aircraft you'd probably want 150m or so as it will probably take longer to slow down.
Cheers, Tridge
@Andrew. Yesterday early morning, had a super experience with our VTOL. We did an agricultural mapping mission and the output was amazing. All went well, take off, flying and return. But then something weird happened. After passing the last waypoint, about 350 meter from the VTOL landing point, the Quad was started and he went into hover mode, moving very, very slowly. Luckily we were able to switch to QHover and manualy (quickly) moved him to the landing area. All in all it took about 2 minutes. Also luckily, the hover battery didn't drain and we landed safely.
The question is, why did he go to hover so far away from the landing point??
TLOG file is here: https://drive.google.com/open?id=0Bxps3ktVugpbeGN5MzhDaU5oYW8
@Amirali, that isn't expected. Could you post a tlog showing the effect?
@Mike, the 3.5.3 release is now out
Hello Andrew, I had a question regarding different behaviour that I've noticed in 3.5.2. It seems like the my plane has no rudder control prior to arming the motor. As soon as I arm the motor the rudder works and once the motor is disarmed it stops working. Is this intended? Thank you in advance for your help.
@Mike, it's coming, I just haven't had a chance to test fly it yet, sorry. All the changes are trivial so I'm completely confident in them, but I don't like doing a release without a test flight
-
1
-
2
-
3
-
4
-
5
of 8 Next