Robot locks onto last speed after Limelight looses target

We have been using the Limelight as a targeting system in order to track and move towards targets. We are facing an issue when the limelight loses a valid target, but the robot continues to move. In our code, we use a conditional to set all movement to 0 when there is no target. We have also been able to log and confirm that we are inputting 0 for our drive motors, but the robot continues to move/spin. One things that we did notice is that it was working well before we updated to the most recent WPILib framework. Has anyone encountered the same problem or know how to fix it?

Did you update to 2022.2.1 released last night?

Yes, we think that might be what broke it because it was working fine before we updated it.

1 Like

Can you share your code? Just to rule out any logical issues you may have. (1.8 KB)

The JoystickProcessing and JoystickShaping functions just fix the joystick values, and we are certain they work because they work with normal driving.

You declare a driveTrain field in the class and use it in end(), but I do not see you initialize it anywhere. I suspect you are getting and NullPointerException in end() and the last values set in execute() are still being used. Also, not the different way you access the drive train subsystem in execute.

We fixed that error, but it still is not working

@2022tmiller - Can you put all your code on GitHub and provide a link so that we can see all the code involved? Also, are there any errors in the driver station console?

@Thad_House - Thought you might want to see this since the OP first noticed the problem after applying last evening’s update.

Also, no errors appeared in our driver station

What do you want it to do when the limelight loses lock? The code you posted won’t cause it to stop.

@Joe_Ross - Are referring to the fact that the end() method will not get called because isFinished() is always returning false? I did not notice the isFinished behavior the first time I looked at the code.

However, the execute(), as long as nobody is fiddling with the sticks, looks like it should use 0 for turn and move if there is no target. I could be missing something as the number of functions to walk though before actual output can be a bit difficult to follow completely.

@2022tmiller - It looks like this command may be designed to be the drive subsystem’s default command. However, I do not see it being set as such, nor do I see it being associated with any driver input. Are you sure this is all the latest code? If so, can you point to how this command is getting scheduled.

That’s a big assumption, especially given how poorly some joysticks center.

There’s also a potential issue of using the Talon SRX’s velocity mode with unknown PID constants.

I agree. I think I did see a 0.08 dead band being applied to the input which seems a bit narrow.

I would recommend that you put your robot on blocks so the robot won’t move physically, and get to a point where you can reliably recreate this scenario.

Once you have a repeatable setup, open Shuffleboard and view the Scheduler or Subsystem widgets for the drivetrain.

Observe those and verify what command is being run, then you can trace down exactly what is running while it’s happening.

I just did a quick run through of your code and it looks to me like you’re setting your Talons to velocity closed-loop with a kF value. So even if you set the velocity mode to 0, it will still add kF to the motor output which will make it non-zero.

I’d suggest reading through the closed-loop control doc a few more times to ensure you understand how the velocity control mode is working. As a troubleshooting step to verify this, you could just change to drive with percent output instead, that way when you set to ‘0’ it will stop your motors.

Or, conversely, create a stopMotors() method in your drive train that sets them to ControlMode.PercentOutput with 0 as the mark. That will stop your velocity pid from running.

I didn’t have time to look at your code very closely, so I may be misinterpreting (heads up).

I do not believe that this problem is because of the joysticks since we tried running it without joysticks and encountered the same problem.

@2022tmiller - Have you tried what Newton suggested. I agree with him that it looks like you are using velocity control with a kF value. That could lead to this behavior.

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

We have put our robot on blocks and tinkered with the subsystem widgets and the scheduler, and it seems that setting the motor output in percent mode to 0 works. However, we have encountered a new problem where the left side of our robot is either running at 100% or at 0%. We have tried switching talons in order to fix this, but it has not corrected our issue. We have also tried switching the left and right talons in the code, but the left side still cannot be controlled, so we believe that it is some sort of hardware issue.

We have discussed this issue in another thread: Talon SRXs Extremes - #5 by NewtonCrosby

Did the bad encoder in your other thread also cause this issue?