Falcon detaching itself from Follower

Technical
1

Sup. I’m the lead software on our team. We’re having a weird issue with our Falcons, whereby one of them changes its mode from Follower to PercentOutput, then assigns itself a -16.67% output value after driving a Flywheel (which is also on 2 Falcons, see below)

For context, this is on our drivetrain. We use 4 Falcons on it; two on each side. We use the DifferentialDrive class to actually drive the chassis, but we only send speed signals to the front two - the back ones are in following. So our drive code looks something like this:

//Pseudocode
WPI_TalonFX m_rightFront, m_leftFront, m_rightAft, m_leftAft; 
DifferentialDrive m_drive = new DifferentialDrive(m_leftFront, m_rightFront);
//The above are defined in a separate class but this is just to show

public void robotInit() {
    ...
    //Excerpt
    m_leftAft.configFactoryDefault();
    m_rightAft.configFactoryDefault();
    m_leftFront.configFactoryDefault();
    m_rightFront.configFactoryDefault();
    
    m_leftAft.follow(m_leftFront);
    m_rightAft.follow(m_rightFront);

    ...
    //Skipping some other irrelevant setup stuff
}

public void teleopPeriodic() {
    ...
    //Excerpt
    m_drive.arcadeDrive(m_drive.arcadeDrive(m_joy.getY(), -m_joy.getX());
}

The thing is, elsewhere in our code we drive a flywheel, and doing so (even just manually telling it to go a certain speed) caused the left aft drivetrain motor to just start driving backwards. Upon looking over the self-test snapshot in Phoenix Tuner while it was exhibiting this behavior, we found that the left aft motor had detached itself from following, set it self to PercentOutput mode, and was going at -16.67%. After poring through the entire project, I’m absolutely sure we are not telling it to stop following, and even more sure we are not telling it to move that speed (we never directly send a speed to the back motors, and the double -0.1667 never appears anywhere in the code)

The flywheel is setup as two falcons - a master one following the slave one. We only play with the configuration of these, as well as every motor on our robot, on startup - we never change any settings mid-match and I know there’s no following issues going on.

I’m fairly certain I haven’t programmed anything causing it to do this, but does anyone have any ideas as to why it might suddenly change its settings like this? Maybe a failure mode or something? Thanks.

2

Bumping this thread as we’re still having issues

3

Is the problem repeatable? That is, can you do it again?

I know you say that “you haven’t programmed anything causing it to do this” but if the problem is repeatable (i.e. every time you turn on the flywheel, the left aft motor goes into PercentOutput mode at -16.67%), then the program is almost surely commanding that somehow, although it’s clearly not intentional on your part. Reminds me of one of my favorite Sherlock Holmes quotes, " … when you have eliminated the impossible , whatever remains, however improbable, must be the truth."

I would check to make sure you don’t have another speed controller in your code using the same CAN ID (although that should result in a code error), would look for all occurrences of m_leftAft in your code, and would start commenting out huge chunks of the flywheel control code to see if commenting out one of those chunks makes the problem no longer occur when manually controlling the flywheel.

Do the flywheel speed controllers have distinct CAN IDs from the ones used for the m_leftAft drive motor?

4

We had a similar issue, which we never really pinned down. For us, what seemed to cure it was to never configure anything on the follower. That is, we were configuring a bunch of pid constants and stuff, and it seems as though there are some configuration commands that will remove follower mode. That is, we had something like
m_follower.follow(m_main);
m_follower.configAThing().
m_follower.configAnotherThing();
When we reduced the code to m_follower.follow() and no other use of m_follower, it started working.

As I said, we never really nailed it down; it’s entirely likely that it was something else altogether that fixed it. But I thought I’d share in case it helps.

5

We had a similar hardware issue. When the follower loses power or browns out it stops following. Wiggle the power wires all the way from the PDP to the controller to see if you can recreate the issue (safely!).

One software bandage (at least for the Spark Max) is to store your parameters in nonvolatile memory so you have the proper parameters at power up. You really want to fix the wiring though.

1 Like
6

My team found that if you set the follower motor manually to percent output mode anywhere in the code, it would stop following the leader. The solution was to use the Follower control mode so it follows the next instruction given my the leader.

I.e.
m_leftFollower.set(TalonFXControlMode.Follower, /* ID of leader motor /);
m_leftLeader.set(/ Insert control mode and demand here */);

Hopefully this fixes your issue.

7

I can’t speak to the exact details (was not hands-on debugging) but we encountered a similar issue during Comp yesterday. Our band-aid fix that worked was simply calling the follow() method every loop. It’s not ideal but seems to do the trick.

8

Hey,

So I can’t speak to that weird 16.67% thing, but we had a really similar issue with our drivetrain and our flywheel. We used the .follow() method on our drivetrain and the drivetrain looked like it was working right, but the issue was that the master motors would spin, but the followers wouldn’t be getting any current. We only realized this after I decided to make sure that the drivetrain was working right by displaying values to SmartDashboard. Even though our drivetrain looked like it worked fine, the followers would just get pulled along at the same speed as the masters without getting current, similar to an issue we had with our flywheel. What we did to fix this was, like someone else mentioned, use the follower control mode for the talons. In an initialize method somewhere, use talonFollower.set(ControlMode.Follower, talonMaster.getID()). This makes sure that the talon follows the master properly. If they’re supposed to be spinning in opposite directions, my suggestion would be to take the motors off, and use the setInverted() for the follower method to make sure that, when you set the master to spin forward, they both spin the same way. Hope this helps!

9

Like this:

ShooterMap.LEFT_SHOOTER_FALCON.setInverted(false);
ShooterMap.RIGHT_SHOOTER_FALCON.set(ControlMode.Follower, ShooterMap.LEFT_SHOOTER_FALCON.getDeviceID());
ShooterMap.RIGHT_SHOOTER_FALCON.setInverted(InvertType.OpposeMaster);
1 Like
10

We’ve also run into this issue early on in the season with our drivetrain talons where the slaves would occasionally go into percent output mode. Not sure another way to resolve it so we ran with this bandaid fix.

11

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.