Default drivetrain turn PID values create large oscillations

[sfe-SparkFro]

It works okay on a soft surface like carpet, but hard surfaces result in large oscillations that take an excessively long time to settle.

Also, not sure why there are commented values in here, and why kd has an undocumented (max(max_effort, 0.5) - 0.5) * 2 term:

XRP_MicroPython/XRPLib/differential_drive.py

Lines 253 to 266 in 00c2cc7

	main_controller = PID(
	# kp = 0.2,
	# ki = 0.004,
	# kd = 0.0036,
	kd = 0.0036 + 0.0034 * (max(max_effort, 0.5) - 0.5) * 2,
	kp = 0.2,
	ki = 0.004,
	#kd = 0.007,
	min_output = 0.1,
	max_output = max_effort,
	max_integral = 30,
	tolerance = 1,
	tolerance_count = 3
	)

[KalticCodes]

This has happened quite a few time now where we've tuned the turning for some surfaces but then it struggles on others - the commented values are likely from that back and forth of tuning on different surfaces? If we can find a better solution that would be less dependent on battery power and drive surface that may be the best option. Maybe we take inspiration from WPILib and provide a tuning function where the robot attempts to drive + turn, then outputs what PID terms would be good?

[sfe-SparkFro]

What kind of surfaces result in the XRP struggling to turn? I'm guessing thick carpet or something? And how common are those surfaces versus hard surfaces where large overshoots occur? IMO the defaults should be tuned for whatever surfaces are most popular, which I'm guessing are desks and hard floors.

And for situations when the XRP struggles to turn, shouldn't the integrator kick in and fix it? Or is max_integral naybe limiting the integrator? Could also looks at increasing tolerance, 1 degree seems maybe a bit tight.

[KalticCodes]

Let me pull @bradamiller into this conversation since he's the one who updated the tunings in question most recently, and I'm not sure why - it was changed 10 months ago but i think the change wasn't packaged into a release until the official release?

In general the integral term should settle the motion, but large oscillations imply that ki is too large or that kd is too low- having too low of a ki results in a super long settling time because the combination of a small-ish error and a small ki just takes forever to correct itself. In theory this small error could be considered within the tolerance, but in the past I've found that when the tolerance is too big (~5 degrees) the XRP will coincidentally hit the sweet spot while moving, so it'll just overshoot and say its good enough instead of correcting itself

[sfe-SparkFro]

it was changed 10 months ago but i think the change wasn't packaged into a release until the official release?

I've experienced these oscillations for quite a while now, I only just opened an issue about it. Should have spoken up sooner, sorry!

large oscillations imply that ki is too large or that kd is too low

Can also be caused by kp being too large, all 3 terms contribute.

having too low of a ki results in a super long settling time because the combination of a small-ish error and a small ki just takes forever to correct itself. In theory this small error could be considered within the tolerance, but in the past I've found that when the tolerance is too big (~5 degrees) the XRP will coincidentally hit the sweet spot while moving, so it'll just overshoot and say its good enough instead of correcting itself

Can look into increasing tolerance_count. 3 seems a bit low for a 10ms loop rate.