tank drive
 

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 ;) )

Re: tank drive
 

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

Re: tank drive
 

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

Re: tank drive
 

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

Re: tank drive
 

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

Re: tank drive
 

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.

Re: tank drive
 

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.

Re: tank drive
 

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.

Re: tank drive
 

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

Re: tank drive
 

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

Re: tank drive
 

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)

Re: tank drive
 

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.