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
Hi,
I have a very strange phenomena. During startup, I have "Bad AHRS", which prevent me from arming. Since we are just doing static testing, I disable arming check and arming required.
Now, I still have bad AHRS, followed by "Error velocity variance", Error pos horiz variance", "Error compass variance" and the artificial horizon goes wild..
This continues for a minute or so, after which all become stable and all seems normal.
Very scary....
The logs are here: https://drive.google.com/open?id=0Bxps3ktVugpbUXpNbEFMVVZJWmc
Hope you can shed some light on this.
@Tridge
Yes, that video is right, although it is hard to see due to the angle. At 0:21 the mode is changed from QStabilize to Auto and the plane starts accelerating of its own accord.
That log contains just one attempt at the auto mission. If it is useful, this (much larger) log contains two attempts at the mission towards the end. The start of this log shows succesfull use of QLoiter and QLand.
https://www.dropbox.com/s/tibwksg1a2dfrgn/21.BIN?dl=0
I realise this mission is somewhat contrived, we just wanted to verify that vtol_takeoff and vtol_land were working as expected before we tried full missions.
Thanks for looking into this!
James
@James, Is the video you linked to the right one? I don't see the nose-down.
I've started looking at the log file and I can see the problem happening in the first switch to AUTO. The other AUTO segments in the log are on the ground.
I haven't previously considered the case where a VTOL land is done as the first mission item. I suspect the new velocity controller is not being initialised correctly.
I will look into it and get back to you soon
Cheers, Tridge
@Andrew Tridgell
We have been using the new quadplane code on our 8kg flying wing quadplane. We are running latest build.
After a bit of tuning it controls the aircraft very well in QSTABILIZE, QHOVER, QLOITER, and QLAND. We are yet to try transitioning the aircraft. Yesterday, with the latest code, we tried running an auto mission with a single mission item, DO_VTOL_LAND. We engaged auto from QStabilize, directly above the waypoint position at around 20m. The aircraft instantly goes nose down and starts accelerating and losing altitude. We repeated this problme several times. Logs show the quad motors were still trying to stabilize, but the pitch deviates suddenly from the desired pitch.
This video shows the problem:
https://www.youtube.com/watch?v=AJ2_LuTiHwI
In the simulator this exact situation works as expected, with the aircraft landing verticlaly and disarming.
Help would be much appreciated.
@tridge, mmmh, sadly I have 9 logs from this morning and I'm not super sure which one is what anymore or what portion would be the one you need. Also, I made the mistake of having minalt and retalt be the same, so GUIDED didn't have to climb much, just arrest the descent.
I'll do another one my next series of flights and capture GUIDED actually climbing 50m with full flaps to see how it does and get you a a clean log.
@Phil, not being still on bootup won't make any difference to an "accelerometer inconsistency" error, as we only calibrate the gyros not the accels on startup.
It could be that your accels are more temperature sensitive than usual and that is causing the problem. If you enable logging while disarmed and post a DF log showing the failure to arm then we can diagnose it properly.
To enable logging while disarmed set LOG_BITMASK to 131071. Remember to disable it again after getting the log (by setting LOG_BITMASK back to 65535) or you will fill your microSD quite quickly.
@Marc, great, thanks for testing!
Can you post your DF log? In the change to the pitch controller I set the lower limit on integrator quite conservatively. I suspect your aircraft should have an I gain of 0.3 or so.
@Andrew Tridgell, I just did some test flights with 3.5.2 today, with full flaps down, breached the low altitude fence, and let GUIDED take over a few times.
While it struggled to stop the descent the bit and regain altitude (and that's expected, the flaps are big), it did the right thing and went back up.
So at this point, I have some confidence that your fix did indeed fix something :)
Thanks again for that.
Do a 3 axis accelerometer calibration and reboot the Pixhawk. Also you need to hold your model perfectly still during boot up
-
3
-
4
-
5
-
6
-
7
of 8 Next