Desensitizing Joysticks

[bob1million]

My fellow programmers and I have tried many different ways to desensitize our joysticks, but none of ways work very well. Does anyone know a good way to desensitize them?

[edomus]

My fellow programmers and I have tried many different ways to desensitize our joysticks, but none of ways work very well. Does anyone know a good way to desensitize them?


Why dont you just get new joysticks. very good ones can be found for cheep

[WillyC]

My fellow programmers and I have tried many different ways to desensitize our joysticks, but none of ways work very well. Does anyone know a good way to desensitize them?

You could make a different "transfer function" for the joystick in the form of a lookup table. For instance, right now the transfer function for joystick input to motor output is purely linear (not including the x and y axis mixing). It's linear in the sense that the motor output is linearly proportional to the joystick deflection from neutral.

You could make a slightly non-linear lookup table to de-sensitize the joystick in whatever region of deflection you want. This is actually what I use this lookup table generator for - to rapidly prototype and test new transfer functions for the joystick.

If you want some help, let me know...

[KenWittlief]

how much do you want to back them down?

lots of teams just divide the joystick variable by 2, then add 64 to make 127= center again

or divide it by 4 and add 96 to make 127 = center

you can have this as optional code, with a button or operator switch that lets you switch between normal and "fine tuning" mode of driving.

[Gusman1188]

We played around with joysticks for a while trying to desensitize and the only way that we found effective is to just state something like the following
if (p1_y <= 135 && p1_y >= 127)
{
p1_y = 127;
}

if (p1_y >= 119 && p1_y <127)
{
p1_y = 127;
}


We tried this but just decided to buy new ones or use last years.

[Vladimir]

Here's how I'd do it... first psuedocode for understanding:


x1 = p1_x; // get an axis, store it in temp variable
x1 = x1-127; // make 0 = neutral
x2 = abs(x1); // find magnitude from center
x3 = (x2/127) * x1; // create harshly curved value
x4 = (x3+x1)/2; // average curve with real to lessen curve
p1_x = x4+127; // restore neutral to 127 and replace value


then this should actually work and is a lot more concise... it assumes you have an abs( function available, either include a math library or make your own with something like if (x<0) x*=-1; -- I haven't tested this so don't run me over with your robot if it doesn't work off the first try, there may be some casting or something required with this compiler, but it'll at least be close.


p1_x-=127;
p1_x = ((p1_x*abs(p1_x)/127)+p1_x)/2+127;


Hope this helps some!

-Sean

[fox46]

Hmmm... I'm not a programmer, but I think a large hammer would do it! :D

[KevinB]

We played around with joysticks for a while trying to desensitize and the only way that we found effective is to just state something like the following
if (p1_y <= 135 && p1_y >= 127)
{
p1_y = 127;
}

if (p1_y >= 119 && p1_y <127)
{
p1_y = 127;
}
All this could be rewritten as one line:

if ((p1_y <= 135 && p1_y >= 127) || (p1_y >= 119 && p1_y <= 127)) p1_y = 127;

[deltacoder1020]

and heck, if readability is your issue, just include the 127 case as well:


if(p1_y >= 119 && p1_y <= 135) p1_y = 127;

[KevinB]

and heck, if readability is your issue, just include the 127 case as well:


if(p1_y >= 119 && p1_y <= 135) p1_y = 127;

Looking back at my statement reminds me of why coding at midnight is bad. :D

[KenWittlief]

I dont understand how putting a deadband around 127 will make the joystick less sensitive

in fact, your bot is going to lurch when the joystick is moved just outside the deadband

dividing the joystick variable by two, and then correcting the zero point by adding 64 - makes the full forward or full right... positions of the joystick equal to half forward, or half right... making the entire motion of the joystick less sensitive

and making it easier to make fine control adjustments to the motion of the machine while driving - ie when you want to manuver to capture a ball, or position the robot precisely on the field.

[IMDWalrus]

My fellow programmers and I have tried many different ways to desensitize our joysticks, but none of ways work very well. Does anyone know a good way to desensitize them?
Expose them to lots of violent movies and video games. :)

