|
Re: Using a separate thread for driving motors?
I would recommend not moving your drive code to a separate thread, because it is easy to create lots of subtle bugs this way, such as race conditions or deadlocks (less likely in robot code, but still possible).
The motor safety timer (ie. watchdog) also exists for a very good reason. If you run your drive code in a separate thread, and the main robot thread crashes, the robot will not stop like it is supposed to, possibly causing a runaway robot (edit: It will still stop when you press disable, but what I meant was that you might not be able to stop it quickly if the robot stops responding to joystick inputs and you do not realize it immediately).
My recommendation is that you figure out what part of the code is taking a long time to execute (and causing watchdog timeouts), and possibly move that to a separate thread (likely candidate: vision processing). I would look at Jeff's suggestions and try to see if you can find the root of the problem. I would not disable the safety until you have thoroughly examined your code, because the timeouts are likely a symptom of a real problem that could make your controls laggy or unresponsive.
If you do move code to a separate thread, make sure you understand well the concepts of multithreading, because threading bugs can be a huge pain to track down, especially under pressure at a competition.
__________________
2016 North Shore District - Semifinalists and Excellence in Engineering Award
2015 Northeastern University District - Semifinalists and Creativity Award
2014 Granite State District - Semifinalists and Innovation in Control Award
2012 Boston Regional - Finalists
Last edited by Ben Wolsieffer : 03-18-2015 at 05:40 PM.
Reason: Clarify one of my points
|