Negative numbers?

[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.