Watchdog!?!?!?!

[NC GEARS]

Ok, so about 3-4 times during the match at Traverse City, MI we got this error on the driver station computer (the little blue box) Usually is says Disabled or Enabled, but those few times it said WATCHDOG. WHAT THE HECK IS WATCHDOG!?!?!?! We had to sit there the whole match til we learned how to do the remote reset from the computer during the match the last time it happened. So anyone have ANY info on this? I have no idea what it is, our programer doesnt either. help please! thanks

[keehun]

I am not an expert on the watchdog, but what I do know is that you have to feed it, and feed it constantly. If the watchdog is not fed, the system is interrupted and you can't do anything. This is meant to observe a never-ending while loop and "hangs"

I am probably half wrong, so correct me. =] This is my learning experience, too.

[EricVanWyk]

Originally Posted by keehun

I am probably half wrong, so correct me. =] This is my learning experience, too.

Nope, you got it right.

As keehan indicated, The watchdog is a safety feature that fail-safes the robot by shutting down all actuators when it isn't happy. Keep it happy by feeding it at regular intervals. This protects you when code hangs.

One common watchdog source is putting slow camera code in your fast drive code.

[ozrien]

I have seen a similar issue on Team 2022's robot where their auton would cause the watchdog message. This was caused by their labview implemenation to tight-loop which prevented the watchdog from being fed. Basically your program should "feed" the watchdog periodically so that if your program does something bad and "hangs" it will fail to feed the watchdog thus causing a timeout which will halt your motors. Are you using labview or windriver?

[NoahTheBoa]

Originally Posted by ozrien

I have seen a similar issue on Team 2022's robot where their auton would cause the watchdog message. This was caused by their labview implemenation to tight-loop which prevented the watchdog from being fed. Basically your program should "feed" the watchdog periodically so that if your program does something bad and "hangs" it will fail to feed the watchdog thus causing a timeout which will halt your motors. Are you using labview or windriver?

We had several code issues at GSR and it didn't help that we traveled without a programmer. Our autonomous mode prevented the watchdog from getting fed, which basically resulted in our robot being disabled the rest of the match. It took us forever ti find the error since we had no programmer so we were stationary for 6 out of our 8 matches...

[Hanna2325]

We had the same problem after getting our replacement drivers station in KC. The robot was working one second then no the next. Our head programmer was able to fix it, eventually, however - Its seemed like as soon as we realized this was an issue it wasnt the worst thing to fix it was just stunk that it had to flip out before we realized. Even though it counted against us still, the FIRSt ppl were helpful in explaining the problem

[The Lucas]

Using printf (in C++ or any other print or file writing call) too frequently also causes the watchdog not to be fed in time. I suggest that any downloaded competition code have only a few infrequent print statements if any

[Caroline2399]

I think the Watchdog has to be fed about every 100 ms, otherwise it will timeout.

[Stuart]

ok just to be proactive. ( I have not run in to this problem with our own robot or any other that Ive messed with, but then Murphy's law n such.)

if you take out all the delay and feeds in auto mode. and replace them with your own way of delaying, AND place a parallel 100ms feed loop, everything will be OK?

[Wayne TenBrink]

I'm not the programmer, and neither is the original poster, so please bear with our ignorance. Our programming mentor has about 2 months worth of experience with LabView.

When you all describe "feeding the watchdog", what actually does that? From your description, I assume that its some built-in, behind the scenes, function of the code that just happens without any special "instruction" from our programmer. And if the code is too busy or gets stuck in a "while" loop, it doesn't feed the watchdog.

What would make that happen only intermittently? It seemed to happen to us at one particular setup location. It isn't camera related, because we don't use it. We use 4 CIM's/4 Jaguars, a gyro, two limity switches, and 3 microswitches for setting autonomous patterns. Two of the match failures occurred at the start of the match, resulting in no autonomous motion, and nothing after it either (until we learned how to reset the cRio from the DS (thanks 494)). One of our failures occurred after a successful autonomous. I don't know for sure if we got the "watchdog" message that time, but one side of the drive train (Jaguar/CIM) didn't work after autonomous. After the match, we found no problems and the problem didn't repeat.

We would like to think it was field/system related, but we really don't know. If its a robot problem (short, programming issue, loose connection, improper connection, etc.) we would really like to know. Intermittent, random, stuff is scary and frustrating and we would like to do whatever we can to fix it (if is something under our own control).

Is there a credible scenario where static electricity could be involved? Doesn't seem like it to me since it happened at the start of the match. What about startup sequencing? I've read where some teams had communication problems when they powered up the robot before the DS. We generally powered up the DS first, but probably not always. I wouldn't think that would necessarily have anything to do with watchdog.

We generally like the new control system and LabView, but are anxious to find out where the bugs are hiding out and get rid of them.

Thanks for all your help so far in this thread.

[big1boom]

I don't do programming, but I am pretty sure that when Simbotics, ThunderChickens, and Bomb Squad helped us, they found that we had our code in an infinite loop among other problems.

I know that for two qualifying matches, we would put autonomous in and then have no control of drivebase for the rest of the match. However, when we tried to recreate this in the pit with a tether, we couldn't.

[NoahTheBoa]

Originally Posted by big1boom

I don't do programming, but I am pretty sure that when Simbotics, ThunderChickens, and Bomb Squad helped us, they found that we had our code in an infinite loop among other problems.

I know that for two qualifying matches, we would put autonomous in and then have no control of drivebase for the rest of the match. However, when we tried to recreate this in the pit with a tether, we couldn't.

The exact same thing happened to us, except it took us 6 matches to fix it. One of the mentors from 1831 (Chris) found an infinite loop in our drive code. When we took that out it worked.

[Wayne TenBrink]

Did your drive shut down before or after it moved in autonomous? Did the failures occur in your first two matches or was it intermittent? Did the autonomous work in testing before you hooked up to the field system? Did you get the "watchdog" message?

It doesn't make sense to me that code would generate intermittent hang ups. Our system worked fine before the failure, and then again after rebooting. That implies something outside the code is influencing the system.

[Vikesrock]

Originally Posted by Wayne TenBrink

Did your drive shut down before or after it moved in autonomous? Did the failures occur in your first two matches or was it intermittent? Did the autonomous work in testing before you hooked up to the field system? Did you get the "watchdog" message?

It doesn't make sense to me that code would generate intermittent hang ups. Our system worked fine before the failure, and then again after rebooting. That implies something outside the code is influencing the system.

As far as I know it is not possible for the field to cause a Watchdog error.
EDIT: It sounds like, based on the document that StephenB linked to that communication problems could potentially cause the system Watchdog to time out.

Depending on the structure of your code it may be possible that one specific case somewhere or one value for a sensor or variable causes a hang that times out the User Watchdog. The robot gets cycled through a specific set of modes on the competition field that may not be the same as what is happening when you are testing on the practice field.

[StephenB]

There has been quite a bit of misinformation posted so far about this topic so I thought I'd try to clear it up: http://decibel.ni.com/content/docs/DOC-2957

Main thing is, there are two watchdogs. One you shouldn't ever worry about, and the other you should only worry about if you want to (it is optional and configurable)

Check out the doc, let me know if I can clear anything up.