FRC PID did not die within 500 ms. Force killing with kill -9

Have seen old threads on this with no satisfactory answer. This error corresponds to the code not properly deploying and CTR CAN Frame not received/too-stale errors that prevent the code from running without a redeploy. Does anyone know of a way to fix this?
Code: GitHub - Team4028/wpiScratchSwerve (main branch)

Unfortunately I don’t have a solution for you. We are getting the same issue.

We quite often will Deploy and the Driver Station indicates the code is ready and we can enable, but the we have no joystick control, even though the Driver Station show the inputs properly. Do you see this as well or is this a different issue that we have?


Hmmmm, can you describe how you proved this out? The error message I see just shows code stopping and restarting, but no indication of whether the deploy succeeded.

The way I’d usually test something like this is to make a new, blank robot project, and deploy it. If the CTR messages persist, I think you could say you’ve proven the new .jar is not getting to the right spot on the RIO, and that’s your main goal to debug. But I wouldn’t go debugging the deploy process until that’s proven.

You’re likely seeing this issue:

Basically, when the previous program doesn’t shut down correctly (indicated by the kill -9) it causes all CAN comms to not work in the newly run program. The fix is to re-start code and this issue does not occur when you first boot the RIO (such as before a match).

Is there anyway to change something in my code that will prevent this from happening at all?

When I say “not properly deploying” I just mean the driver station says there is no robot code after deploy. I am not well-versed in the actual deploy process, apologies if I used the wrong terminology.

Not really, there was a workaround in that thread that I’m not sure worked. This will only happen after a deploy, so a roborio reboot will fix it.

1 Like

Ah ok, no worries! Yea, vocab is important for some stuff like this, but description works just fine too, and we’re all learning!

I’d probably start with Jacob’s guess, seems most reasonable.

“No robot code” simply means the .jar on the roboRIO isn’t running in a way that keeps up communication with the driver station. It could imply that the .jar never made it there. It could also imply that the .jar made it, but is encountering some error at runtime causing it to stop/restart constantly, which would prevent proper DS communications.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.