Hello, our team is running swerve and we seem to be running into an issue. Sometimes when we enable the robot, it will randomly start driving by itself in one direction even if we do not touch the controllers. However sometimes it works randomly. Here is an example video (We had to immediately disable to start it from moving. The other way to stop it from moving seems to be pressing a random button). Here is my code: code Does anyone know what the issue might be?
edit: RSL now works
Have you ruled out any drift on your joysticks? Sometimes with use this happens. Put your robot up off the floor , enable ; then check in driverstation in the controls section if it thinks its receiving input. If so that controller is probably bad.
You can check drift without even enabling the robot, live joystick data is in DS always, just make sure you pick the correct device if you have multiple USB controllers.
Reason I note this is if you haven’t checked the controller out and a joystick is faulty it could also enable other components if a faulty button or trigger is tied to another mechanism besides driving.
The downside is the DS by default doesn’t show you number values, just the sliders. On any machine with Internet you can test joysticks with Hardware Tester and get really fine details about the joysticks, triggers and buttons. It also helps you identify the mode the controller is in X-Input v D-Input and what difference it makes. Really useful with the default Logitech controllers for FTC
DS shows number values when you hold your curser on the sliders.
… Never in my 10 years did I do that, even by accident. Mind blown. Okay so DS can give you that as well. Good news!
yes we have ruled this out.
Next I’d suggest a deadband but you have that already, I briefly looked at the code. Very organized!
The note about the RSL is interesting. I couldn’t see it well in the video but what mode are you enabling into? Auto or teleop? Id assume since you mention not touching the controls it’s teleop
Yes the controller is not touching anything and it happens in teleop. This issue has already happened multiple times and we still can not figure out why.
Next question, the RSL not turning on, is it because it’s on the flash and you estop it right away so it never turns back on or it never turns on at all even if it was allowed to keep going?
Ideally put the bot up on blocks so you can do it over and over and let it stay in that fault state longer so you can inspect it better. It seems like if the RSL is failing the RoboRio may be failing.
Also RoboRio 1 or 2?
This is curious. The RSL should be on and solid when disabled. It switches to a blink when enabled. Are you sure you aren’t just seeing it go out as part of the enable blink, then come back to solid when you disable?
Can you provide a driver station log that includes an occurrence of the issue?
Looking at the code, one thing to look into is that the Drivetrain subsystem periodic() function runs all the time, even in disabled, so it’s possible for the calculations to become numerically unstable?
The key when debugging problems like this is to collect as much data as possible regarding the robot state. Log as much as internal state as you can using the SmartDashboard class. You can plot it real-time using Glass, or use DataLogManager to save it to an on-robot .wpilog file that you can download and review using AdvantageScope.
Robo rio 2. We just fixed the rsl by disconnecting and reconnecting. I will update the main post.
Does this happen when you power the robot for the first time and then enable it? Or does it happen when it already had been enabled and disabled once, then when you re-enable it you encounter this issue?
If it does not happen at the first time you power up the robot, seems like an issue related to you not being able to set the global variable chassis speeds to zero correctly and since the chassis speeds will be applied as the module states in DrivetrainSubsystem’s periodic as @Peter_Johnson mentioned, your robot might continue using the last value that was set to that variable.
I haven’t taken a deep look into your code but that is the first thing that caught my attention.
As a quick fix, you might consider setting the chassis speeds value to 0 in autonomousInit and teleopInit. If you want to fully debug this, you should log the data as it had already been recommended.
Keep in mind that my recommendation would only be helpful if you’re %100 sure about your inputs working fine.
I simulated your code using the basic wpilib simulation, and with the simulated joystick I couldn’t find anything obvious that could cause this.
However, It seems like the code in github doesn’t compile, (the “ScoreWithBalanceAuto” command does not initialized the wirst subsystem), so the code in github might be different from the code running on your robot.
When we first power the robot and upload code then enable, this issue does not happen. But once we disable then enable again this issue sometimes comes up. If we disable, keep power on, and upload new code then enable the issue also comes up. Right now seems like the only way to not have this issue is power off the robot then power on and upload code each time which is a hassle.
Also we just had a similar issue today morning with the arm where we were testing set positions and afterwards we disabled. We made sure to zero the arm but when we enabled again it immediately went to one of the setpositions we had tested despite us not pressing any buttons.
Yes I think Ill try to set the chassis speed values to 0 once I have access to the robot because I am not sure how to fully debug right now without further research. This is my first time programming and I am the sole programmer on my team without mentors who have technical experience so Im still struggling with this lol.
yeah, I just realized I uploaded the version with broken autonomous. The teleop and rest of the stuff should be exactly the same. I just updated the code on github to the current version where I disabled the parts of the auto that was not working. Sorry
The arm issue should be related to you using the internal position controller of TalonFX. The last target position you set for the controller, will be kept if you are not sending a 0 volts / percent output request to the motor controller like motor.set(ControlMode.PercentOutput, 0); (phoenix 5)
in the end() method of the command. Disabling the robot will cancel the command, however I believe you don’t have such line in your end() method so that should be the reason why your arm went to that setpoint back again.
We’re having a similar issue with Rev swerve code, not sure as to the cause yet.