What's the difference between RATE.R and ATT.Roll?

RATE.R is the angular rate (degrees per second) the autopilot is achieving on the roll axis. ATT.Roll is the angle (degrees) it is currently at. The rate loop is the inner controller; the angle loop sits outside. An oscillation in RATE.R but not ATT.Roll is rate-loop tuning; an oscillation in ATT.Roll with clean RATE.R is angle-loop tuning.

Why does dropping ATC_RAT_RLL_D not fix my oscillation?

Because your oscillation is probably below 10 Hz. D gain damps high-frequency motion; lowering it doesn't help slow wobbles. Identify the frequency from an FFT plot first — high-frequency motor whine fixes with D and notch; visible slow wobble fixes with P or angle-loop adjustment.

How do I run an FFT on my flight log to find the oscillation frequency?

Set INS_LOG_BAT_OPT = 4 and INS_LOG_BAT_MASK = 1 before the tuning flight (these enable raw IMU batch sampling). After flight, open Mission Planner → Setup → Advanced → FFT → IMU Batch Sample and load the .bin. The pre-filter gyro plot shows the noise spectrum; the dominant peak is your motor frequency or oscillation frequency.

Is a 5 Hz wobble dangerous?

It's a tuning problem, not an immediate crash risk on most airframes. The controller is fighting itself but the EKF and the angle controller are still receiving usable data. Sustained wobbles do tire out motors and shorten flight times, and on lightweight airframes can cause structural fatigue cracks over many flights.

Why does my drone oscillate only on the roll axis?

Three usual causes. First, asymmetric motor or prop balance — one motor on the roll axis delivering different thrust. Second, frame stiffness mismatch — one side flexier than the other. Third, the roll PIDs are not equal to pitch PIDs (which they should be on a symmetric quad). Compare ATC_RAT_RLL_* against ATC_RAT_PIT_* — if they differ, that's your starting point.

When should I tune the angle loop versus the rate loop?

Always tune the rate loop first (with AutoTune or manually). The angle loop sits outside the rate loop and depends on it being correct. Tuning ATC_ANG_RLL_P before the rate gains are right amplifies any rate-loop oscillation into the angle layer.

Diagnosing Roll and Pitch Oscillations in ArduPilot RATE and ATT Logs

TL;DR: Roll/pitch oscillations show up in ArduPilot logs as the achieved attitude rate (RATE.R) or angle (ATT.Roll) tracking a desired value with periodic error. The diagnosis depends on frequency: above ~10 Hz the cause is almost always rate-loop D gain too high or motor noise leaking through; below ~5 Hz the cause is rate-loop P too high, structural flex, or saturation. Identify the frequency, then apply the matching fix — the wrong fix for the wrong band makes things worse.

What the log carries

Two messages do most of the work. ATT records the attitude controller's desired vs achieved angle:

ATT  TimeUS  DesRoll  Roll  DesPitch  Pitch  DesYaw  Yaw  ErrRP  ErrYaw  AEKF

RATE records the rate-loop equivalent — the layer that actually drives the motor mix:

RATE  TimeUS  RDes  R  ROut  PDes  P  POut  YDes  Y  YOut  ADes  A  AOut  AOutSlew

RATE.R follows RATE.RDes with under 50 ms of lag in a healthy tune. ATT.Roll follows ATT.DesRoll with a similar relationship at the angle layer. Sustained oscillation appears as a sinusoidal error between the two.

Reading the frequency

The fix depends on the oscillation frequency, so identify it first. In Mission Planner, plot RATE.R versus RATE.RDes for the affected axis, zoom into a few seconds of oscillation, and count peaks per second. In MAVExplorer:

MAV> graph RATE.RDes RATE.R
MAV> graph ATT.DesRoll ATT.Roll
MAV> fft RATE.R

The FFT plot tells you the dominant frequency directly. Three bands matter:

Above 30 Hz — almost always motor noise leaking through the gyro filter. The harmonic notch isn't configured or isn't tracking. See ArduPilot's harmonic notch setup.
10–30 Hz — rate-loop D gain too high. ATC_RAT_RLL_D is amplifying gyro noise into motor commands.
Below 10 Hz — rate-loop P gain too high (very fast) or structural / payload coupling (slower).
Below 1 Hz — angle-loop P (ATC_ANG_RLL_P) is over-aggressive, or the position controller is fighting itself in Loiter.

The decision tree

High-frequency whine, motors audibly humming. Look at VIBE.VibeX/Y/Z. If they're above 30 m/s², the problem is mechanical — balance props, check motor mounts, foam the FC, and re-fly before touching gains. If VIBE is clean, drop ATC_RAT_RLL_D in 25% steps and re-fly.
Visible roll wobble in hover. 5–10 Hz. Drop ATC_RAT_RLL_P in 10% steps and confirm the wobble decreases. If the wobble persists with low P, the airframe likely has structural flex.
Slow wallowing in Loiter or PosHold. Below 1 Hz, often with RATE.ROut not saturating. Reduce ATC_ANG_RLL_P, or if you also see PSCN.PN oscillating against PSCN.DPN, tune the position controller (PSC_VEL_XY_P).
Oscillation only on one axis. Check the motor balance on that side. Strap into a hover stand and measure RPM per motor at hover throttle — one motor delivering less thrust than the others produces a single-axis wobble.

The harmonic notch comes before any gain tweak

Modern Copter builds rely on INS_HNTCH_* to suppress motor noise before the rate loop sees it. If the notch isn't tuned:

Set INS_LOG_BAT_OPT = 4 and INS_LOG_BAT_MASK = 1 for one tuning flight.
Hover for at least 30 seconds.
Open Mission Planner → Setup → Advanced → FFT → IMU Batch Sample — load the .bin.
Read the peak frequency from the pre-filter gyro spectrum.
Set INS_HNTCH_ENABLE = 1, INS_HNTCH_FREQ = peak_freq, INS_HNTCH_BW = peak_freq / 2, and INS_HNTCH_MODE = 1 (throttle-based) or 4 (in-flight FFT, F7/H7 only).

With the notch in place, raising ATC_RAT_RLL_D doesn't amplify motor noise — that's the gain you need to get a tight tune. AutoTune almost always succeeds after this.

What ATT.ErrRP tells you

The ErrRP field is a smoothed combined roll/pitch error magnitude in radians. A healthy hover has ErrRP below 0.05 (about 3 degrees). Sustained above 0.1 with motors not saturated means the airframe can't keep up with what the controller is asking — the loop is fighting itself. Anything above 0.5 for sustained periods is what the crash check uses to declare loss of control (ERR Subsys=12 ECode=2).

When it's not really an oscillation

Pilot-induced oscillation. The pilot oscillates the sticks and the airframe responds. RCIN.C1 shows the same period as ATT.Roll. Not a tune problem.
Wind gusts. Disturbance enters from outside, the controller reacts, oscillation damps within a second or two. Sustained gust patterns at low frequency can look like a tune problem but are airframe authority limits.
EKF noise. If XKF3.IVN/IVE are spiky, the position controller is chasing a noisy estimate. Fix the EKF before tuning. See our EKF innovation post.

When LogHat helps — and when it doesn't

LogHat runs the FFT for you on every flight log and flags axes where the dominant frequency falls in the noise-amplification or P-gain-overshoot bands. We also surface the parameter snapshot at takeoff so you can correlate a tune change with the resulting behaviour. What we can't tell you is whether your customer's heavy payload variation is the real cause — that needs the payload mass logged alongside the flight, which the autopilot doesn't capture.