I am experiencing the same symptom you are. It seems that any interaction with the SmartDashboard results in a robot crash. I have confirmed that the code I have works as expected (no watchdog issues) when SmartDashboard is not involved, but results in the dreaded “Watchdog Not Fed” symptom when even the simplest of lines is added (I went 1 level deeper to avoid using any of the code in the scheduler, just in case that was the problem - CommandBase::asp_accumulatorSubsystem is a sub-class of Subsystem and is therefore a subclass of SmartDashboardNamedData, so it fits the PutData() method signature):
As soon as I push even 1 button that causes the Accumulator subsystem to activate, the code crashes. Here are the errors I get on the Driver Station Diagnostics window (it appears that the errors are to be read from the bottom up):
ERROR: A timeout has been exceeded: NetworkTables watchdog expired... disconnecting ...in WatchdogTaskRun() in C:/WindRiver/workspace/WPILib/NetworkTables/Connection.cpp at line 567
ERROR: A timeout has been exceeded: NetworkTables watchdog expired... disconnecting ...in WatchdogTaskRun() in C:/WindRiver/workspace/WPILib/NetworkTables/Connection.cpp at line 567
ERROR: Task error: Task already deleted.: FRC_NetworkTablesWriteTask ...in HandleError() in C:/WindRiver/workspace/WPILib/Task.cpp at line 190
ERROR: Error reading NetworkTables socket: errno=54 ...in Read() in C:/WindRiver/workspace/WPILib/NetworkTables/Reader.cpp at line 70
ERROR: NetworkTables data stream is corrupt: Unexpected ID ...in GetTable() in C:/WindRiver/workspace/WPILib/NetworkTables/Connection.cpp at line 534
Then it seems like the timeout error occurs repeatedly - because the Robot Task is dead due to the watchdog issue.
I only have the problem when trying to send the Scheduler to the SmartDashboard. I am having no problem putting other data including subsystem objects, PID controllers and just raw doubles. All of this works fine:
void DriveSubsystem::UpdateStatus()
{
SmartDashboard::GetInstance()->PutDouble("Left Raw",pLeftEncoder->GetRaw());
SmartDashboard::GetInstance()->PutDouble("Right Raw",pRightEncoder->GetRaw());
SmartDashboard::GetInstance()->PutDouble("Left Speed",pLeftEncoder->GetRate());
SmartDashboard::GetInstance()->PutDouble("Right Speed",pRightEncoder->GetRate());
SmartDashboard::GetInstance()->PutDouble("Left Set Point",this->pLeftSpeedControl->GetSetpoint());
SmartDashboard::GetInstance()->PutDouble("Right Set Point",this->pRightSpeedControl->GetSetpoint());
}
I’m not sure how your code works since you are not using the scheduler in TeleopPeriodic(). There is probably not much reason to use the Command Based architecture if you are not going to use the scheduler. And that may also be leading to the crashes you are seeing…
We are using Button/Command/Subsystem architecture (5 subsystems, 12 commands, 6 buttons so far, more to come). I left those details out because I wanted to focus on the problem at hand - the scheduler.
I also see that individual data points are successfully sent to the Dashboard using the PutInt(), PutDouble() etc. methods. I believe we are observing exactly the same issue.
We are having same issue with the robot crashing when we are trying to send Scheduler output to the SmartDashboard. I don’t have the exact details in front of me, but we I believe we are getting a nul function pointer (or at least some other type of excecution at location zero) in the wpilib code on the main robot code and some timeouts on some of the NetworkTable worker tasks. I am not sure which comes first the crash or the dead threads. The problem can occur right away or after a few minutes.
All of our other output so far works fine to the SmartDashBoard other than the scheduler information.
We have very little in the way of new code at this point (1 subsystem and a handful of commands) We are programming in C++. Any suggestions would be appreciated and we figure anything out, we will post some more information.
We are having the same issue. I have a DriveWithJoysticksCmd command, that calls a Drive() method on our DriveTrainSubsystem whenever the Execute() method is called. Everything works great if I create and Start() the command in TeleopInit(). However, if I add the line
I downloaded the update, and it got rid of some of the problems I was having, where GetTable() was returning null when NetworkTables were being initialized (I would get this error every time I put something to the SmartDashboard), however, adding the Scheduler to the SmartDashboard still triggers the watchdog timeout problem for us.
Upon further experimentation, it appears that the SmartDashboard update on the cRIO side may be causing the watchdog timeouts. I added a couple of SD->PutDouble(…) calls in my drive subsystem whenever the drive motors were being set by either the joysticks or directly by a command. Sometimes this would work, and sometimes it would cause timeouts immediately, and sometimes it would timeout after a CommandGroup finished, but before the default command for the drive subsystem could start. If I remove the calls to SD->PutDouble(…) then the problem goes away, and everything functions normally.
I’m new to FIRST and FRC, so I’m still learning WPILib - is there another good way to log data? I can use the DS LCD, but that gets crowded and cumbersome for debugging. I’m using the NI NetConsole app - can I just log the values so they show up there?
If you can come up with a concise example that causes the failure with the 3111 release, please create a tracker at firstforge.wpi.edu in the WPILib project.
We’re getting similar errors, the whole “Network Tables” and watchdog problem with the scheduler. However, whenever we send Subsystem data to the dashboard, so that we can read what commands are running, the textbox displays the word “Command” followed by a string of random numbers and letters. Are these problems related? Or is there something just drastically wrong with our code? Any answers will be greatly appreciated!
When you put a Subsystem in SmartDashboard, it will pop-up with a text box saying the name of the command that is running.
In Java, the command is given a name automatically (using reflection). You can’t do this in c++, so the commands are given “Command:” and then the pointer number as a name.
If you want to give your commands readable names, just hand in a string with the name when you initialize them.
Thank you so much; this really helps. This may be a stupid question, but where exactly would you hand in the string? When you initialize the Subsystem with the SmartDashboard or when you initialize the Command itself?
Same issues here. BTW - the cRIO does not seem able to re-establish comm with the SD - make sure to restart it every time. The entire Network Table concept looks like a nice idea, but the code is unfortunately half-baked and not quite tested.
Is it still possible to send the scheduler to the SmartDashboard to see what command is currently being run by the scheduler? It looks like Scheduler is not a sub-class of Sendable so it can’t be passed to the SmartDashboard::PutData() methods. I thought this was a useful feature…anything equivalent I can do?
We ran into the same thing and would love to know the answer if anyone has it. Was there a reason the Scheduler was potentially changed to not be sendable? Is there another way to achieve the same thing?
Still didn’t see an answer on how to pass a name to commands during initialization so they are named in the SmartDashboard for c++. Has someone else solved this?