Re: Still having some watchdog issues
 

It's against the robot rules to put a Fisher Price motor on a Spike relay. <R55-A>: "Each CIM motor and Fisher-Price motor must be connected to one and only one approved speed controller. These motors must not be connected to relay modules."

Those motors draw much more than the 20 amps a Spike is good for.

Re: Still having some watchdog issues
 

I'm sorry to be a pest but I must be absolutely and totally clear.
As I understand it, there are two watchdogs, the User watchdog in the code and the system watchdog on the cRio. I have no idea which watchdog is causing this error.
You say the FMS doesn't care about the User Watchdog, this is good news for my team.
Is the same true for the System watchdog?

Re: Still having some watchdog issues
 

Since watchdogs are timing issues, you might try this approach to turn off auto error logging. It may help.

Re: Still having some watchdog issues
 

Since watchdogs are timing issues, you might try turning off auto error logging. It may help. Look at the post titled:

Turning off automatic error logging in LabVIEW may improve loop timing

Re: Still having some watchdog issues
 

User and System watchdogs look the same unless you are the safety code that knows which timer timed out.

Greg McKaskle

Re: Still having some watchdog issues
 

As Greg pointed out, a Watchdog is a Watchdog. FMS won't know about either one, in fact they can occur naturally for every team at the change of Modes (disabled, Autonomous, Teleop). So if robots were running at all during your scrimmage, then the Watchdog wasn't stopping the event.

FMS only kills permanently on an E-stop.
After an E-stop the robot MUST be reset to run again.

The E-stop can be engaged at the Driver Station by the drive team or a referee.
It can also be engaged at the FMS station at the scorers table at the discretion of the FTA or Head Ref.

Re: Still having some watchdog issues
 

that definetly explains why the fuses are blowing, thanks, but what about the timing out on the compressor? I can't figure out why it would be stuttering, because it should be continious. and the relays should be operating just fine even when not under load, but still time out.

is there a limit to how much code we can put in teleop to prevent it from overtiming? or is it all electrical?

Re: Still having some watchdog issues
 

Ok. We've fully updated. We're back to seeing the "expired" watchdog errors. We let the bot run in teleop (non-moving) enabled. It does not happen in disabled. It sat there for 26 minutes, and we encountered 96 watchdog expired messages. Every time one came through, it disabled the vics/spikes on the board for a split second.

We'll try the above mentioned change to improve loop timing, but I sure wish there was a way to diagnose this back to the root cause.

Correct me if I'm wrong, but if it's my code shouldn't it be happening a wee bit more often than once every 15-20 seconds? I have NO loops inside my code at all, other than the vision code (default, no mods). The vision code is currently turned off.

I'm going to try loading a default code tomorrow and see what happens.

Re: Still having some watchdog issues
 

I realize this is the LabView forum, but we are having a very similar problem in C++. In fact, it can be duplicated with a very simple (<50 line) C++ program (with no Watchdog object at all). The symptoms are: every 30 seconds, or so, all the motors, servos and solenoids on our robot turn on and off for about 100-500 ms. This happens repeatedly over a 2-3 second interval, after which everything is fine for another 30 seconds - 1 minute (and then the whole sequence repeats).

When this "chatter" occurs, we get Watchdog timeout message on the driver station.

We get this same problem when using the out-of-the-box SimpleRobot sample code in WindRiver.

It happens with a much simpler sample as well (no Watchdog object instantiated at all).

It happens on multiple cRios.

It happens even if we raise our Task Priority to 1.

We are running out of ideas on debugging this. If anyone has any ideas on this they would be GREATLY APPRECIATED!

Re: Still having some watchdog issues
 

LyraS,
You could try running it from a different computer. Some people had some luck with that on the NI forum.
I can't test that myself though :(

Re: Still having some watchdog issues
 

