Tuning Pixracer for Acro mode

[kd0aij]

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.

[LorenzMeier]

@tumbili Could you have a look and see if anything stands out?

[LorenzMeier]

@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.

[kd0aij]

It appears to me as though Pixracer's ATTC.roll is responding appropriately to ATT.RollRate.

[LorenzMeier]

What comes first: The rate change or the response? How do the motors change before and after?

[kd0aij]

I'm not sure you can tell that from the log:

[kd0aij]

[LorenzMeier]

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?

[kd0aij]

not much

[LorenzMeier]

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?

[RomanBapst]

Naze rollrate unfiltered vs rollrate filtered

Pixracer rollrate unfiltered vs rollrate filtered

[RomanBapst]

@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. You can also see in the log from the Pixracer that the rollrate is kind of jumping around very fast while in the other log it's more of an oscillation around zero. Maybe this noise is created by the D part of the controller, so you can try to reduce that a bit. I would also suggest like Lorenz to try and increase the rate P gain. In the log from the Naze the rollrate is always oscillating around zero which could mean that the rate tuning is actually very tight (oscillatory behaviour).

[kd0aij]

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.

[kd0aij]

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

[kd0aij]

log and video from Cleanflight/naze32: https://youtu.be/1JhWcNtSgmI The last hop shows that the P gain is way too low, but it's still easy to fly.

[kd0aij]

@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.

[RomanBapst]

@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

[kd0aij]

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.

[kd0aij]

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. Unfortunately, this flight ended in total loss of control in Acro mode. Battery was ejected on impact, so no postflight messages: http://logs.uaventure.com/view/5eBbpzSgyAsCFJxuip5xVg This could have been just an RC link loss. I have been getting very poor RSSI readings with this X4R-SB receiver; good enough for the backyard but perhaps indicative of impending doom.

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.

[kd0aij]

log segment with good roll rate tracking:

[jgoppert]

After reviewing the rate control code I think there are several possible issues:

1. The gyro bias estimation might be getting updated poorly. Possibly due to external mag disturbance, but this doesn't seem to be the case. The gyro bias estimation might also just be performing poorly. We should probably try to plot it, or just commenting it out temporarily.
2. The rate feedback is occurring after the attitude_estimator_q is updated, which might be long enough lag to cause some issues.
3. Has anyone else successfully tuned the gains for this frame? Do we know how to map from the naze gains to PX4?

@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.

[jgoppert]

@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.

[kd0aij]

@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. http://logs.uaventure.com/view/Q5uFqcyCC5NuVAASWqyazi

[jgoppert]

@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.

[kd0aij]

ATT_W_GYRO_BIAS = 0.01 still causes noticeably erratic behavior. Still harder to fly than naze but I just realized I had 40% expo on naze and none for pixracer. Oh well, will have to fly some more :) There was a little less wind this time, and it was easy to tell that disabling the bias compensation made a positive difference.

On Mon, Feb 15, 2016 at 5:16 PM James Goppert notifications@github.com wrote:

@kd0aij https://github.com/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 corrects about 10 times less.

— Reply to this email directly or view it on GitHub https://github.com/PX4/Firmware/issues/3751#issuecomment-184450044.

[kd0aij]

no px4log from the last 2 flights. Is there anything in the message files to help debug that? 2016-02-16.zip I had QGC running on a Nexus7 connected via wifi the whole time, and did not arm till after 3D lock and home position set.

[jgoppert]

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.

[kd0aij]

Reason for crash and missing logs is probably due to excessive memory use. "free" reports a bogus value for free memory.

[kd0aij]

Another log with less gusty breezes and gyro bias disabled. The quad holds roll well when flying sideways, but is not so good on the pitch axis. Initiating forward flight then centering the stick results in pitching backwards past level, as though there is a growing bias in the pitch gyro. Was able to fly small slow circles though. @sjwilks Acro mode is apparently not recognized as "manual" by the log muncher. Also, the altitude plot isn't very useful at my field elevation. http://logs.uaventure.com/view/HTsjfsvwLeNCJtHbQeTpfF

[jgoppert]

@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?

[kd0aij]

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. https://github.com/cleanflight/cleanflight/blob/master/src/main/flight/pid.c#L185 In Acro mode, the AngleRate setpoint is purely a function of stick inputs, and feedback is pure rate gyro, and that's also what the comments say.

[kd0aij]

much improved acro mode behavior of Spedix S250AQ with these parameter changes: ATT_BIAS_MAX 0.0 MC_ROLLRATE_D 0.005 MC_ROLLRATE_I 0.1 MC_ROLLRATE_P 0.1 MC_PITCHRATE_D 0.005 MC_PITCHRATE_I 0.2 MC_PITCHRATE_P 0.1

[LorenzMeier]

Let's create a new config for it and set the correct defaults.

[jgoppert]

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.

[kd0aij]

what's the best way to log that data, assuming it isn't already there?

[jgoppert]

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.

[kd0aij]

rock solid tracking with rate mode controls http://logs.uaventure.com/view/Znrb9te2EXF36jxxHfMSVb

[einma1]

Logging of integrator states is already implemented in sdlog2 and should log by default. Its the message group "MACS".

[kd0aij]

@einma1 Thanks, that saved some work. https://github.com/PX4/Firmware/pull/3813#issuecomment-187173528

[kd0aij]

PX4 is flying well in acro mode when tuned properly