Closed expntly closed 3 years ago
I had a pretty acute instance of this issue today when after it landed the plane raised its nose by 30 degrees or so until all motors turned off for good. It landed on a surface that seemed pretty level.
Here's a screenshot and DF log, see the landing at 17:23:40
https://dl.dropboxusercontent.com/u/67653/share/land-nose-up.png
https://dl.dropboxusercontent.com/u/67653/share/land-nose-up.BIN
@tridge - I know this is not high prio but is there a way to mitigate this effect for now? Could this be symptomatic of some other issues? I've had a few "PreArm: Gyros inconsistent" messages lately, if this is related I'm happy to take suggestions on how to fix and see if I can reproduce.
I had a look at the log, but don't totally understand what is going on with qplane code (I'm a copter guy).
But at a guess, I wonder if the issue is that when landing in QLand, it's attempting to hold position. If it has landed, but missed it's target position, it is attempting to "fly" back to it's desired target. Since it can't move, the desired angle ramps up until the nose lifts off.
I imagine QStabilize is like Stabilize in copter, where the target roll/pitch angles are zero if you're not touching the sticks. But in QLand, it's probably trying to hold a position.
In copter code, there's a bunch of stuff that prevents this problem from happening, but it might not exist in Qplane currently.
@R-Lefebvre: Interesting theory. Forgive my ignorance but what parameters are you plotting to conclude this must be a positioning issue?
I don't have the data to be sure, as I'm not an expert on quadplane code. But it appears to me that the desired pitch angle is slowly increasing, which is why the motors are ramping up. And I would bet the desired pitch angle is increasing as a navigational I-term is ramping up because it can't move.
Is there a way to track pos/nav error in the logs? If you have the answer for copter that would help anyway.
On Sat, Nov 19, 2016 at 5:51 AM, Robert Lefebvre notifications@github.com wrote:
I don't have the data to be sure, as I'm not an expert on quadplane code. But it appears to me that the desired pitch angle is slowly increasing, which is why the motors are ramping up. And I would bet the desired pitch angle is increasing as a navigational I-term is ramping up because it can't move.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ArduPilot/ardupilot/issues/5123#issuecomment-261715054, or mute the thread https://github.com/notifications/unsubscribe-auth/AGjVtOE2NXtZ2CL4AqaCsoG_ZQYHMbf3ks5q_v7fgaJpZM4KmyvC .
On Copter, you would look at NTUN message, and you have DVelX, DVelY, DAccX and DAccY. And then in a GPS guided mode like Loiter or Auto, you would see resultant ATT.DesRoll and DesPitch.
@expntly I took a look at your log and don't have any great insights into the problem, @tridge is best for this. I'll ping him to take a look at this.
Of note: If you look at PIDP.I and PIDP.D (PID controller for Pitch) you'll see the D term spikes before all this happens implying it felt an impact and then the I term grows because the demanded pitch is not being achieved. Also, the IMU.AccZ spikes too which is another indicator that you've touch the ground. You've definitely touched down before all this happened.
NTUN.WpDist is the distance to waypoint. It is slowly growing after you land implying you're moving further away from the point that it's trying to reach so it's trying harder and harder to get closer to it until it finally realizes it's landed and shuts down.
I think this may just be a problem with the landing detector not reacting fast enough and the GPS error (or maybe EKF?) is thinking we're drifting around on the ground and since we're "not landed" yet it's trying to get over closer to the place it's trying to land at.
Ok, that seems to agree with what I was suggesting. Does Quadplane use the Copter landing detector, or something else?
@magicrub @R-Lefebvre -- Thanks for helping out!
Of super important note: I'm running with some changes related to precland for the quadplane, I need to push these changes (basically AC_PosControl is used similarly to https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/control_land.cpp#L265). I'm not sure these could interfere so badly and cause these issues but it's probably best to test without precland to eliminate the possibility. I'll update the thread soon.
.. yes, custom code will result in custom results. Please let us know how your testing goes.
I ran some tests today without my precision landing backend. I can confirm the issue is still present.
Here's a first log where I did 3 QLANDs, the second was particularly bad with the left wing up by 20-30 degrees, the third with the nose up by about as much. https://dl.dropboxusercontent.com/u/67653/share/quadplane-2016-11-22-post-landing.BIN
Since I have pretty high QVXY{P,I} values (2 and 1), I ran another set of tests with 0.5 and 0.25 respectively. The effect seems less pronounced but is definitely still there. I'll do another round later with a lower Q_PXY_P as well. See here until 10:08: https://dl.dropboxusercontent.com/u/67653/share/quadplane-2016-11-22-post-landing2.BIN
Also when a rangefinder is installed, is there any reason why we can't solely rely on it to tell if we're landed or not?
More tests today. A lower P gain (0.2) for the horizontal position controller still shows the issue. Here is one instance where the nose went up, to be clear I added a red arrow when it's landed: https://dl.dropboxusercontent.com/u/67653/share/nose-up.png
Since the previous tests were using a custom firmware I re-flashed with a vanilla Plane-3.7.1 release. I also did pretty much a full reset on the params and started from there.
So far the best results are obtained with low velocity controller values such as Q_VXY_P=0.35 and Q_VXY_I=0.17. With these I observed the issue for less than 5% of the landings. The P seems to play a bigger role.
With this same firmware and Q_VXY_P=2 and Q_VXY_I=1, the effect is the same craziness as before and I had a few close calls where the plane raised its nose by an alarming 45 degrees.
The position controller doesn't seem to have a big influence.
Then the question becomes why would one use such high velocity values. The thing is precision landing actually needs these if you want any decent accuracy. Hence the conflict.
I'll clean up the precland changes I have and send a PR, perhaps this will give some ideas on how things can be improved.
perhaps this falls under quadcopter expertise? @rmackay9 can you comment on this? Let me summarize: VTOL Plane velocity controller works with normal or low PID values but when you crank them up almost an order of magnitude larger for PrecLanding then stuff misbehaves. Since you're doing PrecLanding on copter, maybe you've seen something similar before or have some advice?
By the way, after using the QuadPlane code extensively on all kinds of different vehicles (very light and very heavy) for a while, I'm still having this problem. Anything I can try to help mitigate and report back? I'm probably not as qualified as the devs but when using a rangefinder, why isn't this trivial?
Sorry we never resolved this, I'm afraid after this time the report is of limited use.
Issue details
Right after landing (VTOL_LAND and QLAND), the VTOL motors are still pretty "nervous" and seem to slowly increase in power before being turned off for good after ~5 seconds. It's bad enough that the aircraft will almost tip over. Switching to QSTABILIZE right when it lands has been the best strategy so far.
Version
commit 0bcbf726acc86cfd6eae4929cdd65ef31c535818
Platform
[ ] All [ ] AntennaTracker [ ] Copter [X] Plane [ ] Rover
Airframe type
Quad plane.
Hardware type
Pixhawk
Logs
It's easy to reproduce with the simulator and default params:
-f quadplane
qstabilize; arm throttle; rc 3 1700
qland
Here's a graph that shows when it lands at 13.352 and the increase until 13.358: https://dl.dropboxusercontent.com/u/67653/share/land-quad-motors.png
I'll produce a full DF log if needed.