[ginger]

I think this is related to the threads on PID and motor feedback. Id look there for the best solution.

I would try a simple average function- keep a bufer of the last 10 or so values, add each new one into the buffer, take the average, and send that value to the motor. Remove the oldest value from the buffer.

This should at least smooth out effects of noise and minor hand jiggles.

[deltacoder1020]

that, or ramp the output - put in a "max change per cycle" function. also, you might try an exponential function for the joystick, so that it really only opens up at full movement.

[WillyC]

I dont understand how putting a deadband around 127 will make the joystick less sensitive

in fact, your bot is going to lurch when the joystick is moved just outside the deadband



I've got to agree with Ken on this one. This deadband approach will make the joysticks more sensitive, because the motor output is proportional to the joystick deflection. If you ignore the stick input unless it's greater than 135 or less than 119, then as the stick moves out of the deadband and starts the motor moving, the motor's smallest non-zero speed is even faster than without the deadband. The result will be jerkiness as the bot starts moving.

Ken's solution sounds good, and is obviously more efficient than what I'm about to suggest here. I haven't tried my idea on the bot yet, and I'm a little sketchy about putting a lookup table of any size into the user routine because I don't want to slow it down too much. But here's the principle: make a slightly non-linear lookup table to de-emphasize the stick input near neutral, but not near the max/min. I've attached an example of the kind of curve I'm thinking of. Notice that near 127, it "dumbs down" the stick input to drive the motors slower and make the sticks less sensitive, but near the high or low end of the input it looks almost linear to make the driveability at high speeds feel pretty normal.

Try it out and let me know what you think! Like I said, I haven't tried this on the bot yet...

EDIT: I just changed the .xls to a zipped up .xls.

[deltacoder1020]

Looking back at my statement reminds me of why coding at midnight is bad. :D

hey, look at the post time on my reply ;)

[WillyC]

hey, look at the post time on my reply ;)

My most productive coding hours are between midnight and 3am, and I can't explain why....yawn....why I'm so tired today... :yikes:

[thoughtful]

That is very helpful file.

What i was thinking is, have a max change function in real-time like you mentioned.

Basically you jus need a variable that holds the current joystick input. For example if your joystick was at 135 and you pushed it to 250 all of a sudden, You can check you current motor output which was 135 and then current joystick input which is 250, now you keep adding a certain number lets say 10 to the motor output untill it reaches 250.

This is one way to do it, the other way is to subtract 250-135, you get 115 devide it by a number lets say 10 so you get 11.5 , now ur max change is 11.5 , add that 10 times to your motor output or until it reaches desired position, this way you will have variable max change function.

[Joe Ross]

I dont understand how putting a deadband around 127 will make the joystick less sensitive

in fact, your bot is going to lurch when the joystick is moved just outside the deadband

But, your robot doesn't move when you give it a small value, because of friction and other factors. In '99 we did some tests with our robot, and you had to give it something to the effect of 145 to get it to move from a stop. So, we programmed in a deadzone from 117-137, and then starting at 138, we scaled the values from 145 to 254.

[WillyC]

But, your robot doesn't move when you give it a small value, because of friction and other factors. In '99 we did some tests with our robot, and you had to give it something to the effect of 145 to get it to move from a stop. So, we programmed in a deadzone from 117-137, and then starting at 138, we scaled the values from 145 to 254.

Ahhh, good point Joe. Note though, that the nonlinear function I gave essentially has that deadband built in (very low response to joystick inputs around neutral), but it's a smooth and continous transition to the "on" state, instead of being abrupt. I guess once the bot is built up and you're testing it to see how much motor output is needed to start moving, you could tailor the transfer function a little to get it to "turn on" at that motor output. The smooth nature of the function takes care of the scaling from that point up to the max.


This is one way to do it, the other way is to subtract 250-135, you get 115 devide it by a number lets say 10 so you get 11.5 , now ur max change is 11.5 , add that 10 times to your motor output or until it reaches desired position, this way you will have variable max change function.

