RoboEmu 1.07

Technical Programming
1

Well, I just finished version 1.07 of RoboEmu, and it includes some fairly substantial changes.

First, relay and PWM outputs are now both graphical instead of just text-based. The sliders also work a little better if you click somewhere in the middle of them.

The big difference, though, is that you can now see the output of the eight LEDs (out8-out15) in the Output Window. I also fixed the debug window, which didn’t scroll properly after 4096 characters.

As always, it’s available in the whitepapers (called RoboTools) or at http://FIRSTprograms.tripod.com/Programs.htm.

Please let me know what you think of the changes, either in a reply here, or PM/email me.

–Rob

2

Does your program make proper accomodations for integer math and byte overflow?

I’ve been having trouble with a bit of code that I wrote for a throttle. When placed on the robot, it does not work at all. When placed in RoboEmu, it works just as I expected. There must be some difference between the PC emulator and the PBASIC chip that I’m not noticing. The weird part is that it works on the emulator and not on the robot (instead of the other way around). Any help?

The code is as follows:

LDRILL = ((LDRILL * p1_wheel) / 255) + ((255 - p1_wheel) / 2)
RDRILL = ((RDRILL * p1_wheel) / 255) + ((255 - p1_wheel) / 2)

LDRILL and RDRILL are both variables of byte length.

3

In theory, everything is correctly incorrect. However, I’m not sure how perfect it really is. Anyway, what exactly do you mean by “does not work at all”? Does the BASIC error light come on, or does it just not move? In either case, have you tried doing a debug on LDRILL and RDRILL?

As soon as InnovationFIRST actually follows through with a deadline and posts the documents for this year, I’m going to sit down and re-write RoboEmu and RoboGUI to reflect whatever changes (if any) they make. I’ll take a closer look at the overflow issues at that point.

–Rob

4

Theoretically, there would be no overflow since 65025 [the largest value that would turn up in the code] is within the 65535 bit space. Alas, that does not appear to be.

I have not made specific records of the bug, but I recall that the motor outputs would move to 127 only if I pulled the joystick all the way back (p1_y = 0). The LDRILL and RDRILL variables are simply outputs from the regular one-joystick tank drive code. If the joystick is centered or pushed forward, the wheels spin at maximum speed forward. The output seems to be wired to the status of p1_wheel, since I can dial that down to 0, and the wheels would stabilize at 127 again.

Once I return to the lab on Tuesday, I can make detailed records of the PWM values that come out for a given input. Perhaps that will yield a more fruitful investigation.