Other name for <DifferentialDrive>.curvatureDrive

In my old age I’ve run out of easy access memory.
<DifferentialDrive>.curvatureDrive, speed on one stick, turn on the other, has another Ancient & Honored name here.
What is it?

TIA,
Tim

Arcade ?

Nah, this is the two stick version of Arcade. Speed and forward/backward on one stick, rotation on the other.

Somebody in the past got this named after them.

Some people need to consult Screensteps on this matter. :wink:

Arcade != curvature.

In arcade drive, your rate of rotation depends on your forward speed. With curvature drive, these are decoupled.

The Cheesy Poofs have used this drive for a few years, as such it was often called Cheezy Drive until its inclusion into WPILib and wider acceptance.

I think you have that backwards.

In Arcade drive, your rate of rotation does not depend on your forward speed*.

With curvature drive, the rate of rotation does depend on your forward speed: it is adjusted as a function of forward speed so as to maintain a commanded curvature.

  • unless your combined fwd & rotate saturate the available voltage.

That is still arcade. Nothing about arcade requires both axes to be on the same joystick, and in fact many teams implement arcade in this way. Curvature drive is different as Ether explained.

Not to derail the thread, but one thing we’ve found extremely helpful is a sort of “generalized curvature drive,” where instead of outputs (left,right) of the form (fwd + fwdrot, fwd - fwdrot), we instead use (fwd + p(fwd)*rot, fwd - p(fwd)rot) for some polynomial p (we actually use a generalized polynomial which allows fractional powers, as we’ve found something of the form p(x) = a + bsqrt(x) to be most-intuitive for drivers).

The problem with standard arcade drive is that, depending on the scaling of your turning axis, you generally end up either over-steering at low speeds or under-steering at high speeds. The problem with standard curvature drive is that most drives do, actually, tend to want to turn on tighter radii at low speeds than high speeds - just not as drastically as is the case with ordinary arcade drive.

Adding a tuneable function to enable precise control of the dependence of curvature on forward speed is quite helpful in finding a happy “middle-ground.”

Kaj Drive? https://www.chiefdelphi.com/forums/showpost.php?p=1433462&postcount=7

Not a hijack, a great contribution. My programmers have been playing with tuneable responses in tank drive lately. I think tomorrow we will explore tuneable “Kaj Drive”.

Thank you all, I learned stuff.

DING DING DING DING

We have a winner!

Thank you very much, that was exactly what I could not remember. This lead to a bunch of posts. Whether curvatureDrive and Kaj drive are the same will be explored shortly.

Tim

It’s so much more fun to ask here and be reminded of Kaj drive and doing some custom tuneable code ourselves.

The thing is, describing curvature drive as “speed on one stick, turn on the other” as you did in the first post is incorrect. Since curvature drive is actually “speed on one stick and curvature on the other”, it is Cheesy drive, not Kaj drive. We said it was Cheesy drive on the “New for 2018” page on ScreenSteps, so I brought that up as a hint. I was assuming you just misspoke when you said “turn”, but I guess not. A more precise term would have been “rotation” since arcade drive works on forward speed and rotation values.