tank drive

[Stormhammer]

just wondering if anyone has or knows of a site that has the programming code for a single joystick tank drive... if not, can someone give us an example one ( preferably one that worked )

[Joe Ross]

see line 224 of the user_routines.c in the default code

[Stormhammer]

Originally Posted by Joe Ross

see line 224 of the user_routines.c in the default code

your gonna have to explain that. The guy thats programming is a new guy on the team, he knows C and that, but yeah, just want to make sure there aren't any confusions anywhere. Thanks

[Astronouth7303]

Originally Posted by Stormhammer

your gonna have to explain that. The guy thats programming is a new guy on the team, he knows C and that, but yeah, just want to make sure there aren't any confusions anywhere. Thanks

void Default_Routine(void)

void Default_Routine(void)
{
//...
 /*---------- 1 Joystick Drive --------------------------
  *----------------------------------------------------
  *  This code mixes the Y and X axis on Port 1 to allow one joystick drive. 
  *  Joystick forward  = Robot forward
  *  Joystick backward = Robot backward
  *  Joystick right    = Robot rotates right
  *  Joystick left     = Robot rotates left
  *  Connect the right drive motors to PWM13 and/or PWM14 on the RC.
  *  Connect the left  drive motors to PWM15 and/or PWM16 on the RC.
  */  
  pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);
  pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127);
//...
}

Of course, my thought is to use X for left and Y for right. But that's counter-intuitve. Really counter-intuitive

[Larry Barello]

Another way to think of this is to convert the IFI joystick values into signed values (e.g. -127 to 127) then simple math to mix, then simple math to limit and finally simple math to convert back to 0-255 for the Victor. The IFI example code was lifted right out of the Pbasic code from last year. Pbasic didn't understand negative numbers (it was truely wretched...) hence the bizzare mixing code.
-------

char limit(int val)
{
if (val > 127) return 127;
if (val < -127) return -127;
return val;
}

void user_routine(void)
{
int Left = p1_y - 127; // Convert to signed #
int Right = p1_x - 127;

pwm01 = limit (Left + Right) + 127;
pwm02 = limit(Left - Right) + 127;

etc.
}

[Astronouth7303]

Speaking of each, what is the difference in storage between signed and unsigned? is it if bit1=true then # is negetive, or is it an offset, like (Signed) 0=(unsigned) 127, as an example.

[Larry Barello]

Signed math just tells the compiler to interpret the bits differently. Internally the CPU uses something called 2-complement to represent the negative numbers. A number in 2-complement form can be added to another number and you will get the right results without any special hardware. However, you can't generate a 2-complement number by simply flipping the sign bit (bit 8). For example: 0x01 2-complement is 0xFF. 0xFF is 255 in unsigned math.

So, to represent a negative 5 in binary, you would complement 00000101 to get 11111010 then add one to get 11111011

So, add -5 and, say, 7 (in binary):

11111011
00000111
---------
100000010

The 9th bit falls off the end of the earth (or into the "carry" bit) and the resulting number is just 2. When adding larger numbers (int, short long and long) the bytes are added sequentially and the carry from the previous add is added into the first bit of the next.

When converting shorter to longer (e.g. a byte to an int) you simply copy the 8th bit into all bits of the next higher byte and the value is preserved. This is all done for you by the compiler.

[Astronouth7303]

so 5 = 00000101 and -5 = !5 + 1 = 11111011
Or did I mis-read that?

I'm just curious, so one has a vague idea what happens if you pass a signed to a unsigned.

[Random Dude]

Originally Posted by Astronouth7303

so 5 = 00000101 and -5 = !5 + 1 = 11111011
Or did I mis-read that?

I'm just curious, so one has a vague idea what happens if you pass a signed to a unsigned.

Well, if you do something like this


unsigned char u_char;
signed char s_char;

.....

u_char = s_char;



The maping will be as follows:

s_char >= 0 : u_char = s_char
s_char <0 : u_char = 256 - s_char


Hope that answers your question... (Note I'm speaking in terms of this micro and this compiler, YMMV on other systems...)

[JoshJ]

Speaking of programming tank drives, ours threw me for a loop tonight. We had run last saturday w/o problems, and then tonight, our x and y values got switched. basically, to drive straight, we had to move the stick left or right, and to turn move it up or down. To fix it, i just changed the order in the default program for one stick mixing. Does anyone know what caused this/ how to fix it? Im lost, thanks.
-Josh

[deltacoder1020]

did one of your motors have its polarity reversed? that would cause the exact problem you are experiencing. (it happened the first time we tested the bot, we switched the polarity of one motor, which fixed it)

[JoshJ]

Originally Posted by deltacoder1020

did one of your motors have its polarity reversed? that would cause the exact problem you are experiencing. (it happened the first time we tested the bot, we switched the polarity of one motor, which fixed it)

Thanks for the quick response. Actually that also happened the first time we ran, but we changed polarity, not code. Ill check and see if someone switched it again.