Re: Still having some watchdog issues
 

You can change whatever you desire in your code. It's legal.
The framework is just a starting point, and some teams don't use it at all.
Teams that are not using the gyro or camera to track should rip that code out entirely. It's just a possibly useful example.

The user watchdog is not required.
It is intended to be a benefit in helping locate user code that takes too long.
Used correctly, it can help protect you from unintended, uncontrolled rampant behavior by a robot.
Used incorrectly, it can facilitate unintended, uncontrolled rampant behavior by a robot.
If it is a hindrance then you certainly can remove it.
I'm not a particular fan of it myself, because if you can correctly implement it, then you probably don't need it. If you cannot correctly implement it, then it'll be the cause of more heartache than saving grace.

Alternate joysticks have more buttons, just as they have up to 4 more axis than the KOP joystick.

Re: Still having some watchdog issues
 

Thanks a whole bunch, my life just became a lot easier!

Thank you, thank you, THANK YOU!!!

Re: Still having some watchdog issues
 

The comment in Teleop says it's button 2, but the Joystick Read vi actually outputs the Reset Gyro signal when buttons 8 and 9 are pressed simultaneously. You can certainly change that to whatever you want.

Re: Still having some watchdog issues
 

Nice thought. I thought it was the problem, but checking the code again reveals that there is a While(IsAutonomous()) in the autonomous covering everything. :( The problem isn't that rampant any further and it might have been fixed when we were playing with Autonomous because at first we had a timer to govern the autonomous instead of While(IsAutonomous). Thanks!

Re: Still having some watchdog issues
 

Ok - another update.

1. We are not using the cypress board.
2. We have now disabled the boolean that allows error-reporting.
3. We have gone through our code and cleaned out every unused global, .vi, etc.
4. The diagnostic screen shows absolutely NO errors, (other than the old camera error on startup every once in a while - one http error and never seen again).
5. We do not have a single loop in our code, other than what comes in the default camera code.
6. We have removed the image-save function and all the graphs from the dashboard to minimize classmate CPU time. We have only the camera image, and the driver station portion running.

Upon doing this, enabling the robot, and letting it run we are seeing approximately 1 watchdog expiration every 6 minutes where the robot will have a temporary "twitch". We've gone to the effort of replumbing and wiring the bot so that when everything dumps to it's disabled state it does NOT fire the shooter latches or pneumatics.

Tomorrow we're going to start timing our code with the timer VI. However, I suspect more and more this is not a code issue but rather the classmate CPU deciding to do something. For instance, I noticed yesterday than when the driver station blanked the screen for sitting too long it generated 3 watchdog expireds in very rapid succession (all in a second or two).

If we have no further success tomorrow, I'm going to make sure that system restore, the virus scanner, fast file indexing, automatic updating, and the BIT's service are all turned off permanently on the classmate to see what that does. I'm also going to change the setting on the classmate to maximum performance for the battery management.

Re: Still having some watchdog issues
 

This is from http://decibel.ni.com/content/docs/DOC-2957 :

I have been unable to find further details, e.g., how many packets can be dropped before the watchdog expires etc.

One can easily imagine that various system (or application) processes within Windows could occasionally interfere with TCP packet transmission. Windows is not a hard-real-time OS.


~

Re: Still having some watchdog issues
 

Has anyone called NI on their hotline or posted a discussion on their forum about this exact reason? I think this thread is excellent, as there certainly is a repeating problem here that they need to know about.

We too have had this problem (our robot is shipped now), but don't really have anything new to report. Sometimes we would have to cycle power to the robot to get it to cooperate. If this helps, we had a strong lead that it was a power issue because the connection from our battery was bad. But it still happened after that was fixed.

I have just read through the whole thread and it does not seem to be a code issue. Teams have removed all offending items (loops, unused code, etc) and this does not seem to fix the problem. What interests me is the lead about the Classmate slowing things down. People have mentioned turning off virus protection and that going into screen saver promptly fires off some watchdog errors. Tom Line also posted other information shortly before me that supports this. I think this looks like it's worth researching. Thanks Tom for saying that you and your team will.

One thing I'd like to mention is that the user watchdog gets tripped/sends an error if it's not feed for half a second (by default). To me, that sounded like a long time in terms of programming. The code loops a couple hundred times per second (correct me if I'm wrong on that, I might be) and before a watchdog trips the robot is still operable (as seen in past occurrences). One would notice if, say, a race condition was holding up the code for a whole half of a second. I don't know what to think of that, other than that it's interesting and does point to the classmate.

Re: Still having some watchdog issues
 

The iteration period of the teleop task is 20ms, which is 50Hz. Not a couple hundred.

The 20ms is established by the Driver Station, which sends teleop (and autonomous iterative) data packet to cRIO every 20ms.

The teleop (and autonomous iterative) task is triggered by receipt of data packet.


~

Re: Still having some watchdog issues
 

Also - Greg and the other folks at NI have been hard at work on this issue. The last update put up on the web for the Crio image etc greatly helped the problem for us (100's to only a handful in a half-hour).

Unfortunately, our team is in total crunch time and any non-essential testing that doesn't involve actual function of some component of the robot is being put by the wayside while we hammer out our mechanical issues on the practice bot and prepare for the all-mighty 6 hour fix-it window we have.

Re: Still having some watchdog issues
 

Opps. :) That sounds familiar now.

Ok, thanks Tom for what you are doing!!!

Re: Still having some watchdog issues
 

Just an update:
It turns out that we didn't install the new cRio image in the 2.1 labview update, but the watchdog errors still appeared even after fixing this.
Regardless, the FMS at the Oregon Regional did not disable our robot, we had no problem competing.

Re: Still having some watchdog issues
 

Have any of you teams gotten any lead on this? This thread has been pretty silent. We would if we could, but we can't do much problem solving here since we don't have a second control system. Just wondering because I've been following this issue.

Re: Still having some watchdog issues
 

I can report that during our 2 competitions that we just finished, there was not a single incident of our computer classmate or our robot having coms problems on the field.

We did have ONE incident where the joysticks decided not to work. Pressing F1 on the driverstation to refresh them solved the issue (they were also unplugged then replugged quickly too).

We continue to have expirations. Sometimes they get VERY bad (dozens a minute). When that happens, a reboot of the classmate drops them back down to a handful. They do not, however, affect our field operation.

Greg, if you'd PM me you email I'll zip up our code and send it to you.

Re: Still having some watchdog issues
 

Thanks Tom for the update!

Hmmm more Classmate evidence.

Re: Still having some watchdog issues
 

Our team is having similar problems, though we're not sure if it's the watchdog. Browsing through this thread, we think it might be, but I didn't see a final solution. We're getting a stutter approximately every .5 seconds (with some variation) when we call Compressor.setRelayValue(Relay.Value.kOn) each iteration. If we only call the function once, we get a short burst of compressor noise and then it shuts off. Any idea as to what might be messing with the relay?

Thanks so much! We're in a crunch at crunch time!