This works too. But I think you should be careful about remembering values from loop to loop and using them to calculate motor output. Suppose you're in the middle of changing the motor output as you suggest, but then the driver suddenly moves the stick full the other way. Now your math might suggest that the max change to the motor is huge, and you might get a big drive current spike as the motor responds. If you're going to do this, just be careful about how you write the calculation so that you don't over-juice the motor.

[Scooter]

What we use is a exponenetial function. This simply shifts the power curve out some while still retaining full power at the edges. Instead of it being completely linear, it follows a curve (that looks suspiciously like a cubic function). At 50% joystick travel, you may only have 33% motor output, but at 100% joystick travel, you have 100% motor output.

Another technique that I learned from flying R/C Heli's is to grip the joystick at the bottom with just a few fingers....This helps to make movements less extreme....they only downside is that it is a little tuffer to get to the buttons...The advantage is that the movement comes from the fingers instead of the arm and wrists, and it affords you alot more accuracy.

Bill

[MichalSkiba]

This is what I came up with during our team's meeting today after school:

/*
pwm is a jostick value, 0-254
pwm_in is the pwm_out of the default code
pwm_out is the new value going to the joysticks
null_zone_swing_fraction is the amount you'd want the joystick to move without the motors kicking in.
*/

pwm_out = (pwm_in / (1-null_zone_swing_fraction)) - null_zone_swing_fraction(1 - null_zone_swing_fraction)

So. Its quite simply a y = mx + b "transfer" function. enjoy.

[MichalSkiba]

Exponential Function: simple sin(x) function:

amplitude = 2 * 127 (pwm max)
period = 4 * 127

make sure, as i forgot to in my previous post (above):

pwm = pwm - 127;

That way the origin is the middle of the null zone. makes for nice calculations.

[Mark McLeod]

But, your robot doesn't move when you give it a small value, because of friction and other factors. In '99 we did some tests with our robot, and you had to give it something to the effect of 145 to get it to move from a stop. So, we programmed in a deadzone from 117-137, and then starting at 138, we scaled the values from 145 to 254.

The motors have gained more power since '99.
The new drills introduced last year have almost no delay at low power values.

The deadstick area is still nice, but you also need to scale the output rather than start at 138.

[Ryan M.]

You could use low pass filter. I'm at school right now and don't have access to what I've written, but I'll try to post it when I get home.

[WillyC]

This is what I love about programming...there are so many different ways to solve the same problem. All of these are nest ideas. Good luck everyone!

[Ryan M.]

I've posted the low pass filter on the white pages. It's called low pass filter. (Duh! :))

An example usage:

...
pwm01 = rampPWM(pwm01, where_we_want_it, 6, 5);
...


Basically, you call this function with what your current speed is, where you want it to be, how fast you want it to get there (higher numbers are faster), and how large you want the dead zone to be (i.e. if the joystick is at 129, you probably want to be at 127. You can set how far from 127 it will be corrected with this param.). It returns what value you should set the PWM to next.

By calling this function multiple times you get a nice gradual increase in output values, so if you move the joystick as fast as you can in circles, very little of that will be picked up. How sensitive it is to input is set by you. The exact equation for finding what to set sensitivity to:
255
-------------- = t
(1000/26.2)*s

t is time in this equation. deterimine what time (in seconds) you think is best for it to be able to go from full reverse to full forward and plug that equation. Solve and use that as your input to the function, ignoring any decimal portion. For instance, if t = 1 sec, then s = 6.

Note that the equation assumes it is being called every 26.2 ms.

Post again if you have any questions about the code or if you'd like to comment on it.

PS I had to re-write it because somebody took my disk that I had that on, so it hasn't been complied. It should be right, though. :)

[Chris Hibner]

Beware of low pass filters. We used an LPF on the joystick once and we decided that we didn't like using it. Under acceleration, it's fine, but under stopping, it's not so good. To make the story short, it will cause you to overshoot (because it ramps down your input just like it ramps it up). You can try some funky "if increasing do this, if decreasing do that" logic, but I really don't think it's worth it.

