Robot glitching on field

At our competition this weekend we were having trouble with our Robot randomly stopping on the field. It would stop for 5-15 seconds after which we would regain control. We were not however able to recreate this is the pits. I have posted our code if anyone knows what is going on your help would be very much appreciated.

Have you eliminated the possibility of this being an electrical problem? Did you lose communication during the match? Have you looked at the DS logs for any errors or communication issues?
Also, if you are at an event you can always ask for help from one of the local CSAs, they are there to help with this kind of problems and can provide more help as they are walking through the problem with you at the event.

Start with your driver station logs. That will tell you if it is battery or communications issue. After that you have to move on to code etc.

This typically corresponds to the roborio getting temporarily disconnected and then reconnecting in those 5-15 seconds; however, in order to be certain, you should check the log files for the matches. See here for instructions on how to access/read the log files. For your case, I believe that you should look at the event log for a message along the lines of “Ping Results” where you could see if the driver station wasn’t able to communicate with the roborio and/or the router.

If the roborio is disconnecting, I would suggest trying to shake the power input to see if it is loose. If that is the case, start by tightening the connection’s screws and if that doesn’t work then I’d recommend buying a new plastic connector (they stop working for us quite frequently).

Note: I think it would’ve been best, as @Omer_Huly suggested, to have contacted a CSA during the competition to diagnose the problem early on.

Absolutely start with the driver station logs. This may well be a brownout situation (the most obvious answer) but could be something more difficult. Checking the logs will tell you what’s going on before you go delving into code that may be perfectly fine.

We had a CSA look at our log files and he couldn’t find any issue

That seems odd… Could you post a screenshot of the log for a match in which you lost connection?

here is a screenshot

Its bad connections almost guaranteed check all connections and secure them. Scouts note “dead” bots you are hurting your chances

Thanks for the screenshot, could you take another one with the “Event List” tab?—if you cannot fit it all in one screen then could you scroll to when it disconnects or take multiple images? It seems odd that there are no yellow/red dots before the latency goes up, and the packet loss still remains relatively low during the disconnects.

I think there may, in fact, be something else at play here. A disconnect from the robot should correspond to a spike in the packet loss, and yet that only happens slightly. At this point I am leaning towards the initial suggestion of issues with the code, the Event List should clarify what is happening here.

The fact that the robot would stop for 5-15 seconds but yet your voltage is jumping all around even when the robot is not moving and there are no disconnections indicators is disturbing.
Is it the only match it happened or are there any other matches with logs where the problem occurred?
As @oleitersdorf said a screenshot of “Event List” tab would help too.

One thing to note but thanks for the replies. We had a CSA review the logs at the regional this weekend but he could not find anything amiss. Practice robot with the same code on pure wifi doesn’t show the issue. It only seems to happen when connected to the field itself, and happened for every match.

While it is plausible that the latency is FMS-related (such as a phone HotSpot interfering with the radio), I would first want to be certain that everything within your control is perfect as interference issues are typically only temporary (you wouldn’t have the problem for multiple matches).

That being said, I took a look at your GitHub and, no offense, but the code is a type of maze… I would not be surprised if the code was causing the latency issue due to a periodic function not returning in time. The “Event List” page would be able to provide further information as to whether this is the problem. If the code is indeed the issues, then I’ll try to suggest various ways to diagnose the issue.

With regards to why it works in the pit or with practice but not on the field, I think it may be a scenario where the code is already close to “the edge” and the FMS is enough to “push” it over the limit, causing the disconnects. Cannot tell for certain without the “Event List”.

Will try to upload screen caps of the event list when we can get wifi (after event finishes).

There is a common warning message similar to this:

robotPeriodic():0.000170s teleopPeriodic():0.021666s Warning at edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.Java:273) : Loop time of 0.02s overrun Warning 1 Loop time of 0.02s overrun edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.Java:273)

Other message is: Watchdog not fed within 0.020000s

