Px4-autopilot: Create pure racer config

[LorenzMeier]

We should add a pure racer config:

• MPU6K output rate at 500 Hz
• Attitude control running at 500 Hz
• ekf2 rate-limited to 250 Hz at lower priority
• OneShot enabled and with proper QGC UI config for it

With some logs from that we should then infer what the limits are and if we need to disable position fusion completely (only run the attitude estimator) or what a safe setup is.

[MaEtUgR]

IMHO it should be possible to adapt the structure such that a special reacer configuration is generally not needed. This would allow a racer to benefit from all failsafe modes. But what really motivates me it would for sure help to increase the flight performance of other airframes.

My first goal is to find a software setup, even if it's a total zombie, that works comparable to other popular flight stacks on a racer. This is probably the most important step to achieve because it allows to get a feel for the bottlenecks on the rather complex platform. I'm currently trying this whenever I find the time after work.

[LorenzMeier]

@MaEtUgR @nkhoit Let's continue the discussion from https://github.com/PX4/Firmware/pull/7640 here:

Objectives:

• Tune default racer config for 250 frame better to provide acceptable performance (without changes)
• Upgrade rate loop to 500 Hz (without boosting EKF rate) @priseborough Would be great if you could pitch in

Logs:

• Acro mode
  http://review.px4.io/plot_app?log=9a8ce565-5af4-4c50-8314-82352c4b15d6
• Acro on 2nd airframe: : http://logs.px4.io/plot_app?log=c686a30f-2a7d-4657-a934-c137a42b4037
• Manual mode (untuned attitude controller)
  http://review.px4.io/plot_app?log=c103b9fd-19e4-45f0-a897-30e1b2e3bf31
• Acro and manual (fast flicking attitude)
  http://review.px4.io/plot_app?log=ce8ce910-4011-4da2-b8dc-e64e5adccd59

[dagar]

Should we split the sensor_gyro message? Publish x, y, z at max rate (subscribed by the rate controller) and the integrated values at 250 Hz.
https://github.com/PX4/Firmware/blob/master/msg/sensor_gyro.msg

[LorenzMeier]

The more I think of that the more this seems to make sense. Simple and clear.

[LorenzMeier]

Feel free to beat me to it - I'm sure @MaEtUgR and @nkhoit are happy to test it.

[priseborough]

Agree, we should split the control feedback (angular rate) data from the navigation data as the required rates are not compatible. The most critical control loop in terms of latency/phase margin is the rate loop, so we should be aiming at synchronous transfer of data from gyro -> driver -> rate controller -> PWM.

The attitude control loop has a lower bandwidth and is less phase critical so we could continue to provide attitude data from the estimator at 250Hz. This does introduce the problem of inter-sampling noise with the current controller because the attitude will update every 4th controller fame which introduces small 'steps' in the rate controller demand. During high angular rate manoeuvres, this will cause excessive noise i the esc demands at 250Hz if the derivative term is being used because it has has no noise filtering.

The following changes will mitigate this effect :

1) Add a parameter adjustable first order LPF (use bilinear transform for reduced phase loss) to the rate error before it is differentiated. This is something that will help other setups as well because noise sensitivity currently prevents the D term being used to it's full potential on most setups.
2) Apply a second order filter to the rate demand (runs at 1000Hz) with a cutoff frequency somewhere between 60 and 120Hz - note this introduces phase delay to the rate loops.
3) Use the angular rates to wind the attitude quaternion forward so that the controller has an attitude update at 1kHz. This is an efficient operation would involve:
a) converting the angular rate to a delta angle by multiplying by the time step
b) converting the delta angle to a delta quaternion using the small angle approximation
c) Use the quaternion product operator and delta quaternion from b) to wind the attitude forward
Steps a) to c) will need to be performed recursively for each angular rate update and the quaternion reset to the value published by the EKF when it is received.

Option 1) should be implemented regardless of other options.
Option 3) is preferable to Option 2) in terms of control loop performance, but is more work.

[dagar]

Hmm, I guess we shouldn't split out the rate controller if option 3 is preferable.

[priseborough]

It depends on how successful option 1) is. If that is adequate on it's own to manage the intersampling noise, then 2) and 3) are not necessary.

I would delay the decision to split or not to split until after 1) has been implemented and the ESC demand noise levels evaluated.

Option 3) will give around a 2 msec reduction in latency in the attitude feedback. For example if the attitude loop has the default gain of 6.5, then that equates to a dominant closed loop pole at 6.approximately 5 rad/sec or 6.5/(2*pi) = 1.03 Hz. This equates to a phase delay reduction of less than 1 degree which in isolation would appear to be not worth the effort. However it should be compared to the phase lost from implementing option 2) which will be less than 5 deg. Whether a net gain in phase for the attitude loop of less than 6deg is worth the complexity remains to be seen.

If we split then we will also have additional latency in the attitude loop due to transmission delays across the uORB. One way to work around loss of phase in the attitude loop is to reduce MC_PITCH_P and MC_ROLL_P values and increase the value of MC_PITCHRATE_I and MC_ROLLRATE_I. This tuning strategy effectively moves some of the attitude stiffness from the attitude loop into the rate loop. This is beneficial from both disturbance rejection and control saturation handling, however it is a departure from the way that PX4 has traditionally tuned the loops and does increase the time constant from demanded to achieved attitude which is set by MC_PITCH_P and MC_ROLL_P.

[MaEtUgR]

I would definitely vote for splitting rate and attitude controller because it would make the control stack more modular and I've seen a lot of quadcopter softwares that successfully have the rate controller running a lot faster than the attitude controller just holding the rate setpoint constant in the meantime without introducing any significant problems. Of course noise filters especially on D in the feedback loop and also for the reference signal can be a good help for tuning further.

I would go with 1kHz rate controller with direct gyro data only (accelerometer does in theory not have to be read out with it) and the Attitude controller could even only run at only 50Hz and I'm pretty sure the performance difference would be marginal. This 50Hz does not include the attitude estimator, @priseborough knows best how fast that should run.

I like the idea of updating the quaternion as paul described in the fastest possible frequency because it's really cheap to compute and I had good experimental results during my master thesis doing that.

The shift from high gain attitude controller to high gain rate controller is exactly what is my goal because I think it will result in better high angular rate performance, better disturbance rejection, more stable looking flight in general (less wobbling).

[LorenzMeier]

I'm closing this since we addressed a bunch already.