I had fiddled with this off and on years before, but never really worked it out properly or had the time (or a spare robot) during build season. Itâ€™s nice to see it formalized and posted here.

Just to make it clear (or correct me if Iâ€™m wrong), the X and Y are not the actual joystick numbers from the X and Y axis (eg, in y = x^3, axis x number doesnâ€™t produce axis y number), but the input and output from each direction, so really you should have two formulas:

The deadzone or band would be a separate calculation (at least programming-wise); a simple â€śif input is between -0.2 and +0.2 then Y= 0â€ť. Whilst doing it all at once would be elegant, it would be a nightmare to debug. Though looking at the graph for f(x)=x^3, in all practicallity the robot motors might not overcome robot weight at all under +/-0.3.

I wonder what the effect would be if a<0? That is, more power near zero (to overcome the robot weight) and leveling off at higher speeds.

In practice this would have to be adjusted to each individual robot; even similar robots (a prototype and competition robot for example) would have different results. Also adjust to the driver, as different drivers like different reactions. If the driver doesnâ€™t notice it, then it works!

Correct. The X and Y are general variables. You can use this approach for any signal, not just the inputs from a joystick. For a 3-axis joystick, if you wanted to independently adjust the sensitivity for each axis, it would look like this:

Xâ€™ = a1*X^3 + (1-a1)*X

Yâ€™ = a2*Y^3 + (1-a2)*Y

Zâ€™ = a3*Z^3 + (1-a3)*Z

â€¦looking at the graph for f(x)=x^3, in all practicallity the robot motors might not overcome robot weight at all under +/-0.3.

Yes, at higher values of the â€śaâ€ť parameter, you may not need to add deadband.

I wonder what the effect would be if a<0? That is, more power near zero (to overcome the robot weight) and leveling off at higher speeds.

Higher gain near zero, lower gain at higher commands. Not recommended under normal circumstances. See the added purple lines in the attached graph*. Also, youâ€™d have to add logic to constrain the output to the range -1/+1.

In practice this would have to be adjusted to each individual robot; even similar robots (a prototype and competition robot for example) would have different results. Also adjust to the driver, as different drivers like different reactions.

Yes, thatâ€™s the idea.

*for some reason this thread does not allow me to attach the graph

We use four linear equations (y=mx+b). First, we test our robot. So far, every robot we have built has been skid-steer. This means that there is an appreciable amount of motor force that it takes to break the robot into a skid to turn. Utilizing a control on the dashboard, we watch the values required to break it free using only one side. This is the B-intercept of our equation, so that the instant you move the joysticks out of the controllerâ€™s preprogrammed deadband, you have enough power to turn the robot at the slowest possible speed.

So we use one equation from 0 to about 80% power. This portion has a gentle slope. After that, the slope goes from that point up to 1 (maximum joystick), 1 (maximum motor output). The nice part is that we only need to enter two values into our custom VI. The â€śBâ€ť y-intercept value that the drivetrain manages to start turning the robot at, and the intersection point of the two slopes.

For instance, if you were to graph it, the positive domain of the joystick would have these x,y points:

(X,Y)
(0,0.2)
(0.7,0.7)
(1,1)

Iâ€™m trying to attach a picture, but it doesnâ€™t appear I can do so in this forum.

Does anybody know why this is, and can it be corrected? I also had the same problem: I wanted to attach a graph to a previous post in this thread but was not able to.

Out of curiosity, is there anything special about the function x^3+x?

Recently weâ€™ve used an exponential graph:
Let min = lowest desired value (min>0, usually the highest value at which the robot doesnâ€™t move)
Let max = highest desired value (usually, max = 1.0)
Then, output = min(max/min)^joystick value.

This also enables us to vary the max value for the turning axes based on the robotâ€™s forward speed.

Just to be clear (to avoid possibly confusing other readers), the function is not x^3+x, it is f(x) = a*x^3 + (1-a)*x. This function has some interesting properties.

As mentioned in the paper, when a=0, it becomes f(x)=x. When a=1, it becomes f(x)=x^3. When 0<a<1, itâ€™s something in-between. You can vary the â€śaâ€ť parameter to create a curve between f(x)=x and f(x)=x^3 to obtain the desired gain at low joystick settings.

Also, f(x) maps the domain (-1â€¦1) into the range (-1â€¦1) for any chosen value of â€śaâ€ť between 0 and 1, so thereâ€™s no extra code required to break the domain up into, say, x<0 and x>0.

Recently weâ€™ve used an exponential graph:
Let min = lowest desired value (min>0, usually the highest value at which the robot doesnâ€™t move)
Let max = highest desired value (usually, max = 1.0)
Then, output = min(max/min)^joystick value.

Clever. I like it.

If you want to add a Y-intercept to the f(x) function, you can do it like this:

g(x) = b + (1-b)*[a*x^3 + (1-a)*x] for x>=0
g(x) = -b + (1-b)*[a*x^3 + (1-a)*x] for x<0

Now you have 2 adjustable parameters: â€śbâ€ť and â€śaâ€ť. The â€śaâ€ť parameter still adjusts the gain, and the extra parameter, â€śbâ€ť, adjusts the y-intercept.

Interestingly, if you set b=0.2 and a=0.5, you get almost exactly the same curve as your exponential curve with min=0.2.