Also, the deadbands that have been described here are discontinuous deadbands, which are generally considered "hack" deadbands in the controls world (due to their abrupt change at the deadzone point). For a continuous deadzone (more commonly used), do this:

DeadZone = 15; // Calibration parameter
if (Joy > (127-DeadZone) && Joy < (127+DeadZone)) Joy = 127;
else if (Joy <= (127-DeadZone)) Joy += DeadZone;
else Joy -= DeadZone;

[Ryan M.]

Thanks for the warnings.

[bob1million]

I've got to agree with Ken on this one. This deadband approach will make the joysticks more sensitive, because the motor output is proportional to the joystick deflection. If you ignore the stick input unless it's greater than 135 or less than 119, then as the stick moves out of the deadband and starts the motor moving, the motor's smallest non-zero speed is even faster than without the deadband. The result will be jerkiness as the bot starts moving.

Ken's solution sounds good, and is obviously more efficient than what I'm about to suggest here. I haven't tried my idea on the bot yet, and I'm a little sketchy about putting a lookup table of any size into the user routine because I don't want to slow it down too much. But here's the principle: make a slightly non-linear lookup table to de-emphasize the stick input near neutral, but not near the max/min. I've attached an example of the kind of curve I'm thinking of. Notice that near 127, it "dumbs down" the stick input to drive the motors slower and make the sticks less sensitive, but near the high or low end of the input it looks almost linear to make the driveability at high speeds feel pretty normal.

Try it out and let me know what you think! Like I said, I haven't tried this on the bot yet...

EDIT: I just changed the .xls to a zipped up .xls.

This works great on our bot, everyone from SWVGS Maximus thanks you.
We used a switch statement and it did not slow down anything. It is a big improvement from what we had. :)

[phrontist]

We are going to map our joystick input to a function (y=x^3 or something) and then map the output to the motors. We were also considering a recursive approach, such that it finds the delta (change-in joystick postion) and alters accelleration accoordingly.

[WillyC]

This works great on our bot, everyone from SWVGS Maximus thanks you.
We used a switch statement and it did not slow down anything. It is a big improvement from what we had. :)

I'm glad to hear that this helped you guys. We just tested this today and found that it worked really nice. Thanks, good luck.

[squide]

I'm glad to hear that this helped you guys. We just tested this today and found that it worked really nice. Thanks, good luck.

Team 1056 would also like to thank you. We created an array with the values, adjusted the joystick values so they were divisible by five then got the value from the array by dividing by 5.

Would a larger array of 255 members be okay to use, or would it slow the program down?

Thanks!

[Ryan M.]

Team 1056 would also like to thank you. We created an array with the values, adjusted the joystick values so they were divisible by five then got the value from the array by dividing by 5.

Would a larger array of 255 members be okay to use, or would it slow the program down?

Thanks! A large array size won't slow the program down in any noticable way.

[deltacoder1020]

however, you'll probably want to put it in rom, as you only have 1800 bytes of variable space in user memory. just add the keyword "rom" to the list of type modifiers in the declaration.

[m0rph3us]

We are going to map our joystick input to a function (y=x^3 or something) and then map the output to the motors. We were also considering a recursive approach, such that it finds the delta (change-in joystick postion) and alters accelleration accoordingly.

You might want to stay away from recursive functions because they can take up a lot of memory while running making the code less reliable.

[Andy A.]

Hold on a sec folks...

I'm assuming before you've done any of this, you've gone through and recalibrated the Victors with the joysticks you plan on using, right?

Right?

The option to recalibration is really just there because not all joysticks are created equal. The output from one stick to another varies, espically from model to model. By calibrating each victor to the joystick you use, you'll get a smooth, consistent output from it, instead of either:

