Both Copter and Quadplane have that parameter. It is important. Set it according to how much throttle is required to hover. However, even if this is set wrong, adding throttle stick would still prevent the QuadPlane from descending. You must have another issue.
Are you sure you aren’t in LAND mode?
Hi JeffBloggs,
I don’t think it’s a motor or ESC issue. Because my ardupilot automatically cut down the thorttle output which result in crash.I prefer to think it’s a sensor or algorithm problem.
Thanks for your post.
Can you post the problem log?
My ESC is Hobbywing. Especially for copter, 50 to 500 Hz.Does this type of ESC will cause the same peoblem? I encounter this peoblem even in 3.5.3.
@farstein,
Your log from 2016-05-27 shows an error in the calculated altitude. The GPS.RAlt value in the log is not in fact from the GPS sensor, it comes from the EKF. The altitude as measured by the GPS (in meters above sea level) is in GPS.Alt.
The EKF altitude comes from a number of sources:
the barometer
the accelerometers
the GPS vertical velocity
something had gone badly wrong in combining these to give a height estimate. As a result ArduPilot thought your vehicle was climbing when in fact it had stopped climbing at 2.4m off the ground. As it thought it was climbing and you were not commanding a climb it put in less power. That is why you lost height.
The bit that is most strange in your log is the GPS vertical velocity which shows a positive vertical velocity when the vehicle is not actually climbing. I think this is what fooled the EKF. Is there anything on the aircraft which could be interfering with the GPS signal? A video transmitter perhaps?
Since this flight the EKF has been considerably improved and this issue may be fixed. If it isn’t then we would need a log with LOG_REPLAY=1 and LOG_DISARMED=1 set so that we could debug the issues with the EKF.
Cheers, Tridge
Hi,tridge.
So many thanks for your reply.
I didn’t install any video transmitter. Why it didn’t happen in the traditional plane, while it come up in Q-plane only.I use the flight control and GPS/Compass which caused crash as a Q-plane , had no problem as a traditional plane. Isn’t it strange.
Does the material of the plane matter much?The crash always happened in glass fiber plane. The Q-plane crashing hadn’t happen in EPO q-plane.
And can i debug the issue by myself? I tried to programme it and found it’s a little hard for me.
Hi,tridge,
You said that"Since this flight the EKF has been considerably improved and this issue may be fixed" . Does it mean that the newest firmware 3.6.0 ,using a new EKF algorithm,has fixed this problem?
I have run your log against the current EKF using replay and it rejects the bad velocity data from the GPS instead of rejecting the barometer data, so it gives the right height.
That is not a guarantee though. The log was not captured with LOG_REPLAY=1 which means it isn’t a perfect replay. If the problem does happen to you with a newer version then please capture a log with LOG_REPLAY=1 and LOG_DISARMED=1 for us to analyse properly.
I do think it is very likely that it is fixed though.
Hi,tridge,Thanks for your timely reply.
Which version of firmware I should choose? I see the stable version was released at 2016-06-10 23:40.Is it ok?Or I should choose a latest beta version?