Fried program slots?
 

We were doing some autonomous mode testing with our 2002 robot yesterday, and ran into some major problems with our robot controller. We were trying to make a multi-slot program, and when we did, the robot went berserk.

It started last weekend, when we were doing some other auto mode testing. Whenever we removed the program cable after downloading a program, all the motors and pneumatics started randomly turning on and off. Shutting off the bot fixed the problem.

Other than that, everything worked fine until we tried to change program slots. When we loaded our multi-slot auto program, and used our dongle to start auto mode, the robot went crazy for about three seconds, then died.

Subsequent testing showed that numerous program slots were corrupted, and would return bad data when we tried to use them. This got worse and worse with each test, until the RC finally refused to communicate with our laptop.

Does anyone have any idea what would cause these problems? All of our single-slot programs worked fine, but multi-slot programs caused problems every time.

More detail...
 

I'm on Jeff's team, and wanted to add a little bit of detail I feel relevant.

Before we started having multi-slot programming, we did have a few problems.

- When we tried to upload a program, the BASIC stamp would sometimes refuse to communicate. We had loopback and echo from the program port, but it would not give in ID or accept a program. When we unplugged after this happened, all the motors and relays went completely random.

- Occaisonally, the p1_y axis, which should be linked with our drive system, took the place of p3_y, which controlled an arm. Input from p3_y was ignored. This was corrected by resetting the robot.

- Once or twice, I heard / saw one of the arm actuators randomly move, even when the robot was in disable.

After attempting to load a multi-bank program, it ran until the RUN statement and then stopped. We had made a bunch of different autonomous programs, and we were trying to load each of them into their own bank and then use the selector switch to run them. Code looked something like this:

