Help With A Simple TalonSRX Code Example

[filler1111]

After the CANTalon updated to Talon SRX, we are having trouble using the updated version. We have tried using the example code on the FRC website, but the RobotDrive library was depreciated. Could anybody please help give an example with the TalonSRX being set up, used (especially .set()), and running. We do not understand much about the change, so very basic example or resources would be appreciated.

[ExploitSage]

If you go to the New for 2018 page on the ScreenStepsLive documentation, it outlines the changes with the RobotDrive: https://wpilib.screenstepslive.com/s/currentCS/m/getting_started/l/801080-new-for-2018#c-java-wpilib

Basically there are 3 different classes for different drive types. Tank, Halo, and CheesyDrive would all be under the DifferentialDrive Class, and there there are separate MecanumDrive and KilloughDrive Classes. You should look into the JavaDocs for more details of what options (methods) the classes have/take. http://first.wpi.edu/FRC/roborio/release/docs/java/

I know it is documented somewhere, but I’m not going to go digging for it now. In order to use the CAN Talon with the new RobotDrive replacement classes you need to use the WPI_TalonSRX Class, as it properly tied in to the WPILIB classes and so the RobotDrive objects will take it.

[Bart_Kerfeld]

Sure. Avoiding all fancy stuff for now, here is a snippet of our code for our 3-CIM gearboxes. We use the WPI wrapped classed for the TalonSRX which work with the DifferentialDrive class which is replacing the now deprecated RobotDrive.

WPI_TalonSRX leftMaster = new WPI_TalonSRX(RobotMap.LEFT_MASTER);
WPI_TalonSRX rightMaster = new WPI_TalonSRX(RobotMap.RIGHT_MASTER);
    
WPI_TalonSRX leftSlave1 = new WPI_TalonSRX(RobotMap.LEFT_SLAVE_1);
WPI_TalonSRX leftSlave2 = new WPI_TalonSRX(RobotMap.LEFT_SLAVE_2);
WPI_TalonSRX rightSlave1 = new WPI_TalonSRX(RobotMap.RIGHT_SLAVE_1);
WPI_TalonSRX rightSlave2 = new WPI_TalonSRX(RobotMap.RIGHT_SLAVE_2);

DifferentialDrive drive = new DifferentialDrive(leftMaster, rightMaster);

// This class is constructed in the robotInit method in Robot.java
public Drivetrain() {
    leftSlave1.follow(leftMaster);
    leftSlave2.follow(leftMaster);
    rightSlave1.follow(rightMaster);
    rightSlave2.follow(rightMaster);
}

public void arcadeDrive(double move, double rotate) {
    drive.arcadeDrive(move, rotate);
}

[Oblarg]

Note that if you use the WPI-combatible wrappers in a WPI drivetrain object, you are restricted to open-loop control.

[Bart_Kerfeld]

@Oblarg

Note that if you use the WPI-combatible wrappers in a WPI drivetrain object, you are restricted to open-loop control.

Interesting. Thanks for the heads up. I would have assumed that DifferentialDrive would have refrained from changing the controlMode until its drive method was called. I’ll have to do some reading tonight on the implementation details of the WPI drive classes. Otherwise, it looks like we will be copy/pasting the arcadeDrive method (or implementing our own) this year. Either way, not the end of the world I suppose.

[Oblarg]

@Bart_Kerfeld

Interesting. Thanks for the heads up. I would have assumed that DifferentialDrive would have refrained from changing the controlMode until its drive method was called. I’ll have to do some reading tonight on the implementation details of the WPI drive classes. Otherwise, it looks like we will be copy/pasting the arcadeDrive method (or implementing our own) this year. Either way, not the end of the world I suppose.

The WPILib drive classes act only on the SpeedController interface, which does not have any method for changing the control mode.

A better solution than rewriting the drive classes, however, is to write your own Talon wrapper implementing SpeedController, rather than using the one provided by CTRE. It’s not hard to make one that allows you to use closed-loop control.

[Bart_Kerfeld]

@Oblarg

The WPILib drive classes act only on the SpeedController interface, which does not have any method for changing the control mode.

A better solution than rewriting the drive classes, however, is to write your own Talon wrapper implementing SpeedController, rather than using the one provided by CTRE. It’s not hard to make one that allows you to use closed-loop control.

To be clear, we are only talking about preventing closed-loop control in teleop here though right? For example, using the combination of WPI_TalonSRX and DifferentialDrive will not allow for sending go at this velocity based on joystick position and use encoder and control loop to achieve that setpoint. However, it does not prevent us from having an autonomous mode where we use other closed loop control (MotionMagic, MotionProfile, etc…) with our WPI_TalonSRX instances. Said another way, there is nothing inherent to DifferentialDrive that locks you out of closed loop control elsewhere, but rather you cannot do closed loop control in DifferentialDrive using the WPI_TalonSRX wrapper (you must implement your own).

[Oblarg]

@Bart_Kerfeld

To be clear, we are only talking about preventing closed-loop control in teleop here though right? E.g. it will not allow for sending go at this velocity based on joystick position and use encoder and control loop to achieve that setpoint. It does not prevent us from having an autonomous mode where we use other closed loop control (MotionMagic, MotionProfile, etc…). There is nothing inherent to DifferentialDrive that locks you out of closed loop control elsewhere, but rather you cannot do closed loop control in DifferentialDrive without first implementing your own wrapper.

Correct. You are not prevented from using the other control modes (unless you construct the injected Talon objects in the WPI drive object’s constructor and thus don’t retain any references to them); rather, the WPILib objects themselves are unable to make use of them as they only call the single-argument set() method defined in the SpeedController interface, which the CTRE wrapper implements as using open-loop mode only.