Screen shots here. This repeats throughout the match:



Just to be sure, what is your RoboRio’s image version?
If it’s not FRC_roboRIO_2019_v14 then that might be the problem.

It looks like your TeleopPeriodic code isn’t executing fast enough, and that’s causing watchdog issues. I’m not great with Java, so I’ll let someone else actually help fix the code.

Also, based on the battery voltage graph you provided earlier it looks like you likely have either a bad battery or loose connection between the battery and PDP. That’s whats causing the voltage graph to look so shaky. You should double check all your connections (if you can move them by hand they’re too loose) and check all of your batteries with a battery beak.

disclaimer: not a programming mentor
what language? there was a bug in the latest python update we ran into on Thursday, but we were able to fix by friday morning, it mainly affected the sandstorm period, we would lose code twice in sandstorm, and once at the start of telop, and then we were good for the rest of the match. It has something to do with the timer that changes the state of the fms from sandstorm to telop if im not mistaken. One fix was to revert back to an older version, but I think our mentor was able to fix the current update…

we were getting the “watchdog not fed” error

you can recreate the issue at home or in the pit by running in “practice” mode on the driver station

They’re using Java (see the GitHub page).

I second this question as I noticed that the code is at 2019.2.1 WPILib (corresponding to roborio v13) and not 2019.3.1 WPILib (coorsponding to roborio v14) — it is possible though that you updated it locally and did not commit/push to GitHub. Please make sure you’re on the latest versions.

From the event log, we can see behavior where the loop takes up to 40ms (when it’s supposed to run every 20ms) which can cause the robot’s latency to increase. Looking back at the log graph, I would guess that the loop overall takes over 20ms (which is not good) and then there are additional spikes in the loop time (corresponding to the times the robot stops) that are not included in the EventList log (due to random chance). If I had to guess, I would say that the following is responsible for delaying your robot program (starting line 145 in RobotFunctions.java):

if (_backupJoy.getRawButton(1) || _backupJoy.getRawButton(3)) { // square button wrist up circle wrist up
  while (_backupJoy.getRawButton(3)) {
    SmartDashboard.putNumber("aaaaaaaaaa", 13);
  Robot.wrist.in();
  }
  while (_backupJoy.getRawButton(1)) {
  Robot.wrist.out();
  }
  ManualWrist = true;
}

You should never have a while loop such as that in a periodic function as it delays the execution of the program, and any messages from the DS (such as additional joystick information), until that while loop is complete. Unfortunately, I was unable to understand what you’re trying to do with this part of the code; if you could explain it to me, then I may be able to propose a solution that doesn’t involve the while loop.

Regarding the function being overrun regardless, taking about 30ms for the periodic function (when not running the while loop) isn’t that terrible for your robot performance and you will most likely not notice it too much. That being said, it’s nice to have the function under 20ms so I suggest that you place various System.currentTimeMillis() throughout the periodic functions to figure out what is taking up that time. I suspect it’ll be the many small functions that you have adding up — for example in LifterSubsystem.java line 63:

public void GoToHighBallPosition() { // moving to given position
// setting PID values
lift.setP(1);
lift.setI(0);
lift.setD(0);
lift.setIZone(0);
lift.setFF(0);
lift.setOutputRange(-1, 1);

lift2.setP(1);
lift2.setI(0);
lift2.setD(0);
lift2.setIZone(0);
lift2.setFF(0);
lift2.setOutputRange(-1, 1);
// setting PID values
lift.setReference(280, ControlType.kPosition);
lift2.setReference(-280, ControlType.kPosition);//orginal 320

}

Setting the PID constants and output range each time just requires more operations on the CAN bus (which cooresponds to more processing time) when the same function can be achieved by moving the PID constant setup to an init function and then only setting the reference in the periodic function. Same goes for all the other subsystems.

1 Like

When did you stop for 5-15 seconds in match 73? Watching the match video, I didn’t really see any, which is consistent with the log.