-
Notifications
You must be signed in to change notification settings - Fork 13.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tuning Pixracer for Acro mode #3751
Comments
@Tumbili Could you have a look and see if anything stands out? |
@kd0aij So what is obvious is that the roll rate is observable and uncommanded. Which bears the question what led to the roll rate. Which essentially means we can rule out that attitude estimation is the issue here, because the roll rate is zero with Naze. We'll have to dig in the control side of things. |
It appears to me as though Pixracer's ATTC.roll is responding appropriately to ATT.RollRate. |
What comes first: The rate change or the response? How do the motors change before and after? |
Right when the four motor outputs have a noticeable step in their output the roll rate becomes non-zero. In particular the spread of yellow to the rest is changing. What is throttle doing there? |
I'm wondering why the ATTC.Roll curve is so noisy compared to the RollRate. Do you maybe need to drop your roll D gain and ramp up your P and I gains a bit? |
@LorenzMeier @kd0aij In the logs from the Naze the filtered rollrate (control state topic which is used for control) is actually tracking the raw rollrate better. This means that the raw rollrate is not as noisy. |
I think the naze P gain is too high. I'll reduce it and see if it starts behaving like the PIxRacer. Having trouble getting the PixRacer to fly today. |
reducing naze32 roll/pitch P gain by 50% resulted in random zero-mean deviations in angle, very different from PX4 behavior. Just became a bit "wobbly" instead of getting difficult to control |
log and video from Cleanflight/naze32: https://youtu.be/1JhWcNtSgmI |
@LorenzMeier @Tumbili doubling the roll/pitch rate P gains solved the PixRacer Acro mode stability problem for me, with no oscillations evident in Acro mode. Will have to look at the log to tell for sure. |
@kd0aij Cool, would be interested to see the log. Have you verified that attitude control is still good? Sometimes you tune around steady state forgetting that the drone still needs to move :-D |
The issue will be whether we need different rate gains for ANGLE vs ACRO modes. It was dark here by the time I got my Pixracer parameters restored well enough to fly it, so the log is short and the throttle channel parameters were still hosed. I'll fly some more after daylight here today and see whether I can tune for both acro and angle mode. The dual FC setup will allow direct comparison of flight characteristics for both autopilots, and will make clear (to me at least) the shortcomings in our user interface for setup and tuning. |
With roll/pitch rate gains doubled to 0.1, the PIxracer does a better job of holding zero rates in Acro mode, but on this flight I again observed random uncommanded roll/pitch events. Switching to stabilize mode showed that this P gain results in excessive roll/pitch oscillation in that mode. The presence of uncommanded roll/pitch rates even at higher gains is indicative of a control problem though, since the naze32 did not exhibit such behavior even with reduced gains. It is also informative that "stabilize" (angle) mode oscillates when the rate P gain is just sufficient for good rate-mode control. |
After reviewing the rate control code I think there are several possible issues:
@kd0aij Try setting ATT_BIAS_MAX to 0 and see if the issues go away with wandering gyro. Make sure you still do a static gyro calibration before flight so that is is reasonable. |
@kd0aij When you were saying it was unlikely that you would have to tune the outer pitch/roll loops that would make sense if you were able to get a similar rise time and damping ratio as the default px4 quadcopter, but with this frame I would guess you have a higher natural frequency/ faster rise time than the default and therefore require different roll/pitch outer loop gains. |
@jgoppert I think you are right about gyro bias estimates causing the problems in rate mode flight. This flight has ATT_BIAS_MAX 0.0, and although conditions were gusty during the entire flight, I was able to see the effect of a single click of pitch trim on the attitude of the copter. |
@kd0aij Glad to hear that worked for you. So now if you still want dynamic gyro bias compensation, you might try leaving ATT_BIAS_MAX at default 0.05 and turning down ATT_W_GYRO_BIAS from 0.1 to something more like 0.01 and see if it flies well. That will make the magnitude of the corrections about 10 times less. |
ATT_W_GYRO_BIAS = 0.01 still causes noticeably erratic behavior. Still On Mon, Feb 15, 2016 at 5:16 PM James Goppert notifications@github.com
|
no px4log from the last 2 flights. Is there anything in the message files to help debug that? |
I don't see anything obvious. I'm assuming blackbox is the new name for sdlog2. If you hadn't changed the firmware at all it seems unlikely to be a software issue. The parameter change should have had no effect on that. |
Reason for crash and missing logs is probably due to excessive memory use. "free" reports a bogus value for free memory. |
Another log with less gusty breezes and gyro bias disabled. |
@kd0aij Is it possible the airframe is generating a pitching moment due to the aerodynamics? Are we sure the naze32 is not using any roll/pitch/yaw information to hold attitude? |
The aerodynamics are definitely different for pitch and roll, and it may just be that I need higher pitch gain for the Pixracer. Will try that next. I looked at the CleanFlight "LUX" PID code which I flight tested, and it seems pretty clear that it's not using anything but gyro rates in Acro mode. |
much improved acro mode behavior of Spedix S250AQ with these parameter changes: |
Let's create a new config for it and set the correct defaults. |
I'd really like to see a plot of the integrator states for roll and pitch. If they were slowly time varying, it might mean that we are using the integrator for the gyro bias correction. This would mean we should try to fix this on the estimator side. If it varied with pitch/roll significantly, it would mean that we are compensating for the aerodynamics. If it is the aerodynamics, you should be able to adjust MC_ROLLRATE_FF/ MC_PITCHRATE_FF to account for the aerodynamics, at least the best you can linearly, and then this would allow you to lower MC_ROLLRATE_I and MC_PITCHRATE_I back to the default levels. |
what's the best way to log that data, assuming it isn't already there? |
Don't think it is logged. I think you can use the named float debug message maybe. Not sure if that is just mavlink or also implemented in sdlog2. |
rock solid tracking with rate mode controls |
Logging of integrator states is already implemented in sdlog2 and should log by default. Its the message group "MACS". |
@einma1 Thanks, that saved some work. |
PX4 is flying well in acro mode when tuned properly |
Pixracer is not as stable as Naze32/Cleanflight in acro mode. There appears to be some source of random error in attitude estimation or control which causes random deviations from zero roll and pitch rates. This greatly increases pilot workload.
Two successive flight logs on a dual FC Spedix S250AQ with Naze32 and PixRacer. PixRacer logged both flights; FrSky X4R-SB connected to both Naze and PixRacer; ESC leads moved from Naze to PixRacer for second log.
Naze32 log: http://logs.uaventure.com/view/4jfjkJAs8LgGr24m5m7gsR
PixRacer log: http://logs.uaventure.com/view/DZMnFmU6MgvAqTwd6oXnuC
Consider that if attitude estimation is the source of error, the log for the Naze32 flight will not accurately reflect its stability. I will look at Cleanflight's logging capabilities next.
The text was updated successfully, but these errors were encountered: