I am trying to fine tune PID's on my quad and have two questions:
" A negative D value is used to help the ArduCopter change faster to a level position after forward flight."
"Once you are happy with hovering performance, try moving the ArduCopter into forward flight, then stop to a hover. Does the ArduCopter dip too much when transitioning from forward flight to a hover? If it does, the P gain may be overcompensating (too much motor power) when transitioning to a hover. To reduce this, apply a negative D value (try decreasing it by decrements of -5) to reduce this effect."
How does it behave in the non-stabilized manual mode?
Anyone? This seems like a normal question, am I in the wrong forum?
I've been fighting this same issue. So far I've tried a lot of things but haven't figured it out yet. I have a thread here.
Would you mind taking a look at the video and confirm this is what you're seeing?
Increasing my D values for both acro and stable mode seems to help a lot....but the value is VERY VERY sensitive. I've been creeping up by .001 at a time.
Sometimes its hard to tell if its the wind or the Ardupilot causing the quad to tilt when transitioning out of forward flight. I have 12" props on a very light helicopter, so the wind really gets under there. Either way, increasing D is helping, I'm going to keep on creeping it up.
I can't take my rate D over .004. What do you have your stab D at?
Just read over your thread, exact same problem. I did notice that increasing the D term definitely helped, but it still does what you describe. My quad flies pretty good in ACRO, but does still have an over pitch tendency when exiting forward flight. I don't notice it moving sideways, but I don't go ripping around fast sideways either. In stabilize mode it really pitches.
I feel like it must be an I term problem, because it seems to get worse the longer I've been pushing the stick forward. Have you tried setting Rate I and/or Stab I to zero?
My gut tells me the problem lies in tuning the RATE controller, not the Stabilize controller because the problem almost instantly rectifies itself after the overshoot. Or its a problem in the code.
I'll put some flight time on tomorrow morning and see what I can find, I ask you to please continue doing the same and let us all know...This has been an arducopter problem (on my quads at least) for a long time. Ive never had one that didn't do it.
I'm curious if our traditional helicopter flying has led us to expect a behavior that people that have only flown quads don't find odd. Like you said, when I stop giving input, I want my quad to level out and keep it's forward momentum, not jerk back trying to stop it's motion. Also, I don't see it in roll, but again, I don't zip around as much in a roll as I do in forward flight.
I agree that it's something building up, and my understanding of PID controller in general would say the error, or I term is what's building up. In my last bit of testing with these the attached settings I played with Rate Pitch IMAX.
With IMAX at 5, I got what was in the video I made, it seems to build up over time.
With IMAX at 1, it was really bad, so bad that a little bit of movement caused it to counter react.
With IMAX at 20, it didn't seem much different than 5.
So if the I term is building up, I thought lowering the IMAX to 1, would limit it's buildup and stop the problem, or is it in this case, the error, or rate i is the forward motion and we want that to build up?
I've done similar things playing with stabilize I and IMAX, but didn't notice any change. I'm going to keep looking at attitude.pde and try to get a solid understanding of what is happening in the main PID loop when we move forward. I see in the code that you can log all the variable values; I think just having that information would give us what we need to understand what's going on. I'll give that a try tomorrow afternoon and let you know what I find.
I just flew today and can't come back with good results. I have my quad flying wonderful in most respects However, it still pitches opposite the direction of movement, its does it worst forward and back. Worse yet, if I keep it moving slowly for an extended period (I like to fly back to my house, about a hundred yards and walk behind it) thus meaning 2-3 min of slight forward pressure, if I let go it pitches back significantly, far more than it was pitched forward, then quickly levels. If you are trying to fly FPV this is a no-go item. I would like to just push my trim forward when FPV flying but can't because the Arducopter fights these long term inputs (stabilze mode).
I am convinced this must be in the code, I have ramped my Stab and Rate I from 0 - 4 with no discernible difference in flight characteristics. I have lowered and raised my imax values from 0-5 with the I term at 0-4 with no flight changes. Are these values commented out in the latest release or something? I have changed the Stabilize D term from 0 - 4 with no changes, I have adjusted the "Stabilize D schedule" from 0 - 100 with no change (cant find documentation on that setting). Maybe this isn't a problem, maybe it is designed to work this way in the code, but I would prefer we had a mode that did not do this.
Just from my observations, the Stabilize code seems to operate as follows:
-A stick input commands a specific angle.
-If the input is held, the angle slowly scales down.
-If the stick is suddenly let go (a zero angle command) the scale addition still exists, and the quad is actually commanded in the opposite direction, which then ramps down to zero.
-When a tilt is commanded the motors automatically ramp up to prevent the helicopter from descending. This commonly causes my quad to rocket climb when letting go of the sticks, I have to bring the throttle way down until the scale command drops and then bring the throttle back up.
**Josh: have you seen this adjustment to acro mode (axis enable)? It basically looks like the quad will fly around in rate based mode with a slight bias towards leveling itself. (perfect!)
It looks like something that you and I might like flying in, but I can't find the settings for it in the mission planner...
That's good information. I'm just getting ready to head out to the field. I tested and verified my logging last night, and will hopefully get the variable information we need to see what's building up.
I was curious to test to see if this was being caused by fast movement forward or if just slow small stick input would case this, and I see you found that speed or angle of input doesn't matter. Some term is still building up.
Acro mode does work great for me, a lot like flying a helicopter. (It's just listed as a flight mode in mission planner.) However, when I fly FPV closer to objects or near the ground, I like stabilize mode for obvious reason.. I think Robert Lefebvre was working on a new flight mode that is basically acro mode with an axis lock, which might be close to what we're looking for.
I'll report back with what I find from the internal logging.
Correction, I see you were asking about the axis lock for acro-mode, not just acro mode. I think that's been removed and it's what Robert is currently working on.
Back to the problem, I did two quick test with the basic data logging on. I'm going to turn on a few more vales for my next run, but your assessment of the problem sounds correct. The value is building, and when the target rate (input) goes to 0, it has to unwind. It has nothing to do with I or IMAX from what I'm seeing.
The values are just way to high for it to tuned out with a D value. In the basic concept of PID's, we could lower our P value, and get a more smooth response, but doing that defaults the purpose of control when we're not moving much. Take a look at this data and the main control loop and let me know your thoughts one what we can change code wise, or maybe we should look into manually coding that axis lock into acro mode until Robert finishes the new mode.
I'm still working on my ideas for fixing this problem in stabilize mode.
I'm not a programmer, but I don't see anything in this code that defines what the target rate is. We are assuming it corresponds directly to stick position, but my guess is that is wrong. Same applies for target attitude. We need to understand how the quad determines the targets. Your data clearly shows the oscillation, with a huge P I and D buildup the moment you let go (understandable, the target pitch is now something like 70 deg off) so what is telling the target pitch to go back so much? I do not know. A developer needs to chime in...
You say the axis lock was in some older code? Do you have any idea which one? We could load it up...I think this is where we need to be looking. They should call it "flies like a real helicopter mode" lol