paper: joystick sensitivity (gain) adjustment

[Ether]

Originally Posted by Roger

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.

Which one did you try? The one with just tunable sensitivity, or the one with both sensitivity and inverse deadband tuning parameters?

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.

[Roger]

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.

[Ether]

Originally Posted by Roger

...the "left/right" axis is not being changed...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?

[AustinSchuh]

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.

[Ether]

Originally Posted by AustinSchuh

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.

Would you be willing to post your data? (Or maybe you already have?)

[AustinSchuh]

Originally Posted by Ether

Would you be willing to post your data?

Sure. I only tested it one direction and duplicated the data as you can see. The data isn't quite as clean as I would have liked, but it's not bad and worked well enough. I exploited the symmetry when I fitted it to avoid getting answers that didn't make much sense.

# Speed Power	Data on blocks.
0.103448	0.020000
-0.103448	-0.020000
0.252874	0.043000
-0.252874	-0.043000
0.333333	0.059000
-0.333333	-0.059000
0.454023	0.082000
-0.454023	-0.082000
0.517241	0.098000
-0.517241	-0.098000
0.614943	0.145000
-0.614943	-0.145000
0.724138	0.184000
-0.724138	-0.184000
0.793103	0.223000
-0.793103	-0.223000
0.885057	0.363000
-0.885057	-0.363000
0.965517	0.559000
-0.965517	-0.559000
1.000000	0.918000
-1.000000	-0.918000

[Joe Ross]

By default, RobotDrive squares the inputs before it outputs the PWM, so you should consider the affects of that on any input adjustments.

[AustinSchuh]

Originally Posted by Joe Ross

By default, RobotDrive squares the inputs before it outputs the PWM, so you should consider the affects of that on any input adjustments.

If you are referring to the data that I provide, that was generated using the victor.Set function, rather than passing it through the RobotDrive.

[Roger]

Originally Posted by Ether

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

It's our 2009 robot with skid steer/tank drive; see this photo. We're using LabVIEW and the standard KOP joysticks and driver station. A single joystick does the driving. The robot drive has the drill-type gear shifter (1st and 2nd gear only; 3rd gear was too fast for Lunacy's floor.)

Adding the second axis to the formula won't be a problem. It was more of "let's get one working first, then add the second." But now that you wrote it out, it makes sense that full power is always possible. We just ran out of time to do the changes.

This was a perfect project as a warm-up, with just enough learning joystick interfacing, sub-vi creation, and math programming, to get done in an hour then debug and change and test after. Adding the different modes and deciding which is "best" will be fun.

There are also two different drivers that we have to program for, and not for the same time. The first (and obvious) is the high school competition driver, who has practice driving with the robot. The second, more unpredictable, driver is the off-season "carnival" driver, a wanna-drive-the robot seven-year-old that throws the joystick all over the place. The former is easy, the latter we can only slow down the action so the robot doesn't crash too much.

[jhebbel]

Sorry to revive a more than dead thread but its really the only relevant thread I could find. Im intrigued by the b + (1-b)*[a*x^3 + (1-a)*x] equation, but also confused, doesnt this need to be formated to solve for x and not y? Has anybody done this yet?

[jhebbel]

For anybody else that lands here from Google like I did wondering the similar, The reason I though the equation needed to be formatted to solve for X is I didn't realize this was for inverse deadzone, to calculate for traditional deadzone it is y=G*((x-D)/(1-D))^3+(1-G)*(x-D)/(1-D); Where X is in value, D is Deadzone and G is Gain.