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):
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.