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 :confused: .

[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]

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 :confused: .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]

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! :D

[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]

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/showthread.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.

[KenWittlief]

Ive never heard of anyones controller doing something all by itself after running for a while - Im talking about running for hours, so I really doubt the PICs watchdog timer is doing something on its own.

One possiblity, if you have an error in your code that causes an infinite loop, or that takes too long to run, the OI link program will disable your outputs (thinking your code is lost in the woods) and that might cause a reset of the OI.

This is starting to sound like CS101 syndrome (my SW is ok, the mainframe is broken! )

most likely there is something in your code that is causing the drive motors to lurch.

[Argoth]

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.

Could you tell me where I could find the 18F8520's data sheet? (sorry I am on a rookie team and don't know where too much stuff is.)

[velocipenguin]

Could you tell me where I could find the 18F8520's data sheet? (sorry I am on a rookie team and don't know where too much stuff is.)

Datasheet: http://www.microchip.com/download/lit/pline/picmicro/families/18fxx20/39609b.pdf

It assumes you're already familiar with assembler programming, though, so it might be kinda difficult to understand.

[Argoth]

Datasheet: http://www.microchip.com/download/lit/pline/picmicro/families/18fxx20/39609b.pdf

It assumes you're already familiar with assembler programming, though, so it might be kinda difficult to understand.

Ummm... so can you change it in the code so that way it wont reset. Or, will that affect the bot preformance?

[Roland]

Our bot did a stack overflow reset the other day when we were testing new autonomous code. This seems like what caused your problem.

[roknjohn]

This may be related, so I'm posting it here. Using the FRC-INTERRUPTS code posted by Kevin, our drive motors (PWM 13 & 15) went crazy (jerking back & forth) whenever we tried to enable a timer interrupt. The interrupt handler only increments a unsigned long.

Today, I'm going to start with a fresh copy of his code and only modify the timer initialization code to pin down the exact problem. If the problem persists, I will post the mods for discussion.

BTW, our two Grayhill 61K128 encoders work fine at ~200 RPM using interrupts (INT1/INT2). But disabling them, doesn't solve the problem.

What I'd like is a timer with a resolution of 0.1 ms or better. My thinking is to have a timer interrupt update a counter every millisecond, then reload the timer register will a value that will roll over again in 1ms. The timer register could be read to calculate the fractional part of the timestamp when needed.

FYI: For safety, we either put our robot on blocks or unplug the PWM cables from the drive motors when powering up the robot in close quarters.

[KenWittlief]

one thing that can make a bot go totally berzerk is if you output 255 on a pwm - 255 is the start of serial data flag, so you must limit your pwm variables so they can never be 255

what happens is the output string restarts when it sees the 255, so the variables you intended to be digital outputs will end up on pwm outputs, and the pwm variables will not be going to the right pwm pins

in other words, the bot goes completely berzerk!

[Phil_Lutz]

Another possible explaination is as you noted in a previous post
" The robot had been running for hours"

Your battery may have lost enough "Juice" to start behaving erratic.
Watch the voltage levels....

Phil

[seanwitte]

Our bot did a stack overflow reset the other day when we were testing new autonomous code. This seems like what caused your problem.

When the stack overflowed did the robot go into a reset state or did it restart? We tested it on the EDUbot by calling a recursive function and we got a blinking red program state.

[seanwitte]

This may be related, so I'm posting it here. Using the FRC-INTERRUPTS code posted by Kevin, our drive motors (PWM 13 & 15) went crazy (jerking back & forth) whenever we tried to enable a timer interrupt. The interrupt handler only increments a unsigned long.

There are two different .lib files from IFI: FRC_Alltimers.lib and FRC_Library.lib. If you use the Generate_Pwms() function you need to use FRC_Library.lib. The Generate_Pwms() function uses timer0 so it is unavailable. If you don't need the extra 4 PWMs then you can use FRC_Alltimers.lib and have access to timer0.