Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   Watchdog!?!?!?! (http://www.chiefdelphi.com/forums/showthread.php?t=75361)

Alexa Stott 03-03-2009 19:46

Re: Watchdog!?!?!?!
 
A few notes on some of the things that have appeared in this thread:
1. I recommend disabling the watchdog entirely. This should be done by simply entering GetWatchdog.SetEnabled(false), NOT by "killing" the watchdog. That causes even more problems. I found this feature to be more of a pain than anything.
2. We have discovered that, if anything goes wrong in autonomous regarding code issues, you will be unable to retain control during teleop unless you reset, so resetting the system from the DS is critical. As such, we went through the process with our drive team. I highly recommend all programmers make sure that at least one driver knows how to do it. Wayne TenBrink posted instructions earlier on how that's done.

Vikesrock 03-03-2009 20:39

Re: Watchdog!?!?!?!
 
Quote:

Originally Posted by Alexa Stott (Post 831325)
1. I recommend disabling the watchdog entirely. This should be done by simply entering GetWatchdog.SetEnabled(false), NOT by "killing" the watchdog. That causes even more problems. I found this feature to be more of a pain than anything.

Watchdog's exist for a reason. I would not give a blanket statement saying disable the watchdog because for a number of teams this may be a bad idea. I know that there are parts of our robot that could be broken if our code were to hang and not be disabled by the watchdog.

For some teams disabling the watchdog may be the easy solution for now, but the "better" solution is probably a properly fed watchdog.

kirtar 03-03-2009 20:47

Re: Watchdog!?!?!?!
 
In any case, according to our programmers, not feeding the watchdog was the most common mistake in autonomous programming at Buckeye.

Alexa Stott 03-03-2009 21:15

Re: Watchdog!?!?!?!
 
Quote:

Originally Posted by Vikesrock (Post 831360)
Watchdog's exist for a reason. I would not give a blanket statement saying disable the watchdog because for a number of teams this may be a bad idea. I know that there are parts of our robot that could be broken if our code were to hang and not be disabled by the watchdog.

For some teams disabling the watchdog may be the easy solution for now, but the "better" solution is probably a properly fed watchdog.

We have not seen any problems arising from not using the watchdog, and we disabled it in all our code.

StephenB 03-03-2009 21:26

Re: Watchdog!?!?!?!
 
either way works. the main reason the watchdog was put in was for debugging. if you hit a breakpoint, you might not want the robot to keep chugging along.

Vikesrock 03-03-2009 21:27

Re: Watchdog!?!?!?!
 
Quote:

Originally Posted by Alexa Stott (Post 831389)
We have not seen any problems arising from not using the watchdog, and we disabled it in all our code.

Which is why I said it may work for some teams. We will not be disabling our watchdog because if our code is actually hanging somewhere we want the outputs disabled so our robot doesn't break itself or incur a penalty.

BLAQmx 03-03-2009 21:44

Re: Watchdog!?!?!?!
 
NI FIRST Support: FRC Robot Modes / States Explained

This is some documentation on these modes/states. Feel free to submit questions and feedback.

ahudson 23-01-2010 08:44

Re: Watchdog!?!?!?!
 
Glad to know we are not the only team struggling with programming. When using driver station we are able to connect to robot and drive sporadically, but have a watchdog not fed message. Does it have anything to do with the DS being so sporadic?
Also we have an ERROR Code 44015.

Bongle 23-01-2010 08:52

Re: Watchdog!?!?!?!
 
We had a watchdog issue when our battery got too low.

In C++, the default code has something like
GetWatchDog().Feed()
at the top of the OperatorControl() loop. You need to make sure that that function gets called frequently.

In C++ (and probably all the other languages, since they are all the same library), the image analysis code seems to be a bit too slow to keep your watchdog fed if you put it in your main loop. I recommend you create a new task (aka thread) and do the image analysis there, putting the results in some variable accessible to the main OperatorControl() or Autonomous() loops.

That's what we're going to be doing today. I don't know the specifics of how we're going to do it yet, but I do know that the PIDController class spawns a new thread in its constructor, so we're going to be copying that.


All times are GMT -5. The time now is 16:03.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi