Dangerous.....Code problem?!?

[Argoth]

Does anyone know if the code resets after being on for too long? Yesterday, we were working on code for our arm, and one of our engineers was messing with the joystick for the arm (he had it backwards when this happened). The robot suddenly just kicked on full foward until it came crashing into my shin, a full foot away , then it quit! We turned it off and when we turned it on again, our sponsor was leaning over it reactivating the kill switch so the bot could be on again, and it just kicked on again!!!! Our arm scratched our sponsor's neck and then went crashing into MY OTHER SHIN! Soooo now that you know the circumstances, why did it do that .

[tophq]

my only guess would be that maybe the engineer accidentally bumped the trim wheel when he was messing with the controls. i wasn't there so that's all i can think of. sporry about the injury to both of you though.

[Raven_Writer]

Originally Posted by Argoth

Does anyone know if the code resets after being on for too long? Yesterday, we were working on code for our arm, and one of our engineers was messing with the joystick for the arm (he had it backwards when this happened). The robot suddenly just kicked on full foward until it came crashing into my shin, a full foot away , then it quit! We turned it off and when we turned it on again, our sponsor was leaning over it reactivating the kill switch so the bot could be on again, and it just kicked on again!!!! Our arm scratched our sponsor's neck and then went crashing into MY OTHER SHIN! Soooo now that you know the circumstances, why did it do that .

I don't think the code resets itself. Maybe it was because the engineer hit the joystick, and you values were reversed also (so full back on the joystick would go foward). Sorry to hear about that though

[Argoth]

I too would say that the engineer bumped the joystick, except we didn't have either joystick plugged into the first or second port. (we are running our bot of two joysticks) We had them plugged into port three and four because we havent gotton the two new ones we ordered yet. We were watching our victors and no signal was going to the victors controlling the motors(the signals were going to the victors controling the arm ).

[Raven_Writer]

Maybe something screwy happened in the code maybe?

[seanwitte]

The simple answer is to put the robot on blocks until you've debugged the control system.

[Adam Y.]

It may be the WDT or the Watchdog Timer. It actually resets the pic microcontroller if WDT is not reset after a specific amount of time. That is the only thing I could think of that can reset the PIC. Though I don't even know if that specific PIC contains it.

[Argoth]

Originally Posted by Adam Y.

It may be the WDT or the Watchdog Timer. It actually resets the pic microcontroller if WDT is not reset after a specific amount of time. That is the only thing I could think of that can reset the PIC. Though I don't even know if that specific PIC contains it.

I will look into that and see if that is what happened. (My shins thank you very much.) I am not keen on having that thing come charging at me again!

[Phil_Lutz]

1. Trace the code.
2. You need to ensure that the controls are being neutralized on start.
3. Are you jumping into auton mode? shorts, etc.

Before we switch the breaker on our bor, we tell everyone in a loud voice, Stand clear, Robot starting up.

Only one person near the robot during fire-up.
Only one person near joysticks/oi controls (to ensure no knocking of controls) Activate breaker in a 'safe' position.
(no ties hanging down, hand not in treads zone, not in front of bot, etc.)

To quote a motto (I think OSHA), "Safety is no accident"

Phil

[Adam Y.]

Only one person near the robot during fire-up.

Also make sure the robot is off before you stick your fingers in it. Yeah you can imagine what happened.

[steven114]

From the chip docs:

PIC18F6520/8520/6620/8620/6720/8720
3.0 RESET
The PIC18FXX20 devices differentiate between
various kinds of Reset:
a) Power-on Reset (POR)
b) MCLR Reset during normal operation
c) MCLR Reset during Sleep
d) Watchdog Timer (WDT) Reset (during normal
operation)
e) Programmable Brown-out Reset (PBOR)
f) RESET Instruction
g) Stack Full Reset
h) Stack Underflow Reset
Most registers are unaffected by a Reset. Their status
is unknown on POR and unchanged by all other
Resets. The other registers are forced to a “Reset
state” on Power-on Reset, MCLR, WDT Reset, Brownout
Reset, MCLR Reset during Sleep and by the
RESET instruction.
Most registers are not affected by a WDT wake-up,
since this is viewed as the resumption of normal
operation. Status bits from the RCON register, RI, TO,
PD, POR and BOR, are set or cleared differently in
different Reset situations, as indicated in Table 3-2.
These bits are used in software to determine the nature
of the Reset. See Table 3-3 for a full description of the
Reset states of all registers.
A simplified block diagram of the On-Chip Reset Circuit
is shown in Figure 3-1.
The Enhanced MCU devices have a MCLR noise filter
in the MCLR Reset path. The filter will detect and
ignore small pulses. The MCLR pin is not driven low by
any internal Resets, including the WDT.

Looks like the most likely reasons (assuming of course that it is actually a reset, which it might not be) would be the stack over/underflow resets. Are you doing anything funny in assembly?

[KenWittlief]

I cant remember what the joysticks do when nothing is connected - logically it must default to 0 or 254? Im sure it defaults to something, but to depend on that with a live machine online is a little risky.

Whenever we powerup our bot on the cart, or on the floor while we are messing with it, we always chock the wheels

and pull the fuse on the compressor with the pressure release valve open.

[Joe Ross]

Originally Posted by KenWittlief

I cant remember what the joysticks do when nothing is connected - logically it must default to 0 or 254? Im sure it defaults to something, but to depend on that with a live machine online is a little risky.

They default to 127. It is covered in this thread: http://www.chiefdelphi.com/forums/sh...ad.php?t=24813

[KenWittlief]

right the OI output defaults to 127 when it detects infinite impedance on the joystick input

but infinite impedance on an input makes it very susceptable to noise or glitches.

[velocipenguin]

I'm not sure if the IFI initialization routines disable it or not, but the watchdog timer would reset the microcontroller after a certain amount of time, which could cause problems like those you're describing. If you want to make sure that's not the problem, read the 18F8520's datasheet to figure out how to disable the WDT, and toss the necessary assembler code into your program.