For our previous robots, we've been implementing variable speed for the drive motors by using the wheel on the player one joystick. Since we took a break from FIRST last year, we did not have a chance to convert our pbasic code for the variable speed to C. When we tried, the "robot" (platform with wheels) did not follow the code at all. What happened was when p1_y became greater than 147, p1_y, pwm13, pwm 15, and p1_x all became 127 no matter where the joystick was positioned. The same happened when p1_y became less than 107. Is the algorithm to calculated the new p1_y too complex?

Could someone look at our interpretation of the code and help us find our problem? Any help would be much appreciated, thanks!

This is using integer arithmetic. The division by 254 gives an intermediate result of zero, so the final answer is always 127.

You need to either a) force floating point arithmetic by dividing by 254.0, or b) scale the intermediate calculations up by multiplying by a constant (e.g. 256) first and dividing by the same constant just before adding the 127.

doy

01-12-2005, 11:46 AM

and for what its worth, sticking with integer division is almost always the best choice... floating point division on this processor is surprisingly slow, having no fpu.

Matt Leese

01-12-2005, 12:15 PM

This is using integer arithmetic. The division by 254 gives an intermediate result of zero, so the final answer is always 127.

You need to either a) force floating point arithmetic by dividing by 254.0, or b) scale the intermediate calculations up by multiplying by a constant (e.g. 256) first and dividing by the same constant just before adding the 127.
The multiplication by p1_wheel should happen first by order of operations (left-to-right). You could try adding parenthesis around the (p1_wheel)*(p1_y - 127) part and that may fix it. My other thought is that you may be doing 8-bit arithmetic and not 16-bit arithmetic. You might want to move p1_y and p1_wheel into int's first so that it's guaranteed to be 16-bit arithmetic and not 8-bit.

Matt

cabbagekid2

01-12-2005, 12:17 PM

This is using integer arithmetic. The division by 254 gives an intermediate result of zero, so the final answer is always 127.

You need to either a) force floating point arithmetic by dividing by 254.0, or b) scale the intermediate calculations up by multiplying by a constant (e.g. 256) first and dividing by the same constant just before adding the 127.

So would this be the same if I just added parenthesis and changed the formula to this:

The multiplication by p1_wheel should happen first by order of operations (left-to-right). You could try adding parenthesis around the (p1_wheel)*(p1_y - 127) part and that may fix it. My other thought is that you may be doing 8-bit arithmetic and not 16-bit arithmetic. You might want to move p1_y and p1_wheel into int's first so that it's guaranteed to be 16-bit arithmetic and not 8-bit.

Matt

That was one of our thoughts about the problem....that it was doing the calculation and somehow losing the number. We didn't know how to solve this problem though. Thanks for the suggestion. We'll try creating new 16-bit variables and try this again.