Router Issue? (Watchdog not Feed)


Our team was testing to robot today and we had some weird issue. The robot was driving and then it just stoped. The driver station communications and robot code would randomly turn red at different times. Also whenever we tried to enable the robot the driver station said “Watchdog not Feed”. In testing different configurations we found the bring the robot closer to the computer worked. However if the robot was more then 5 feet away we would lose connection. Everything worked fine when we used an ethernet cable. We then went into the Wireless settings on the router and changed:

  • the wireless channel from auto to manual number 11.
  • the band width from 20MHz to 20/40Mhz
    After these changes everything worked fine. I was wondering what made it work and why does that happen. Our team had the same problem with the watchdog at last years competition and the only thing that we (many people from other teams) could figure out to do was to reprogram the robot. After that it worked again.

So… My question is what does the “Watchdog not Feed” message mean and what is the best way of fixing it and what did I do to fix it? This is something that I want to know just to know how to fix it later on.

Thank you!

The “watchdog” on the robot is simply checking for new inputs from the driver station while the robot is running. If the code lags or you lose connection so that new inputs can’t be sent, the “watchdog” isn’t “fed” new inputs, and it automatically stops the robot’s movement. This is a basic safety feature to ensure that the robot doesn’t keep driving and kill someone if you lose connection.

The way to improve the problem? Just fix your communications, like you did, and make sure that your code isn’t slowing down to the point where it can’t get new inputs often enough.

This is just wrong. No answer is better than a wrong answer. The watchdog has nothing to do with network communication.

The watchdog will stop all outputs from the cRio when the watchdog is not fed. You put feed statements in your program to inform the cRio that your user code is still running and isn’t hung up in a loop. Either the set expiration was set too low, or you have a slow loop somewhere. Set expiration is basically setting the amount of maximum amount of time you want to allow between 2 feeds without disabling the robot.

On my DD-WRT router, I can enable a watchdog so that it automatically reboots if it lags out or crashes. The same thing has been implemented on my Pi to give it a 100% uptime with 0 maintenance. Is this the dysfunctional hardware we are talking about?

If you are having connection problems, here’s what to check. We had connection problems until we got new computers this year. Some laptops are just lacking a powerful antenna to connect to the robot’s network. That was our main problem last year. To solve that issue, there are two solutions:
-Get a router to connect both the DS and the laptop using
-Get a new computer
-Get a good Wireless adapter (internal would be best).

Before you do that, eradicate the interference. In our school, we have an AP every 10-20 ft so interference is tremendous. To eradicate that problem, here are a few things to do:
-use a powerful router (DD-WRT is nice because you can hack the router and change the Tx power.).
-Ask your school to shut down the Wireless (unlikely)
-Go outside or to the gym where there ain’t as much network.
-get a more powerful computer.
-turn off bluetooth and wifi on EVERYTHING
-operate before and after school when less people are accessing the network

That may be able to solve connection problems. Otherwise, the problem to me is unknown in the sea of possibilities! Good luck in troubleshooting!

What you’ve posted is “just wrong”. No answer is better than a wrong answer.

There is a network watchdog present on the cRIO. The system watchdog has everything to do with network communication.

Just wondering, how many GP watchdogs are on the cRIO (locked and unlocked)? On the RPi, there is one, that I use to fix hangs and crashes. I am pretty sure there are at least two: network and processor! Also, how does the cRIO boot into safe mode if it corrupted?

The cRIO has two types of watchdogs. The system watchdog cannot be modified and makes sure that the DS laptop is still connected and sending packets to the robot. If the laptop runs out of battery, is dropped, or driver station is closed, the robot will automatically disable.

The second type is the user watchdog. This can be configured as an extra safety feature to stop an actuator if your code takes longer than expected to execute or crashes. They are used by default in RobotDrive, or they can be added manually. It’s a great safety feature for drive. If your code doesn’t update the value set for the drive motors because of an issue, you don’t want the robot to continue driving at full speed.

It causes the “robot drive output not update often enough” errors a lot for command based robot programming because if one command is slow to execute, the whole robot code falls apart because the scheduler has to wait for each command to finish executing before it moves on to the next thing.

For this reason, I always put the robot drive code in a separate thread so that if some other command takes a long time and prevents the scheduler from getting to the next command, I don’t have issues with drive.

A specific quote about the system watchdog from that article:

System Watchdog
The system watchdog (always enabled) ensures the wireless and Compact RIO system are behaving properly. This is a watchdog built into the Compact RIO FPGA that is fed TCP packets through the Ethernet connection (wired or wireless) from the driver station to the cRIO-FRC. This happens by default and requires no additional setup from the user beyond normal IP address setup of the cRIO and driver’s station. If anything disrupts the connection between the drivers station and the cRIO (such as a loss of wireless network connection) the FPGA turns off all PWM and actuator outputs. This immediately stops the robot and prevents a run-away robot. Additionally, the system watchdog will trigger if the competition dongle is not attached to the drivers station in the enabled position. Teams do not have any way to access or modify this watchdog. Ideally, this watchdog is entirely transparent to the user and just works.

Okay, I’ve been learning a little more about watchdogs, and while I don’t think my answer was “just wrong”, I realize now that I should clarify something:

The watchdogs on an FRC robot need to be “fed” by the code just like any other. The difference with FRC that I didn’t fully understand was the fact that the cRIO FPGA has its own watchdog, mostly invisible to the user, that is fed based on new TCP packets. There is also a user watchdog, which is what simpsonboy77 was referring to. So neither of us were “just wrong!”

Awesome thank you all. This is some really helpful information!

What is your firmware version? May be there is a need to upgrade the one first.