Using a separate thread for driving motors?

[DanG100]

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.

[JefferMC]

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?

[Ben Wolsieffer]

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.

[DanG100]

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

[Ben Wolsieffer]

Originally Posted by DanG100

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

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.

[Jefferson]

Originally Posted by lopsided98

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.

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.

[Ben Wolsieffer]

Originally Posted by Jefferson

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.

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.

[Jefferson]

Originally Posted by lopsided98

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.

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.

[Ben Wolsieffer]

Originally Posted by Jefferson

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.

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.

[Ether]

Originally Posted by Jefferson

I don't believe separate threads outside the main robot thread can keep the robot alive if the main thread has died.

Originally Posted by lopsided98

Yes, your [sic] right... in C++, exiting the main thread does cause all other threads to terminate.

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".

[Ben Wolsieffer]

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.

[connor.worley]

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.

[Ether]

Originally Posted by connor.worley

I would advise trying to find the root of the problem

ditto that.

[Jefferson]

Originally Posted by Ether

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".

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.

[DanG100]

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