Quote:
Originally Posted by microbuns
I've learned that some teams use a special (not in WPILib) way of scheduling their loop callbacks. I've seen the number 200Hz thrown around occasionally. I believe (at least for C++) that WPILib tries to schedule at ~50Hz. Obviously, tighter control loops would be nicer, but I have 2 questions about this:
- How hard is this to implement? I have tried to look around in WPILib, but I haven't found an obvious way to do so right now.
- How much benefit does it bring? Clearly faster control loops are better than slower ones, but really how much does it add? Are there things you can do with a faster control loop that you can't with the standard ~50Hz WPILib one?
|
We run all of the loops on our robot on a separate thread running at 200hz.
The big benefit of this doesn't really come from the "200hz" part, but the "separate thread". Using IterativeRobot, the update rate is supposed to be "about" 50hz, but it's really inconsistent. The loop is synchronized to driver station packets, meaning that it's waiting on the network in between iterations. Things like writing to the console or sending CAN messages can mess up your timing as well. This can give very strange results, especially if you're relying on consistent timing in your control loops.
That said, there is still a benefit to running loops at 200hz if you're relying on really tight controls (faster update rates will allow your code to respond more quickly to disturbances).
I believe that WPILib gets around these timing issues by updating their built-in PID controller class in a separate thread. However, if you're rolling your own PID code or doing some sort of other logic, you'll want to manually create a new thread to run your control loops so that you can avoid timing issues. Fair warning - multithreading can be really tricky to get right, especially when communicating between threads.