Mystery problem: exponential drive

[ida_noeman]

Hi FIRST community. We decided to try out scaling our joysticks so that small, exact changes could be made using the middle parts of the joystick. To do this we used an exponential function model. We decided to use a lookup talbe, because we figured we had plenty of space, and we weren't sure whether the processor could do 4 of the calculations each loop without skipping a beat. However, the joysticks did not follow the model, as putting the joysticks full forward had the motors at stop, in addition to the middle and full back. The motors would only run when the joystick was not full forward, backward, or in the middle.
Anybody have any idea why? Is it fixable?
Thanks in advance.

--
Lemma 1: MOTOR_LEFT, JOY_LEFT are pound defined to you know what and DEAD_ZONE is to fix trim issues, by making some defined number (x2) of middle values of the joystick 127.
Lemma 2: "IN_DEAD_ZONE" is
#define IN_DEAD_ZONE(x) (x <= DEAD_ZONE + STOP && x>= STOP - DEAD_ZONE)
--

(At the beginning of user_routines.c)

rom const unsigned char [] lookup = {0, 4, 7, 10, 13, 16, 19, 22, 25, 28, 31, 33, 36, 38, 41, 43, 45, 48, 50, 52, 54, 56, 58, 60, 62, 63, 65, 67, 68, 70, 72, 73, 75, 76, 77, 79, 80, 81, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 99, 100, 101, 101, 102, 103, 104, 104, 105, 105, 106, 107, 107, 108, 108, 109, 109, 110, 110, 111, 111, 112, 112, 112, 113, 113, 114, 114, 114, 115, 115, 115, 116, 116, 116, 116, 117, 117, 117, 118, 118, 118, 118, 119, 119, 119, 119, 119, 120, 120, 120, 120, 120, 121, 121, 121, 121, 121, 121, 122, 122, 122, 122, 122, 122, 122, 123, 123, 123, 123, 123, 127, 127, 131, 131, 131, 131, 131, 131, 132, 132, 132, 132, 132, 132, 132, 133, 133, 133, 133, 133, 133, 134, 134, 134, 134, 134, 135, 135, 135, 135, 135, 136, 136, 136, 136, 137, 137, 137, 138, 138, 138, 138, 139, 139, 139, 140, 140, 140, 141, 141, 142, 142, 142, 143, 143, 144, 144, 145, 145, 146, 146, 147, 147, 148, 149, 149, 150, 150, 151, 152, 153, 153, 154, 155, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 173, 174, 175, 177, 178, 179, 181, 182, 184, 186, 187, 189, 191, 192, 194, 196, 198, 200, 202, 204, 206, 209, 211, 213, 216, 218, 221, 223, 226, 229, 232, 235, 238, 241, 244, 247, 250, 254,};

(later, when assigning joysticks)

if (IN_DEAD_ZONE(JOY_LEFT))
            JOY_LEFT = STOP;
else
            JOY_LEFT = lookup[JOY_LEFT];

(etc for the rest of them.)

LEFT_MOTOR = JOY_LEFT

(etc.)


P.S. The reason that it jumps from 127 to 131 and 123 on each side is so we can adjust our deadzone to whatever we want, but then have a minimum output for the motor, something that will be detectable if we're not calibrated.

[Mark McLeod]

Did you cut & paste directly from the code?
You have a syntax error at the end of your lookup table declaration.

DEAD_ZONE + STOP
and
STOP - DEAD_ZONE
need parentheses.

[6600gt]

You guys should watch what values are going to the pwms based on where the joystick is...use the printfs.

[Jake M]

I'd say, if anything, there's a problem with how your logic string in IN_DEAD_ZONE() is being evaluated (use parenthases), or there's some other, small part of code somewhere else you don't know about, that's messing with those outputs. There might be something else modifying LEFT_MOTOR, after you set it to JOY_LEFT, and that would be overwriting everything.

[ida_noeman]

Urm, we're actually using a method for deadzone, sorry 'bout that:

unsigned char Deadzone(unsigned char x) {
    if ( (x <= (STOP + DEADZONE)) && (x >= (STOP - DEADZONE)) )
        return STOP;
    else
        return x;
}

[Joel J]

What I like about a second or third order exponential, is that a deadband is included automatically. When I use an exponential on a drive, I usually comment out the deadband code, and let the function to the work. But then again, I just do something along the lines of "variable = SGN(variable)*variable*variable/127;" I don't use a LUT. Maybe if I wanted something a bit more specific? I understand the multiplications and divide chew up time, but bah!

[ida_noeman]

Originally Posted by Joel J.

What I like about a second or third order exponential, is that a deadband is included automatically.

I think you're mistaking 'exponential' for 'polynomial'.
The thing about a cubic function is that all but the center of the joystick will provide some power, but for most of it, not enough to get it moving.
That's why I used two exponentials and a dead zone.

[ida_noeman]

OK!!! So... it looks like that old inline function was the thing that was messing it up!

It works now. Feel free to copy the code and use it yourself (if that's within the bounds of the rules)

[Joel J]

Well, the code example I provided (and have usually used) is an x^2 exponential. I dropped my exponential equation into MATLAB, and verified that it gives a deadband of about 11 in the positive direction, and about 12 in the negative direction, which is about what I normally use as a deadband (10 in either direction).

[Joel J]

Ok, I saw your PM.. x^2 is a polynomial . I guess I can't use the term exponential control.