TalonSRX not working only during joystick drive

Technical Electrical
1

I’m having a bit of an odd problem with some Talons. When I try to drive the robot using a joystick (an Xbox controller to be precise), only two of the motors will drive at the desired speed. The other ones will limp along at a very slow speed or flat out refuse to move.

Currently I’m using a test bot that only has four talons connected, and they are all being used on the drive. There are currently no encoders, gyros, or any sensors hooked up to the robot. The talons are connected via a canbus, which is appropriately connected to the RoboRIO and PDP. All four talons are visible in the web interface, and they all have unique IDs. I can flash the lights on all four talons, and the lights flash on the appropriate physical device that matches the programmed talon. I have checked the canbus wire connections. The talons have all had their firmware updated to 2018 versions, and the roboRIO has been flashed.

The oddest part is that when I wrote a tester class that directly drives one motor at a time at a specified percent output, that motor works just fine. All four motors drive perfectly when using this class.

I have four mecanum wheels attached to a CIM each. I have tried using the WPI mecanum drive classes, the basic arcade drive classes (abandoning mecanum functionality in hopes of just getting joystick control but alas, no dice), and my own mecanum drive class. They all had the same problem. The robot is currently propped up on blocks so that I have a good view of how each wheel is moving.

Help and suggestions for troubleshooting would be appreciated!

2

Have you physical disconnected the motors from power one at a time to see if they’re all going in the right direction?

3

Do you mean while running the joystick input? I have not. The issue is not with the direction, they are all running in the correct direction when they run. The problem is that they aren’t running at all/are barely moving when full power is being applied.

4

When you drive them at full speed, do all Talons have solid lights? Should be either red or green.

5

Have you calibrated your talons?

6

Can you display/watch/query the actual power commanded to the Talons in real-time, i.e., display at the place the Talons are called after all processing?
Feedback on the dashboard.

Are there calls to the Talons from multiple places that might be occurring simultaneously and interfering with each other?

7

Try going through the web interface and disable the forward/backwards limits for the talons associated with your drive motors. I had a similar problem this year where my left motors would refuse to go forward, but worked completely fine going backwards. This problem is associated with a short somewhere in the talon that would enable the limits even if you haven’t enabled them.

8

On that note, you might want to factory reset your talons to make sure there aren’t any persistent settings (like limit switches) that are preventing use.

9

Yes. I’m going to give a brief update here because the problem has “mutated” so to speak. I reformatted the RIO a second time, and installed a “blank” version of a robot project that only contained the simple arcade drive using DifferentialDrive from the WPILIB.

This appeared to work, although I was getting an error message along the lines of “Differential Drive: output not updated often enough”. I switched my differential drive to a MecanumDrive (because the robot has mecanums installed, so we need to be able to strafe) and while the robot is now driving mostly correctly, I am still getting that error.

Additionally, despite having a “dead zone” programmed in (to ensure that the joystick not returning to exactly zero does not cause the robot to move when unwanted), the robot wheels spin at random and don’t stop. However, this doesn’t happen continuously. Sometimes it happens immediately after deploying and enabling, sometimes it starts happening after I’ve been driving for a few minutes, sometimes I can drive around for a bit with no problems at all. The “output not updated often enough” error message persists.

This error message seems to be fairly common in FRC, so I’ve looked it up on ChiefDelphi and the FIRST forums, and here’s what I’ve done to try and resolve it:
-Installed a blank version of the code as mentioned above. You can see the simple code currently being tested here: https://github.com/frc1711/clean-robot/tree/master/src/org/usfirst/frc/team1711/robot

-Obviously I am using WPI_TalonSRX as mentioned in the TalonSRX user manual, because I cannot use a MecanumDrive object without that class

-Updated Talon firmware

-Set a default command in the DriveSystem class

I don’t want to turn off the motor safety helper if I can help it. Firstly, this is FRC and usually anything that can go wrong does, and I prefer to have built in safety measures to prevent the robot from “going wild” (note: this has happened to our team in past year’s when someone wrote a custom drive class. The custom class worked very well, but during one match there was some sort of timeout issue and the robot spun around wildly. IMO, this is dangerous, so I’d like to keep the motor safety on). I realize that this will prevent the error message from occurring, but it won’t solve the underlying issue.

Any suggestions are appreciated!

10

I did output the commanded power to the Talons to the DS, and the commanded power was matching my joystick movement yet the Talons were not moving. I did just post an update below about the current state of the problem as well. Notably, I installed a “clean” version of a robot project, and issues persist. There are no multiple calls that in the clean version that I have seen. https://github.com/frc1711/clean-robot/tree/master/src/org/usfirst/frc/team1711/robot

11

What exactly do you mean by calibrated? The TalonSRX user manual makes no reference to calibration other than w.r.t. PID loops (which I’m not currently using).

12

No calibration, but a factory reset will clear out any persistent Talon internal settings that may be left over from a previous use.
Some teams have run into odd issues and a factory reset cleared them.

13

Have you checked to see if your joysticks aren’t outside of the deadband zone while in their resting state? Perhaps they need to be calibrated (Windows comes with a joystick calibration program).

14

Forgive me if you’ve already done this, perhaps write a one-page “really dumb” program. Don’t start with joysticks, set the speeds to 0.2, slow, and work up. Get that to work. Troubleshooting is a lot easier if you start with something that works.

15

I did do this, which is what I meant by “running the motors one at a time”. I eventually graduated to pressing a button that caused all four motors to run at 0.5 speed or so. This seemed to work fine.

16

The odd thing is that it’s often just one wheel running, frequently very quickly. This is something that the code should never be asking the robot to do, regardless of unexpected uncalibrated input.

17

Check to see if your motors are going in the same direction,the quick way to check is to switch the polarity on 1 motor by connecting red to black and black to red

Sent from my iPhone using Tapatalk

18

Do you mean relative to each other? I have tested each motor individually, and set the boolean isInverted in the Talon object to true when appropriate (one side is wired in a mirror image from the other).

19