Using a separate thread for driving motors?
 

After being plagued with issues at CVR, with MotorSafetyHelper timeout exceeded errors, I moved all drivetrain calls to a separate thread.

Has any team successfully, but the robot drive code into another thread, to prevent motor safety helper timeout? Or other tips to prevent from happening.

Re: Using a separate thread for driving motors?
 

You could lengthen the timeout from the default of 0.10 seconds to something less touchy... like 0.21 seconds. A lot of teams just disable it altogether; safety is such a pesky thing.

Are you sure you're setting the motor values in every iterative pass?

Are your iterations taking more than 0.02 seconds to execute? Are you having to do a lot of computations (camera processing)?

Are you sending too much data to the dashboard (or too often) and having the communications jam up on you?

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.

Re: Using a separate thread for driving motors?
 

But won't the FMS still disable the drive motors even if motorsafetyhelper is disabled?

Re: Using a separate thread for driving motors?
 

Yes, assuming you press the e-stop or disable button, but that might not happen immediately when someone realizes the robot is no longer responding to their inputs, especially while practicing. Admittedly, disabling the watchdog is not that big a deal safety wise, but it is more important in discovering that code is causing the robot controls to not run as fast as they should be.

Re: Using a separate thread for driving motors?
 

Do you know this for a fact or just theorizing here? If the main robot thread actually crashes, the HAL + FRC firmware disable all outputs, right?

I'm not deeply familiar with these concepts. Maybe somebody could comment with a little more authority than I.

Re: Using a separate thread for driving motors?
 

Sorry for the misunderstanding: I meant that it will run away until you realize what is happening and press disable/e-stop, which isn't that big a problem.

Re: Using a separate thread for driving motors?
 

But I still don't think that's the case. I don't believe separate threads outside the main robot thread can keep the robot alive if the main thread has died.

Re: Using a separate thread for driving motors?
 

Yes, your right. I'm more used to working with Java, where this is not the case, but in C++ (which I just realized the OP was using), exiting the main thread does cause all other threads to terminate.

Re: Using a separate thread for driving motors?
 

Jefferson wrote "if the main thread has died", and lopsided98 wrote "exiting the main thread".

So it's not yet clear if you are both saying exactly the same thing. It depends on Jefferson's intended meaning of "died": If the main thread is blocked or busy-waiting for an event that never occurs, it could be considered to have "died" but not "exited".

Re: Using a separate thread for driving motors?
 

Ether brings up a good point. I was thinking about the case where the main thread finished its execution or threw an exception, in which case all other threads would exit.

But if for the main thread locked up without actually exiting or crashing (something that becomes more likely when you start communicating between multiple threads), the other threads (such as the one controlling the driving) could continue executing. Like I mentioned before, the e-stop/disable buttons would still be able to stop the robot in this case.

Re: Using a separate thread for driving motors?
 

OP, would you mind posting your code? I would advise trying to find the root of the problem in the main thread rather than moving drive code out.

Re: Using a separate thread for driving motors?
 

ditto that.

Re: Using a separate thread for driving motors?
 

Good point. I meant exiting the main thread.

I'll throw in with everybody else and recommend finding the root cause of the motor safety errors in the first place.

Re: Using a separate thread for driving motors?
 

This is the code for the robot, except all the camera code was commented out at competition.
https://github.com/Saint-Francis-Rob...367/FinalRobot