Negative numbers?

[Calvin]

Taking in the input as p1_y, and output as pwn01... I'm having some problems.

When the joystick is moved the the direction of "128 - 254" it works, yet when "126 - 0" it starts of to work (motor turning) but then full blast turns the other direction. I do not understand what might be the problem. The Code worked fine in the RoboEmu.

Here is a part of the code

if (p1_y > 127) // This part works
{
pwm01 = (0.007874015748031496062992125984252) * (p1_y - 127) * (p1_y - 127) + 127;
}

else // Does not work
{
pwm01 = (-0.007874015748031496062992125984252) * (p1_y - 127) * (p1_y - 127) + 127;
}

The only differenece it that the 2nd part has " (-0.00787..." a negative number.
Is that the Problem? If not, what am I doing wrong?

[Workaphobia]

You'll find that it's easier to work with the pwm values if at the beginning of your user code you copy the numbers into a signed char, manipulate those, and then at the end translate that back into the unsigned world. This eliminates all this 127 business, so for example you can simply halve your output by dividing by two.
This would look something like "signed char pwm01S = (signed char)pwm01 - 127;".

In the code you posted, it looks like both sections would have problems. You have to take into account two problems with calculations in programming: overflow and round-off error. Even if you know that the final value must fall within the proper range for the type that is expected, the intermediate values may be too extreme. Two chars multiplied by each other is not that safe - what if they're both 255? You get 65025, and even if you subtract 65000 right after that, you still overflowed and get unpredictable results from that point onward in the formula. The solution is to cast to a larger type - instead of "(p1_y - 127) * (p1_y - 127)" it would be "(int)(p1_y - 127) * (p1_y - 127)". The first term is promoted to an integer before multiplication, and the second value is implicitly promoted as well (at least I think; an integer times a smaller value should yield an integer).

Also, since you have a floating point number, you have to make sure it's treated as a float and not an int or char during calculations, using similar casts. Actually, because the float comes first in the formula, you may be in the clear - everything after it might get promoted to a float. I wouldn't be able to tell you without testing it right in front of my face.

To be safe, you can add in redundant casts all over the place for debug purposes. If that doesn't work, add a printf statement that outputs the values at different stages in the calculation, and find out where the discrepancy lies.



Remember that this is an integer processor, and floating point operations are implemented in software. You'll want to avoid calculations in floats when they can be performed using simpler types.

[Alan Anderson]

The joystick inputs are of type unsigned char. Trying to do arithmetic with them that yields negative results (e.g. p1_x - 127 when p1_x is less than 127) is just asking for things to blow up.

I get around the problem by reading the joystick input values into a temporary int first, and do all the computations with that.

[probizzle]

Also,

...
pwm01 = (-0.007874015748031496062992125984252) * (p1_y - 127) * (p1_y - 127) + 127;...

You will notice that

...
((p1_y - 127) * (p1_y - 127) + 127) / 127
...

will work much much better for your purposes. Since pwm01 is an unsigned char and the whole thing will be converted to a char later, it does not matter that you are doing integer division.

Sometimes you have to forget the lessons you're taught so well in Comp Sci.

[Workaphobia]

Originally Posted by probizzle

Since pwm01 is an unsigned char and the whole thing will be converted to a char later, it does not matter that you are doing integer division.

Actually when I said it would partly help him, I meant because it's pretty hard to overflow a float by multiplying integers.

[Calvin]

Thanks for the fast reply, I'll test the revisions tomorrow at school and see if it works.

[Rocketboy]

I used the same exact process to debug my drive protocol. I wrote a "rampPWMs" feature which ramps the output once every loop. Heres the idea (not actual code):

getData

unsigned char driveRobot (motor, joystick, sensitivity){

set joystick = p1_y;
set motor = pwm01;
set sensitivity = 5;

if (the joystick is in the dead zone){
return 127
}

else if (the joystick is NOT in the dead zone){


   if (((joystick + sensitivity)is greater than (the motor value + sensitivity))
   && ((the motor value + sensitivity) < MAX_SPEED){
   // IF we get here the motor is accelerating, and has not reached it's goal
   yet.
   return motor + sensitivity;
   }


   else if (((joystick + sensitivity) is less than (the motor value - sensitivity)) 
   && ((the motor value - sensitivity) > MIN_SPEED){
   // IF we get here the motor is decellerating, and has not reached it's goal
   yet.
   return motor - sensitivity;
   }


   else return joystick // We have reached our goal PWM setting.

}

else FUBAR;

}

As you might see, this function adds a value named "sensitivity" to the "current motor value" each time it goes through the loop until the value is within "range" (joystick +||- sensitivity) of the joystick. As sensitivity increases, the robot will accelerate faster, and vice-versa. I had to cast temporary int types to each variable to keep them from looping around.

The FUBAR case should never occur (where the joystick is neither in the dead zone nor out of it). But if there was a short in the electrical system or something the process could get FUBAR and the robot might do some strange things.

Anyway, I had the same problems you have until I cast in a signed variable type.