Robot continues to move after input is stoped

[Muskmelon]

We have encountered a strange problem when running our robot. We will run a motor on the robot and it will continue running after we stop giving it input. If the robot is disabled the motor stops but when enabled again it continues this behavior. The only way to stopp it is by power cycling. We don’t believe it to be joystick drift as it has happened with robot systems that run autonomously and inputs that use buttons. We have seen it happen with falcon 500 motors and cim motors ran off a talon SRX with a ubob to a through boar hex Encoder. We appear to maintain coms throughout the occurrence. This also seems to happen randomly as far as we can tell, it hasn’t happened enough times to determine a pattern. Has anyone encountered a similar problem. We are trying to determine if the problem is hardware or software. I personally don’t believe it to be hardware because in past experiences bad hardware brakes things less subtley.

[frog]

Have you checked your controllers with https://gamepad-tester.com/ ? You did say it happens on auto so that is strange.

[NewtonCrosby]

Nearly a 100% likelihood it’s software.
Does the problem persist if you merely restart the robot code, rather than fully power cycle the robot?

Putting your code on github may help us figure out the software issues. Diagnosing the software issue become more difficult without context, timebased, command-based, programming language, etc.

[Muskmelon]

Yes thats what I think as well though I’m the electrical guy so I might be a bit biased. I’ll see if I can get the programming guys to post there stuff.

[jepperson]

Your coders probably did something like this in their drivetrain code in the periodic subsystem function

RobotContainer.differentialDrive.arcadeDrive(leftJoystick, rightJoystick);

they need to do something like this

if (Math.abs(leftJoystick) > deadband || Math.abs(rightJoystick) > deadband) {
RobotContainer.differentialDrive.arcadeDrive(leftJoystick, rightJoystick);
} else {
  RobotContainer.differentialDrive.arcadeDrive(0,0);
}

You might also want to put an override boolean if you also haven’t laid out your command project properly for autonomous commands

[FRC6302]

Have you updated your WPILib/Rio to the lastest versions? This was a bug in a previous version I’m pretty sure

[ExploitSage]

This is likely a software issue. If you could share your code (preferably on GitHub if its not LabVIEW).

For instance, if you are using Command Based, you may not be stopping the motor when the command ends. Your motor would then continue with its last instruction/speed until another command “takes over” and changes it. So best practice is generally to have some kind of “stop” call in the end() method of commands or to have a default command for the subsystem that stops the outputs.