Prevent Burnt Motors - Updated RobotC Joystick Driver

[normalmutant]

Ever disconnected from Samantha and burnt out motors? We from Say Watt?, along with other teams in our area, have experienced it multiple times. We saw that it was a big problem, so we set out to find a solution. After some digging, we discovered that the JoystickDriver.c that all teams using RobotC dutifully include in all of their code is the real source of the problem.

To see our solution explained or download the updated Joystick driver, go to our website post.

[Skinkworks]

Code that performs this function will be added to libftc-util. However, it will be implemented differently in order to avoid editing JoystickDriver.c.

[2010FTC3539]

Code that performs this function will be added to libftc-util. However, it will be implemented differently in order to avoid editing JoystickDriver.c.

We felt that editing the JoystickDriver was the cleanest way to do this. It has several advantages over the other methods that we looked at:

1) It works for every connection type, not only Samantha.
2) This method is extremely simple for new teams to use. It involves changing exactly one line of code.
3) It refrains from adding additional tasks and calculations to the code, causing additional lag. It simply increments a variable.
4) It picks up again the moment the robot is reconnected.

In essence, this is a very simple solution that can be put to use in less than a minute by teams of any level. Additionally, we've been in contact with the RobotC people and we're hoping that they add this fix or a similar fix to the official JoystickDriver in the next release.

[2010FTC2848]

Nice solution!

The only issue we saw with this method is if there's a "start-stop" type circuit in the code. In other words, if you push a button to start something moving, and then push another to stop it, this code does not address that problem.

In this case, a better choice to do the same thing could be to create a "Connected" boolean part of the joystick structure, and then let the user/programmer decide what to do if/when there's a communication loss.

so the teleop code would be

waitForStart();
while (true)
{
  if (joystick.Connected)
  {
     ControlRobot();
  } else {
    StopRobot();
  }

Or, at least that's what we did!

If you're interested, you can find our version of our revised driver online at http://www.technoguards.org/node/407

Please feel free to use/edit/revise as you wish!

[Skinkworks]

I agree completely with 2010FTC2848. Their version of JoystickDriver.c will be included with libftc-util.
EDIT: I realize this completely contradicts my earlier post, saying I didn't want to edit JoystickDriver.c. I changed my mind, thinking that their way is the best solution to the problem.

[2010FTC3539]

Interesting point.

We have updated our version of the driver to include both methods of signaling a disconnect, so that the teams can still use the very simple method of simply changing the single line of code, or use the more advanced method of looking at the variable. Whichever they prefer.

You can find the updated version and information on the variable that we added in the same blog post.

[FTC3053]

Easiest solution: Do work in autonomous, sit still in teleop.


Okay, so that might not work.

Which driver do I use now? I'm inclined to go with the pope's, but say watt and technoguards both certainly know what they're doing as well.