Could someone look this over?

[Ryan M.]

I was wondering if someone could look this over. I think it should work, but when run on the robot it doesn't behave at all the way it is expected to.


In rampPWMs.c:

unsigned char rampPWMs(
unsigned char currentPWM,
unsigned char goalPWM,
unsigned char sensitivity,
unsigned char deadZone)
{
// Check if we want to be within one of the dead zones.
if((127 + deadZone > goalPWM) && (goalPWM > 127 - deadZone))
goalPWM = 127;
if(255 - deadZone < goalPWM)
goalPWM = 255;
if(0 + deadZone > goalPWM)
goalPWM = 0;

// Determine if we have to go up or down to reach our goal
// Note that if we are within 'sensitivity' from the goal
// we don't do anything yet. This prevents us from "jittering" and
// keeps us from exceeding 0 or 255 and looping around.
if(currentPWM >= goalPWM + sensitivity)
return currentPWM - sensitivity;
if(currentPWM <= goalPWM - sensitivity)
return currentPWM + sensitivity;


// If we reach here we are within 'sensitivity' of 'goalPWM'.
// It is now safe to go directly to the goal.
return goalPWM;
}


In user_routines.c, I have used that function like this:

unsigned char tempLeftMotorValue = 0;
unsigned char tempRightMotorValue = 0;

// Determine where the joystick wants us
tempLeftMotorValue = Limit_Mix(2000 + p1_y + p1_x - 127);
tempRightMotorValue = Limit_Mix(2000 + p1_y - p1_x + 127);

// This line ramps the joystick values using a low pass filter with a built-in dead bands/zones
driveMotorLeft = rampPWMs(driveMotorLeft, tempLeftMotorValue, DRIVER_SENSE, DRIVER_DEAD_ZONE);
driveMotorRight = rampPWMs(driveMotorRight, tempRightMotorValue, DRIVER_SENSE, DRIVER_DEAD_ZONE);


The Limit_Mix() lines are taken directly from the default code, so they should work correctly.

driveMotorRight and driveMotorLeft are #defined as pwm01 and pwm02.

If anyone notices any possible errors in that stuff, could they please tell me?

PS You could also tell me that it's perfect and it's all the drivetrain team's fault. :)

[KenWittlief]

in the past putting out a PWM value of 255 would cause your bot to go totally berzerk, casue 255 was used to flag the start of the serial output stream.

Im not sure if thats true with the new controllers, but its somthing to try - set your upper limit to 254.

have you tried putting printF statement in your code, and listing out your variables as it runs, to see what they actaully are?

[Ryan M.]

in the past putting out a PWM value of 255 would cause your bot to go totally berzerk, casue 255 was used to flag the start of the serial output stream.

Im not sure if thats true with the new controllers, but its somthing to try - set your upper limit to 254. Thanks. I'll try changing it to 254. Any other suggestions would be great too, just in case that doesn't help.

[KenWittlief]

oops. I just edited my last post with another idea, go back and check it.

[Ryan M.]

have you tried putting printF statement in your code, and listing out your variables as it runs, to see what they actaully are? I can't figure the printf() out. I am a C/C++ programmer, so I should know what I'm doing, but for unknown reasons, the printf is giving me strange values that are outside the range for an unsigned char.

We have hooked it up to dashboard and it appears to work, but that might have been an older version of the code. I can't remember, people keep stealing the controller to attach it to the control board on the 'bot. I'll have to do it again on Monday.

[KenWittlief]

also this code

__________
if(currentPWM >= goalPWM + sensitivity)
return currentPWM - sensitivity;
if(currentPWM <= goalPWM - sensitivity)
return currentPWM + sensitivity;
__________________________

both IFs can be true when the first IF causes the value to change, then the second one will become true and change it again - I dont think you want that - shouldnt the first IF jump over the second one when its true?

[Ryan M.]

also this code

__________
if(currentPWM >= goalPWM + sensitivity)
return currentPWM - sensitivity;
if(currentPWM <= goalPWM - sensitivity)
return currentPWM + sensitivity;
__________________________

both IFs can be true when the first IF causes the value to change, then the second one will become true and change it again - I dont think you want that - shouldnt the first IF jump over the second one when its true? We return after one of them is true, so it doesn't matter.

[KenWittlief]

if the printf is producing something you dont expect, its not the printf function thats faulty :c)

when your code is not doing what you think it should be, then something IS wrong in there - so if you printf out a variable and its not what you think should be there, then you have found at least one thing that is wrong in your code.

[Ryan M.]

if the printf is producing something you dont expect, its not the printf statement thats faulty :c) I know, I just can't quite figure it out. :) I'll have to play with it some, oh, wait, as I was sitting here I just got an idea. It might not be doing the conversion from a unsigned char to an int correctly. Maybe an explicit cast will help... :):)

As I said in a previous edited post, we have used dashboard on it and it appeared to work then, but I'm not sure about the version I was using. Thanks for your help.

[Joe Ross]

It might not be doing the conversion from a unsigned char to an int correctly. Maybe an explicit cast will help... :):)

That is exactly the problem and the solution.

[Ryan M.]

Yes! :):):):)

PS Excessive celebration, 5 yard penalty.

Any more suggestions appreciated. Thanks

[Joe Ross]

if(currentPWM >= goalPWM + sensitivity)
return currentPWM - sensitivity;
if(currentPWM <= goalPWM - sensitivity)
return currentPWM + sensitivity;

Since everything is an unsigned char, then this code is a problem.
If goalPWM is 254 and sensitivity is 10 and CurrentPWM is 127, the result of (goalPWM + sensitivity) is 8 and so CurrentPWM is greater then 8 and you return 117 not 137 like you hope.

[Ryan M.]

if(currentPWM >= goalPWM + sensitivity)
return currentPWM - sensitivity;
if(currentPWM <= goalPWM - sensitivity)
return currentPWM + sensitivity;

Since everything is an unsigned char, then this code is a problem.
If goalPWM is 254 and sensitivity is 10 and CurrentPWM is 127, the result of (goalPWM + sensitivity) is 8 and so CurrentPWM is greater then 8 and you return 117 not 137 like you hope. Yep, that will be the problem I'm sure. I'll just add a few extra tests for the extreme cases. (wanting to be at 0 and 254)

And the funny thing is, I had already paritially taken looping around into acount in the code.