[Peter Johnson]

It sounds like a crash, although it's hard to know for sure without a NetConsole dump (which should print something if this happens). Assuming it's a crash, I'll explain what's likely going on. There's a workaround (reimplement the PIDController class in Python), but naturally that's a bit ugly. I don't have a real fix at the moment, although I'll try to reproduce this locally.

Basically the problem is that hot reloads on the cRio VxWorks OS are a hack with resultant ugly corner cases, mostly because both Python and WPILib don't have good cleanup code. The hot reload implementation will be much cleaner and work much better on the 2015 control system (which is based on Linux instead of VxWorks), as it will be straightforward to restart the entire robot process (yes, this means that we can get really fancy and auto-restart immediately on file edits, without even a button press).

In short, when you set up a PIDController:
- RobotPy's PIDController is a wrapper around the WPILib C++ PIDController class.
- The WPILib C++ PIDController class uses the WPILib Notifier class and asks for the Calculate callback to get called every X ms.
- The Notifier class uses the FPGA timer and low-level interrupts to call back into the PIDController.

When you do a hot reload, the RollbackImporter tries to delete all of the loaded modules, and all of them are reloaded the next time your code imports them. The modules include wpilib itself, and I'm guessing that for some reason the Notifier itself or the PIDController callback is not getting cleaned up properly, and when the next timer tick comes along X ms later, the interrupt handler references a dangling pointer, resulting in a crash. It's also conceivable a race condition exists somewhere in the cleanup process.