Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code problem?!?
 

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.

Re: Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code problem?!?
 

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 ).

Re: Dangerous.....Code problem?!?
 

Maybe something screwy happened in the code maybe?

Re: Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code problem?!?
 

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.

Re: Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code problem?!?
 

From the chip docs:
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?

Re: Dangerous.....Code problem?!?
 

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.

Re: Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code problem?!?
 

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.

Re: Dangerous.....Code problem?!?
 

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.

Re: Dangerous.....Code problem?!?
 

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.

Re: Dangerous.....Code problem?!?
 

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.)

Re: Dangerous.....Code problem?!?
 

Datasheet: http://www.microchip.com/download/li...x20/39609b.pdf

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

Re: Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code problem?!?
 

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.

Re: Dangerous.....Code problem?!?
 

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!

Re: Dangerous.....Code problem?!?
 

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

Re: Dangerous.....Code 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.

Re: Dangerous.....Code problem?!?
 

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.