|
Re: E-Stop Lag... now part of our arm is broken
We're using C++, but if there is a problem at the FPGA level, it would affect any language.
We've had a few instances where the robot stops responding and latches whatever the last used speed controller outputs were. In all cases, we've used the space bar to disable the robot, so I don't know what the behavior of the e-stop would have been.
A couple times we've gotten crashes when we read the encoders and the WPILib encoder class tries to access the counter. When that happens and we're connected to the robot, we can see the WindRiver error box pop up and point us to that location.
Last night we added a few prints to debug an issue and got some serious lag in our driver control. This was seen by runaway movement of the motor and lack of sensor updates coming back to the dashboard. We don't have any hard evidence of what the problem was, but when we removed the prints things worked fine. We didn't have time to dig in and narrow things down.
So, this obviously doesn't solve your problem, but I just wanted to put this out there so that people can keep an eye out for any similar situations.
|