On three matches at the Suffield Scrimmage our robot became disable during the match. After the second time I had the field software guy come over (sorry don't remember his name) and he looked at our system and told me that since we lost communication with the robot due to a watchdog error that the FMS would lock us out until it could regain communication. We would get an "FMS Locked" display instead of "FMS Connected". The only way to get rid of the Locked mode was to reboot our dashboard. We never tried to do this during the match.

After the second time we were disabled, I removed all of the LabView default code that we were not using (camera, gyro, autonomous), with the exception of the T/F code for gyro contro in the Teleop block (I just didn't have time to deal with that code). We then ran fine for 2 rounds, but on our next round we became disable again. This time I found many,many errors listed for the gyro having no refnum (I removed it from the Begin block) - my theory: one of the students had accidentally pressed button 3 which activated the gyro code block that I didn't remove - it appears this error kept coming up until finally a watchdog error was tripped and our robot was disabled. I did verify after that round that the field people did not disable us (as a part had fallen of our bot, so the students thought we were disabled).

So, from my perspective I believe the watchdog error was shutting us down - is it possible to have this tested? Is someone at FIRST able to create a System watchdog error to see if the FMS stops operator communication by going to FMS Locked mode?

Greg, BTW we did have the virus software enabled , wifi was turned off on the Classmate, we use LabVIew, and we do not use the PSoC I/O board. We have kept our ClassMate and cRIO if there are any test you would like us to try (I feel we have resolved our watchdog timer issue though, by eliminating unused code).

Merle Yoder
GRUNTS Team #3146

Re: Still having some watchdog issues
 

Just to better explain the states the DS goes into for a field, because you don't see them that often.

The DS is always accepting a field connection. If the field shows up, some UI elements hide and the field is in control of the robot mode, the alliance color, etc. Once the DS has attached to the field, you are bound to it. If the field disappears, the robot goes to FMS Locked state until either the field comes back or the DS application is restarted. This is to prevent anyone driving the robot without field supervision.

If your DS said FMS locked, that means that the ethernet cable connection to the field was no longer connected. It may be worthwhile hard connecting to the robot, going to the Diagnostics tab and slowly wiggling the connector and cable to see if you have a flaky laptop connector.

Greg McKaskle

Re: Still having some watchdog issues
 

Hi, we have a somewhat similar issue in C++.

We wrote a nice, long autonomous code that works perfectly. Everything works as coded. But occasionally when we switch from autonomous to teleop to reset the robot after testing the autonomous, the robot keeps going as if it were still in autonomous mode, even though the Classmate clearly states that it is in teleoperated mode. Other functions of the robot go crazy, such as our kicker and such. No watchdog errors, nothing. Just the robot running in a straight line kicking at thin air.

Re: Still having some watchdog issues
 

That sounds like a missed user check for the current robot mode.
In C++ you have full control of when you are in autonomous and when you are in teleop modes. Actually, it can be done in any of the languages, they're just frameworks after all.

That means you must constantly check to see what mode the robot is supposed to be in and act on that information, otherwise, your autonomous code looks no different than your Teleop code and the system doesn't go out of it's way to stop it. If you want to run autonomously during Teleop, no one will stop you.
Likewise, if you really want to run your Teleop code during Autonomous, it can be run.

For instance, if you mistype a command in Autonomous and tell the robot to Wait for 3 minutes, then you'll never get to drive.

If you followed the default framework and Autonomous happens to end early, then you won't notice a problem, but if autonomous runs longer than 15 seconds, then it'll encroach on Teleop time and keep running.

Re: Still having some watchdog issues
 

Fact wanted:
Can I delete the watchdog already in the default code?
Will it help with some of the problems mentioned?
Is it legal?
Is it permissable to feed it in the periodic taskVI loops, and to start feeding it in the beginVI, and feed in both independant and iterative automonus?

Other random question:
When unbundling the joystick, it says there are 12 buttons, where I can only find 11 on the Joystick itself.

I may have answered my own question:
In teleop, default code says I can "0" my gyro by button #2. Is it possible, permissable to change that, which joystick does it normally read, could it be a problem if I have actuators on that same button?