There are two problems.
- You are in Test Mode.
This means that the WPI/NI software is going to call set() on all your motors controllers.
This is a feature of WPI compliant motor controller classes, which includes the WPI_TalonSRX.
If you don’t want to leverate WPI features, use TalonSRX instead.
Test Mode is documented here…
- You are setting your master output under Test Mode loop.
This appears to override the set calls from DS Test mode, but should not be relied upon since this causes multiple things calling set() on your MCs. This will produce unpredictable results as two callers are changing the output.
Additionally set(0) is likely called on your followers because of .
This means they are in PercentOutput mode, not follower mode.
It seems like a lot of time was wasted because of the following…
Firmware was not updated, or at least, it was not understood if it was updated.
4.1 is not a valid release.
Perhaps you meant 4.11 (the kickoff release), but the community can’t help you if you are not accurate in your reporting.
Start with the hardware bring up section.
Creating an empty project and writing a bunch of lines until you get the result you want is not very productive if you are not familiar with the control system. That’s why our documentation is written the way it is, so you follow the necessary steps in order to prevent these kind of misunderstandings.
Relevant link here…
- Start with our examples.
Since students skip 2 anyway, use our examples out-of-box. Get them working. Then integrate into your project.
Diagnosing future issues
I didn’t see any self-tests in this thread. If a CTRE device is misbehaving, check the DS for errors, and capture the self-test (Tuner) while the behavior is occurring.
This will tell you why its behaving the way it is.
In your circumstance, the follower Talons would show that they are in PercentOutput control mode. That’s because the DS Test Mode feature is setting their values directly. You can leverage this through the SmartDashboard (and similar) interface. But it sounds like that’s not what you want.
Not sure what this means. We don’t have an error like that. Talons do not require a sensor to spin the motors.
I have no reason to believe this. The 2 root-causes above explains the symptoms reported.
Although interestingly, because the DS Test Mode features overrides all LiveWIndow-able actuators, using the regular TalonSRX class for followers is probably advantageous. Or alternatively you should call follow() in your robot loop periodically in case Test Mode is entered.
Either is adequate if you plan on using Test Mode, or want to robustly protect against accidental transitions to Test Mode by an inexperienced DS operator.