1 joystick drive
 

Has ne body noticed that the 1 joystick drive default code doesn't work?

*anybody

Which default code do you mean? The only default code I know of is made for two joystick drive.

rbayer, any thoughts?

Adding a jumper to Input 5 on the EduBot should make it switch to one joystick drive, our appears to work.

What exactly do you mean by "doesn't work"?

RoboEmu seems to process it just fine. If you want to try it out, you will need to add eight 127s to the end of the serout to make it the same length as the full RC serout and you will need to add a colon after exit_drive_r_test on line 405 to make RoboEmu recognize it as a label.

Just click the checkbox for sw5 and then play with port 1 to see the changes.

If you want some more help, try the following tests on your robot and let me know what happens. I'm guessing that one of the motors just needs to be reversed or you need to swap which PWM drives each motor. Here's my list of tests:

What happens when you push the joystick straight forwards? straight back?
When you move it all the way to the left? to the right?
In the upper-left corner? Lower-right?

--Rob

it just goes crazy when we close sw5

so it will work if i just add a colon after line 405? I was wondering about that. some places in the code it uses a colon when calling labels and sometimes it doesn't. Please halp i hace never coded pbasic before. im used completely different languages such as PHP, java and C++ and this is a big change.

Also is it possible to divide a byte variable by a decimal and just have the answer rounded?

No. PBASIC knows nothing of decimals. The only division you can do is integer. If you want to round though, you can add 1/2 the divisor to the dividend before dividing. This will insure correct rounding of the quotient.

By the way, it is oft repeated that the BASIC Stamp doesn't handle negative numbers. This is NOT true. It will add, subtract, and multiply negative numbers correctly. IT WILL NOT DIVIDE CORRECTLY, though.

wait so u can store a negative # in a byte var? really!!!

This all comes back to the definition of "handle." Intrinsically, anything using two's complement will "handle" negative numbers by definition. However, until PBASIC can at the very least compare negative and positive numbers using >, <, etc, I'm going to continue believing in the absence of anything less than 0. Ditto on support in Max/Min, etc.



As for the colon thing, it's just a matter of style. Technically, it's not needed following a label, but it makes code easier to read and that stipulation made RoboEmu a LOT easier to write. If you do want to pass EduCode through RoboEmu, don't forget to change the Serout line also. RoboEmu expects 18 bytes after 255,255, but the Edu code only has 10.

Our team has the program written already. The only thing is, we haven't tested it yet so therefore, we don't know if it works or not. Here I have attached the code to our configurations. Tell me if it's correct or not.

Well, if you want to STORE a negative number, you will need to use a WORD variable rather than a BYTE var. My point was that when you're doing calculations, you don't have to be quite as paranoid as some code I've seen.