I have a graph prepared to illustrate this but canâ€™t attach it to this post for some reason*. Iâ€™ll upload it when I get a chance.

This also enables us to vary the max value for the turning axes based on the robotâ€™s forward speed.

Could you provide some more detail explaining what you mean please.

*if a moderator happens to be reading, would it be possible to change permissions on this thread to allow attaching graphs?

Nope! Pick anything that your drivers are comfortable with.

Selecting a joystick mapping function is one of the best teaching opportunities you have in FRC. There are many right answers, it is open to opinion, it is super easy to prototype, you can objectively compare a bunch of them on a whiteboard, and it answers the questions set forth in this article: http://www.fordham.edu/academics/programs_at_fordham_/mathematics_departme/what_math/index.asp . That is to say, it might be the first time the students go in the â€śfrom problem to mathâ€ť direction, instead of the â€śfrom math to problemâ€ť direction.

ax^3+(1-a)x does have a few special properties, see if your students come up with these in their lists of â€śwantsâ€ť for their formula:

The function is smooth

The 1st derivative is smooth

It is tunable.

The gain is low near 0.

â€¦and high near 1.

The gain inflection is always near the middle (.577, per Ether)

@Ether
Cool, will try it with the y-intercept. Really curious if Iâ€™ll be able to feel a significant difference at different a-values.

When I stated â€śThis also enables us to vary the max value for the turning axes based on the robotâ€™s forward speed,â€ť I meant that we found at high speeds, a slight tap to the side on the joystick will send the robot flying away. So, for example, when the robot is moving 1.0 (full speed) in the y-direction, then we might only allow the robot to move up to 0.1 in the x-direction. When the robot isnâ€™t moving in the y-direction, then we allow the full 1.0 turning speed.

@EricVanWyk
As a student, steering curves was the first time I went from problem->math; it was definitely among my fav. robotics experiences. I will try this with some of the rookie programmers, and maybe my calc teacher

Well, that makes sense from a physical point of view. For those of us old enough to remember driving cars before the days of power steering, think how hard it was to turn the steering wheel when the car was not moving (like while parallel parking).

To address this problem, you could use the 2-parameter g(x) function, and treat the â€śbâ€ť inverse deadband parameter like a variable instead of a tuning constant. In other words, adjust the value of â€śbâ€ť (for the rotate axis conversion) as a function of speed before running your joystick rotate axis through the g(x) conversion. * caveat emptor:* Iâ€™ve never tried this.

I took the liberty of parameterizing it, to make it tunable on-the-fly.

Hereâ€™s an implementation written in Delphi:

*
*if (x>=a) then y := c+(x-a)*((1-c)/(1-a))
else if (x>=0) then y :=b + ((c-b)/a)*x
else if (x>=-a) then y := -b + ((c-b)/a)*x
else y:= -c + (x+a)*((1-c)/(1-a));

The above connects the points (-1,-1), (-a,-c), (0,-b), (0,b), (a,c), and (1,1) with straight line segments.

The three parameters are a, b, and c:

â€śbâ€ť is the y-intercept (inverse deadband), and

(a,c) are the coordinates of the point at which the slope changes

Yesterday I gave this to one of my programmers to put into our LabVIEW code, as a sort of a warm-up exercise. An added bonus was making it a sub-vi to plug into future code.

There is a difference in driving, though perhaps not enough to change a good driver with careful joystick control. We didnâ€™t test it fully however.

A suggetion that simplifies changing â€śaâ€ť from rewriting code to letting the driver change it on the fly: use the thumb-thingie on the KOP joystick (itâ€™s at the base in the front and is known as axis3). Itâ€™s range is -1 to +1, but with simple math can be converted to 0 to +1.

If you use the one with 2 tunable parameters, you could use three buttons to tune the two parameters: one button to bump parameter â€śaâ€ť up/down; one button to bump parameter â€śbâ€ť up/down; and a third button to select up/down.

Oh dear, Iâ€™m way behind, arenâ€™t I? We were using the original y = a(x^3) + (1-a)x formula. That â€ś2parmâ€ť looks interesting for Mondayâ€™s programming session.

I think we might be running out of joystick buttons. Weâ€™ve got 2 buttons already for switching gear speed up and down â€“ yet another parameter in the mix, as â€śFull cubicâ€ť in first gear is really slow.

Another thing I might mention is that we are changing only the â€śforward/backwardâ€ť axis of the joystick, and the â€śleft/rightâ€ť axis is not being changed. (The robot is a standard drive left/right sides.) General thought of the group is that this gives full turning power always.

Perhaps this is the result of a misunderstanding. Just to be clear: You would still have â€śfull turning powerâ€ť if you used this sensitivity adjustment for the turn axis.

Look carefully at the figures and the associated narrative. This filter does not reduce the maximum available output. It just changes the response curve to reduce the gain for small commands. The maximum output of the filter is +/-1 regardless of the values selected for the tuning parameters.

What kind of drivetrain are you using, and what type of driver interface?

This probably should go in another paper, but it helps handling a lot if you get some speed vs PWM data, and then curve fit it so that you can convert the nonlinear response of the Victors to a nicer linear response. I ended up using a 7th order polynomial last year to do that, and it helped quite a bit.