if auton_mode = 1 then
if (Prog = 1) AND (Side = 1) then RUN 1
if (Prog = 1) AND (Side = 0) then RUN 2
if (Prog = 2) AND (Side = ....
endif

'Code to get the input from the OI while in disable

I know that the correct RUN command was being executed through output provided by DEBUG statements.

Later, I wrote a program that looked like this:

a.bsx (slot 0)
DEBUG "a"
RUN 1

b.bsx (slot 1)
DEBUG "b"
RUN 2

c.bsx (slot 2)
DEBUG "c"

It ran fine on an older bot (2000), but on our 2001 bot all it outputted "abc" the first time, but if I did the reset button it outputted a plus-or-minus sign, than a superscript 2 followed by a superscript 3. Turning the RC off for a minute and turning it back on would yield "abc" the first time, and then would result in plus-minus to the 23 when we pressed the reset button.

Also, I noticed that sometimes I would have to download the program into the computer multiple times. WIth a 3 bank program (0-2) slots 0 and 2 would go to 100%, but 1 would remain at 0% on the download status screen.

One thought that I have (Jeff doesn't agree) is that we noticed that our battery voltage was 13.8V coming into the RC. Is it possible that the RC is overclocked? The warning level on my computer for a 12V current is 8% off, and we're running about twice that.

One reason I'm inclined to think that it may be overclocked is that all of the problems we're having can be linked to memory corruption. When one overclocks a computer or runs the voltage a bit hot, the first thing to go wrong is usually for the computer to give "Access violation" errors, where the computer goes looking for RAM that it doesn't have, or can't reliably access that RAM. If anyone has eer seen a poorly overclocked video card, while playing games it tends to flicker and the textures are corrupted since the address the game asked for wasn't the address it got.

On Monday, I plan to take a poorly charged battery and hook it up to see if we get the same errors.

Does anyone have any ideas? Does the overclocking theory sound reasonable? If so, what can we do about it?

umm.. remember, you still have to have serin's/serouts in multi-slot proggies.. which means declare your varibles and etc.

basically.. each different file in each slot has to have its own varibles and serin's and serouts and etc. of course you probably did this.. but who knows?

lol.. that message wasn't there when i posted.. oh well.. ignore me

We were having issues with our robot going berserk too, but we wern't using multi slot programs. Make sure you never output 255 to a PWM. It makes the robot go crazy, and some very odd (and hard to trace) things start happening. IE. We outputed 0 to both relay banks. If the PWM output was set to 255, the relays would randomly turn on anyways.

If you look at the test code (the a-, b-, c-, .bsx) you can see that it program has nothing to do with serin's, serout's, or variables.

We did have all of our variables, ser-ins and ser-outs present. All of the programs could have been loaded into slot 0 and they ran fine.

One question. Have you upgraded the RC and OI? This would be required to do autonomous mode on last years equipment.

Tim Tedrow

What do you mean by upgrading it?

Anyways, we tested the same program on the 2001 RC, and had no problems. I'm thinking that there was some sort of hardware fault with our 2002 RC.

Last years RC and OI do not have autonomous mode operation capability. Do not use the three switch dongle on last years controller. Check out the Innovation First WEB site for upgrade information.

Tim Tedrow

Really? Where is this information? I've never seen that anywhere. I was under the impression that Auto mode was just a software thing (PB bit mode 6, or something like that).

The official Innovation FIRST answer is that the 2003 controller supports autonomous, and if you get the 2002 controller upgraded, it will also support autonomous. But through the course of our testing we used old robot controllers and were surprised to see that they worked in autonomous mode. IFI may have modified the firmware somehow, but the old controllers certainly run autonomous code. As Jeff said, the auton_mode flag is just a bit in PB_mode and that bit is set correctly in older controllers.

Just be warned that since autonomous isn't officially supported in older controllers, you may see unexpected behavior.

Thanks for the clarification, Mike. That was what I was thinking. I'm thinking the problems were some sort of hardware fault, though. We had problems with that same control system at Nats last year, and this may be part of the same defect.

Multi-Slot Problems
 

Yeah, Sachiel7 from 1132 here.
I just got the info for Multi-Slot Proggin' yesterday.
I've been trying a few things, but I seem to have a few problems:

1) Here's My Slot Layout:

0: Init
1: Main
2: Auto1
3: Auto2
4: Auto3
5: Auto4
6: Auto5
7: Auto6

Ok, Init and Main routines work fine until... Auto!
It seems that I have come to 2 conclusions:
1: The Run statements aren't working properly
2: The Autonomous trigger isn't working properly

We have a 2 switch dongle, w/ disable and Auto.
I'm not sure what the problem is, but if anyone can help, please let me know!

Any chance that you didn't have the exact same variable declarations in all of the slots. Remeber that you don't have a separate 26 variables in each slot they are all the same, if they are declared at all differently in any of the slots, the same section in memory may show up as something different as you go from slot to slot. For example if one slot had this

p1_x VAR byte 'Port 1, X-axis on Joystick
'p2_x VAR byte 'Port 2, X-axis on Joystick UNUSED
'p3_x VAR byte 'Port 3, X-axis on Joystick UNUSED
'p4_x VAR byte 'Port 4, X-axis on Joystick UNUSED

p1_y VAR byte 'Port 1, Y-axis on Joystick
'p2_y VAR byte 'Port 2, Y-axis on Joystick UNUSED
p3_y VAR byte 'Port 3, Y-axis on Joystick UNUSED
'p4_y VAR byte 'Port 4, Y-axis on Joystick UNUSED

And another slot had this
p1_x VAR byte 'Port 1, X-axis on Joystick
p2_x VAR byte 'Port 2, X-axis on Joystick
'p3_x VAR byte 'Port 3, X-axis on Joystick UNUSED
'p4_x VAR byte 'Port 4, X-axis on Joystick UNUSED

p1_y VAR byte 'Port 1, Y-axis on Joystick
'p2_y VAR byte 'Port 2, Y-axis on Joystick UNUSED
p3_y VAR byte 'Port 3, Y-axis on Joystick UNUSED
'p4_y VAR byte 'Port 4, Y-axis on Joystick UNUSED

In memory p2_x would have the same location as p1_y in the first slot. Try it, it might suprise you!

We take the entire memory declaration section and copy it exactly to each slot so this can't happen. We have never had any problems with any controllers and multiple slots.

I can post more info if anyone doesn't get what I am saying.

What Matt said is very important. One of the problems we rean into was with delta_t. It was being defined in the same spot os one of our analog sensors, and so instead of sending 0 if it didn't miss a packet, it sent 127. Not good. Variable declaration orderr is absolutely crucial.

One question, though: does the master uP init code need to be in just slot 0, or in all slots?