A: Peaking early (I've seen victors putting out %100 at only half stick), which leads to ultra sensitive sticks

or

B: Never peaking. Which leads to speed and power you never get, just because your stick doesn't let you move the pot that extra bit.

Honestly, calibrate the Victors before you do anything else. I suspect that a great deal of the trouble teams are having with the new sticks is because the victors factory calibration is off from were they 'want' to be with the new sticks.

Check your documentation for the procedure. It takes 30 seconds, and can do only good.

-Andy A.

[Astronouth7303]

Compared to last year's, the new sticks are more seensitive. I think it's because the centering springs aren't as powerful.

[Alan Anderson]

I dont understand how putting a deadband around 127 will make the joystick less sensitive

in fact, your bot is going to lurch when the joystick is moved just outside the deadband.
I think the Victors would mask that effect quite nicely, because they have their own deadband around 127.

[gnormhurst]

I think the Victors would mask that effect quite nicely, because they have their own deadband around 127.

I have found that the Victors do indeed have their own deadband of about +/- 7 that I didn't like, so I wrote code to get around it. I chose my own deadband (+/-2 for example). First I calculate my (smooth) transfer function assuming the Victor has no deadband. Then, when the value is inside MY deadband, I set the output to the center value of the Victor (determined either by experimentation (which is what I did) or by calibration of the Victor (better).

When the value is above my deadband, I add a fixed offset to the value. When it is below my deadband, I subtract a fixed offset. This way the output "jumps" from dead to the first value that causes the Victor to do something. I actually did the process on absolute values and restored the sign at the end.

BTW, I have found that working with signed ints saves a lot of headaches. But you need to be careful when converting back to unsigned char that the value is in the range 0-255!

int speed; // signed motor speed; negative means backwards
int absoluteSpeed; // always positive
int direction; // +1 or -1 (sign of speed)

#define ABS( x ) (x) > 0 ? (x) : (-x)
#define SIGN( x ) (x) > 0 ? (+1) : (-1)
#define VICTOR_CENTER 131
#define VICTOR_DEADBAND 7
#define MY_DEADBAND 2

// ... ( magic transfer function that sets 'speed')

// work around Victor's deadband:
//
absoluteSpeed = ABS ( speed );
direction = SIGN( speed );

if ( absoluteSpeed > MY_DEADBAND )
absoluteSpeed += VICTOR_DEADBAND;
else
absoluteSpeed = 0;

// restore sign and add offset. (Be careful to keep this in range of 0-255!)
pwm13 = (unsigned char) clipInt((absoluteSpeed * direction) + VICTOR_CENTER, 0, 255);



The function clipInt() is:

int clipInt( int in, int low, int high )
{
if ( in > high )
return high;
else if ( in < low )
return low;
else
return in;
}

CAUTION: I wrote all this code manually here (not cut and pasted), so it may have bugs!

[Catastrophy]

I know that people have said what to do, but, I'm new to this and do not understand how to modify the sensitivity. Could anyone please post up the code to desensitize the joysticks and where to put it. Thanks! :D

[deltacoder1020]

there is no specific "the code" - there a plenty of ways to do this. however, I have included an example below - it maps the joystick values to an approximation of an x-squared curve. it's not perfect, and i would probably do it differently if i were putting a ton of effort into it, but this is for an example. it should still be functional though.


const rom signed char JOYSTICK_SMOOTHING[128] =
{
0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 2, 2,
2, 2, 3, 3, 3, 3, 4, 4, 5, 5, 5, 6, 6, 7, 7, 8,
8, 9, 9, 10, 10, 11, 11, 12, 13, 13, 14, 14, 15, 16, 17, 17,
18, 19, 20, 20, 21, 22, 23, 24, 25, 25, 26, 27, 28, 29, 30, 31,
32, 33, 34, 35, 36, 37, 38, 39, 41, 42, 43, 44, 45, 46, 48, 49,
50, 51, 53, 54, 55, 56, 58, 59, 61, 62, 63, 65, 66, 68, 69, 71,
72, 74, 75, 77, 78, 80, 81, 83, 85, 86, 88, 89, 91, 93, 95, 96,
98, 100, 102, 103, 105, 107, 109, 111, 113, 114, 116, 118, 120, 122, 124, 126
};

unsigned char Get_Desensitized_Output(unsigned char input)
{
if(input > 127)
{
return ((unsigned char) (128 + JOYSTICK_SMOOTHING[input - 127]));
{
else
{
return ((unsigned char) (127 - JOYSTICK_SMOOTHING[127 - input]));
}
}

[Ryan M.]

const rom signed char JOYSTICK_SMOOTHING[128] =
{
0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 2, 2,
2, 2, 3, 3, 3, 3, 4, 4, 5, 5, 5, 6, 6, 7, 7, 8,
8, 9, 9, 10, 10, 11, 11, 12, 13, 13, 14, 14, 15, 16, 17, 17,
18, 19, 20, 20, 21, 22, 23, 24, 25, 25, 26, 27, 28, 29, 30, 31,
32, 33, 34, 35, 36, 37, 38, 39, 41, 42, 43, 44, 45, 46, 48, 49,
50, 51, 53, 54, 55, 56, 58, 59, 61, 62, 63, 65, 66, 68, 69, 71,
72, 74, 75, 77, 78, 80, 81, 83, 85, 86, 88, 89, 91, 93, 95, 96,
98, 100, 102, 103, 105, 107, 109, 111, 113, 114, 116, 118, 120, 122, 124, 126
};

unsigned char Get_Desensitized_Output(unsigned char input)
{
if(input > 127)
{
return ((unsigned char) (128 + JOYSTICK_SMOOTHING[input - 127]));
{
else
{
return ((unsigned char) (127 - JOYSTICK_SMOOTHING[127 - input]));
}
}
That's a lot of numbers. :) I like it though.

[deltacoder1020]

That's a lot of numbers. :) I like it though.

yeah - it's a lookup table... gonna have a lot of numbers any way you work it. save you the trouble of typing them in, though :)

[Phil_Lutz]

We are using an array of values.
First we worked out in excel a parabolic equation for all the values from -127 to +127 (with zero as neutral)
Then input the adjusted speed into the array.
It was decided to have the parabola reach linear at about 1/4 throttle/joystick movement.

unsigned int throttle_curve[50] = {value0,value1,......};

then we write a quick little function to take the motor speed in and transform it.


unsigned int adjust_throttle(unsigned int speed_in)
{
int speed_out;
if (speed_in > 104 && speed_in < 150)
speed_out = throttle_curve[speed_in - 104];
else
speed_out = speed_in;
return speed_out;
}

call it like this.

p1y = adjust_throttle(p1y);

The nice part of this setup is that you just adjust array values to flatten or sharpen the curve.

Phil

[Astronouth7303]

Wouldn't a hyperbola work? not the regular kind; try Y=sqrt(R^2+X^2)-R. basically, close to zero, it's a curve, but farther away, it's close to linear. Excel that and try it. But it won't reach maximum value ever. A coefficient would be necesary. R is the value at zero.

[Rhs953]

Take out the set screw in the joystick. It should spin like the wheel on the robobt.



I didn't break it!

[deltacoder1020]

Wouldn't a hyperbola work? not the regular kind; try Y=sqrt(R^2+X^2)-R. basically, close to zero, it's a curve, but farther away, it's close to linear. Excel that and try it. But it won't reach maximum value ever. A coefficient would be necesary. R is the value at zero.

plenty of mathematical forms work, just pick one.

[marccenter]

What we use is a exponenetial function. This simply shifts the power curve out some while still retaining full power at the edges. Instead of it being completely linear, it follows a curve (that looks suspiciously like a cubic function). At 50% joystick travel, you may only have 33% motor output, but at 100% joystick travel, you have 100% motor output.

Another technique that I learned from flying R/C Heli's is to grip the joystick at the bottom with just a few fingers....This helps to make movements less extreme....they only downside is that it is a little tuffer to get to the buttons...The advantage is that the movement comes from the fingers instead of the arm and wrists, and it affords you alot more accuracy.

Bill

I am new to Chief Delphi forum but recommend that you add one more
bit of functionality - a rate limiting function. The exponential curve via
table lookup solves one problem but not the problem of quick changes
in torque. If you use both methods simultaneously, it can help to
solve range/resolution issues associated with Joystick input to pwm0x output,
and torque/speed transitions from positive/negative to negative/positive.

[Gusman1188]

I dont understand how putting a deadband around 127 will make the joystick less sensitive

in fact, your bot is going to lurch when the joystick is moved just outside the deadband

dividing the joystick variable by two, and then correcting the zero point by adding 64 - makes the full forward or full right... positions of the joystick equal to half forward, or half right... making the entire motion of the joystick less sensitive

and making it easier to make fine control adjustments to the motion of the machine while driving - ie when you want to manuver to capture a ball, or position the robot precisely on the field.


Looking back on this post, the reason we did this was because our joysticks didn't stay exactly centered and you would have to re-adjust the trim 85 billion times in a match if we used those joysticks.

[M. Hicken]

im not a fluent programmer. im learning java in class. but our programmer wrote in a zeroing button on the control board after the joysicks being a pain and never going back to zero. big mistake, the joysticks hold a value, i forget what it is, and after a while the values become off due to the mechanics of the stick. The zero button made the robot very hard to drive,if you zero it while its not PERFECT, the handling falls apart.


just sharing an experience

[Astronouth7303]

I am new to Chief Delphi forum but recommend that you add one more
bit of functionality - a rate limiting function. The exponential curve via
table lookup solves one problem but not the problem of quick changes
in torque. If you use both methods simultaneously, it can help to
solve range/resolution issues associated with Joystick input to pwm0x output,
and torque/speed transitions from positive/negative to negative/positive.
In programmer terms? Do you mean a loop to change the speed only so fast?

[scitobor 617]

Looking back on this post, the reason we did this was because our joysticks didn't stay exactly centered and you would have to re-adjust the trim 85 billion times in a match if we used those joysticks.

My team had a similr problem. To correct it I wrote some code that would center the joysticks when a button was pressed. It would consider the current position of the joystick the center. It worked by finding the difference between true center and that position and always adding it to the output for the motors. It worked well on our robot and should not be to hard to edit for your robot.

P.S. If you would like the code PM me. The program was a little rushed so it was a tad buggy, nothing too major, but I'm sure with a little work they can be worked out.

[Mr. Lim]

My fellow programmers and I have tried many different ways to desensitize our joysticks, but none of ways work very well. Does anyone know a good way to desensitize them?

It seems the problem is big enough to cause some serious thread resurrection.

Here was Team 188's solution to sensitive joysticks for 2004 courtesy Carol, Honson, Tristan and myself:



temp_p1_long = (signed long)p1_y - 128;
pwm01 = (unsigned char)(((temp_p1_long * temp_p1_long * temp_p1_long) >> 14) + 128);

temp_p2_long = (signed long)p2_y - 128;
pwm02 = (unsigned char)(((temp_p2_long * temp_p2_long * temp_p2_long) >> 14) + 128);


make sure you declare temp_p1_long and temp_p2_long as signed long beforehand.

In a nutshell, it's a cubic transfer function that makes the robot accelerate exponentially when you push the joystick. There's a nice wide area to operate slowly, yet full speed is still there when you push it all the way.

We spent a few days testing different transfer functions, and this one worked out the best.

It's pretty CPU intensive (multiplying long integers), and a look-up table would be faster, but try it for a quick and dirty way to get things working smoothly. You can generate a look-up based on the code later on.

Cheers!

-SlimBoJones...

[tribotec_ca88]

Absolutely...our team also realized the joysticks provided by FIRST proportionalize poor handling...Don't know if you'd had a look at the white papers on this website yet but team 1382's written one about the advantages of converting the linear curve of the joystick into an exponential one (and includes source code). I guarantee it'll give you some ideas...
Link:
http://www.chiefdelphi.com/forums/papers.php?s=&action=single&paperid=280