Talon issue?

I know its a bit late but… Our lift motors are controlled by talons and when they go in one direction they jut around. When they go the other way, they are normal. We have them named as sparks in our code. If I remember right the motors are red line. Everything should be wired right but I have no clue as to why they do that.

What do you mean by “jut around”?

Are you maintaining tension when going up and down? If not, that could be your issue rather than the talon.

Hello, do you have a github repo of your code? Or a pastebin of your lift code?

If they jut around when it lowers then it might just be gravity and you are decelerating too fast. Look around in documentation for some sort of ramp rate, and you could also try decreasing the value that you set to the motors.

I will get the code as soon as I can.

See if this helps:
https://www.youtube.com/watch?v=NP66fduVBRY at (0:48) I was sending the lift down. It goes down a bit, stops, then continues down. ((we are 3329))

This looks like a mechanical issue.

Does the elevator move freely when not attached to the motor or rope that pulls it?

  • If no, this is your issue, the elevator is binding (or rubbing) somewhere

If yes, does the elevator rope keep tension? See this thread for more info on keeping tension.

Why are Talons named as sparks?

Its how the code was set before. I was not on the team when they first used talons.

The elevator does move freely when we don’t have the motors or their pulleys attached. I will look into it more when we unbag.

Which model of Talons? If SRX, CAN or PWM? Are you using the Spark class? Or are they just named as Sparks?

We are using the talon SR and I believe that it is using a spark class. I do not have access to the code atm so I will check when I can. I do believe it does though.

I just looked at the code and someone has changed it. The code is commented out but here is what it was:

private SpeedController lift = new Spark(4);

the new code is:
private SpeedController lift = new Talon(4);

lift down code:
if(selPref.getbutton(“liftdown”).get()){

lift.set(0.8);

}else{
lift.stopMotor();
}

Have you tested the change? I haven’t used the Talon SRs, only the SRXs, but I’m pretty sure you don’t use the Spark class. The new code should be right.

our robot is bagged so unfortunatly we cannot test it. We have a spare motor that is the same kind along with a roborio. I can try to test it this afternoon.

Thank you for the help and I hope to join you guys at state!

1 Like

Programming a Talon SR as a Spark MAX or vice-versa shouldn’t have any significant impact on robot function. The only FRC-legal PWM motor controller which is significantly different from the others in terms of programming is the Jaguar, because it has a different pulse length to throttle mapping.

Your issue could be that the button used to activate the lift is not depressed enough to transmit a constant true value, resulting in jitter/jutting. I’ve had this issue when using the POV buttons on the XBox controllers we use to drive.

You can diagnose this by looking at the output light on the Talon. If they briefly go orange after flashing red or green this is most likely your problem. Another method to diagnosing your issue could be to output the state of the button in question to either the SmartDashboard or Shuffleboard (I haven’t played around with the latter) by inserting this line of code:

SmartDashboard.putBoolean(“Lift down pressed”, selPref.getbutton(“liftdown”).get());

If this is the case, do you know why WPIlib has two different classes for the Spark and the Talon SR? What is the difference between the two that necessitates separate classes instead of a generic PWM speed controller class?

If it were not for the Jaguar having a different mapping than the others, and some nonlinear motor controller performance of some now obsolete controllers, that is likely what we would have, a generic PWM speed controller class*. Though, I haven’t really dug into the source here; perhaps there are a few percent difference between them, but it shouldn’t be enough to create the issue you were describing. Providing classes for each motor controller also would make it easier to implement any differences which happened to show up later - for example, someone who wanted to write a currentLimiting wrapper might decide to limit some motor controllers to lower current than others, or perhaps account for the slightly different deadband widths.

* As I have not had access to any Jaguars or these obsolete motor controllers in many years, when controlling FRC motor controllers with an arduino, I usually just use the Servo class (or occasionally wrap it) unless I’m looking for specific cycle durations, and don’t worry about whether it’s a Spark Max or Victor SP or Talon SR (or one of the others I don’t actually have on hand).