We have been having issues where in the middle of a match, with no other problems, the robot suddenly drops out of teleop mode, while the driver station stays in teleop. After that, for the remainder of the match, the robot would periodically go back into teleop for a single software loop exactly once every 5 seconds, but then immediately drop out again, putting us out of the match. Neither the initial nor subsequent drops occur in conjunction with physical shocks or impacts. Neither the field management system nor the driver station indicated any connection issues. Similarly, the log file for the match shows minimal packet loss and no brownout issues. The occasional battery voltage drops during the problem are the result of the robot moving on the field when a command happened to get through during one of the single-loop teleop reconnects.
This issue occurred twice during our last regional, on different days, with seemingly no connection between them. We have another regional this coming weekend and are obviously eager to resolve this before it. We have only observed this during matches, not during practice. The driver station log files and our code are attached here. Sorry for code quality, this is our first year using C++ to code the robot.
Anyone know what is happening here and how to fix it?
By any chance did you retrieve the log file off the roboRIO? The file is: /user/lvuser/FRCUserProgram.log. It might have some additional diagnostic information that could be very useful for you to track down what is happening. It will also capture printf output from your code. I will look at your code when I get home tonight and see if I can find anything to recommend.
Looking at the events in your driverstation logs, the IMAQdxGrab error, mentioned in the post by euhlmann, is worth consideration. Error -1074360293 is a timeout error.
That timeout error is then followed by timeout errors from your robotdrive. Timeout errors on the robotdrive would be observed as the drive not receiving driver commanding (ie robot appears dead). The periodicity of the IMAQdxGrab errors is approximately the 5 seconds you state in your original post. Since this is occurring in the middle of the match, that might indicate that the camera may have become disconnected electrically at the point the errors start being observed. Hard to tell from just the logs. I know that the team I mentor with (4329) has spent quite a bit of effort to harden the robot’s electrical connections for this game, especially the radio’s.
Your code invokes: IMAQdxGrab(curCam, frame, true, NULL); with the waitForNextBuffer argument set to true.
All this seems to point to your use of IMAQdxGrab is a blocking call that is only returning when it times out. While the call is blocking it is starving the rest of your teleop code which is why the robotdrive is reporting timeouts as well.
It might be worth placing your CameraFeeds::Run into its own Task. This will create a separate execution thread that can block without causing the rest of your teleop code wait for the blocking code to return.
Another recommendation is to check your Eclipse plugins and ensure they are up to date.
On another note I would recommend looking at the command pattern for C++ programming. it is pretty powerful and will help keep your code more easily manageable.
Lastly, while I am not especially proud of the code, I have a class for an xbox controller you might be interested in.
As I get time, I’ll look over more of your code in detail to see if I can find anything else. I would be curious to know how things go with your resolution of this issue.