After writing this, I realize I never asked an actual question, so I’ll just put this at the top. Is there a specific way of setting up democat’s swervelib in order to use CANcoders for the steer encoders?
Hello. I have recently updated our swervelib to democats version and when I deployed the code, it said like CAN ID 10-14 could not be found and that kHalleffect() and kvoltage(), and a few others failed to execute.
However, those CANids belong to our CANCoders, which would explain why it wasn’t too fond of using what i assume to be sparkmax methods. Took me the day after to realize why that happens, which is why I do not have errors and logs.
Regardless, the problem I am now facing is how to I tell the code that it is using CANCoders. The closest thing I could find in the lib is public MkSwerveModuleBuilder withSteerEncoderPort(int encoderPort, String canbus) { this.steerEncoderPort = encoderPort; this.steerEncoderCanbus = canbus; return this; }
Problem is, I’m stuck on what String canbus is looking for.
Not necessarily an answer to your “how do I do this” question, but I can at least answer about thar method parameter. canbus is the name of the bus (if using a CANivore). That method is actually overloaded so you can use the version thar doesn’t require that parameter and it’ll just use the default ("")
********** Robot program starting **********
NT: could not open persistent file '/home/lvuser/networktables.json': No such file or directory
NT: Listening on NT3 port 1735, NT4 port 5810
NT: Got a NT3 connection from 10.46.92.73 port 34456
NT: CONNECTED NT3 client 'NT3@10.46.92.73:34456' (from 10.46.92.73:34456)
NT: Got a NT3 connection from 10.46.92.206 port 49897
NT: CONNECTED NT3 client 'NT3@10.46.92.206:49897' (from 10.46.92.206:49897)
Failed to set NEO idle mode: kHALError
Error at com.swervedrivespecialties.swervelib.rev.RevUtils.checkNeoError(RevUtils.java:12): Failed to set NEO idle mode: kHALError
[CAN SPARK MAX] IDs: 12, WPILib or External HAL Error: CAN: Message not found
[CAN SPARK MAX] IDs: 12, Unable to retrieve SPARK MAX firmware version. Please verify the deviceID field matches the configured CAN ID of the controller, and that the controller is connected to the CAN Bus.
[CAN SPARK MAX] IDs: 27, The firmware is too old and needs to be updated. Refer to www.revrobotics.com/REVLib for details.
Failed to enable voltage compensation: kHALError
Error at com.swervedrivespecialties.swervelib.rev.RevUtils.checkNeoError(RevUtils.java:12): Failed to enable voltage compensation: kHALError
Failed to set NEO current limits: kHALError
Error at com.swervedrivespecialties.swervelib.rev.RevUtils.checkNeoError(RevUtils.java:12): Failed to set NEO current limits: kHALError
Failed to set NEO encoder conversion factor: kHALError
Error at com.swervedrivespecialties.swervelib.rev.RevUtils.checkNeoError(RevUtils.java:12): Failed to set NEO encoder conversion factor: kHALError
Failed to set NEO PID proportional constant: kHALError
Error at com.swervedrivespecialties.swervelib.rev.RevUtils.checkNeoError(RevUtils.java:12): Failed to set NEO PID proportional constant: kHALError
Failed to set NEO PID integral constant: kHALError
Error at com.swervedrivespecialties.swervelib.rev.RevUtils.checkNeoError(RevUtils.java:12): Failed to set NEO PID integral constant: kHALError
Failed to set NEO PID derivative constant: kHALError
Error at com.swervedrivespecialties.swervelib.rev.RevUtils.checkNeoError(RevUtils.java:12): Failed to set NEO PID derivative constant: kHALError
Failed to set NEO PID feedback device: kHALError
Error at com.swervedrivespecialties.swervelib.rev.RevUtils.checkNeoError(RevUtils.java:12): Failed to set NEO PID feedback device: kHALError
Unhandled exception: java.lang.IllegalArgumentException: Title is already in use: Current Velocity
Error at com.swervedrivespecialties.swervelib.DriveControllerFactory.addDashboardEntries(DriveControllerFactory.java:11): Unhandled exception: java.lang.IllegalArgumentException: Title is already in use: Current Velocity
The robot program quit unexpectedly. This is usually due to a code error.
The above stacktrace can help determine where the error occurred.
See https://wpilib.org/stacktrace for more information.
at edu.wpi.first.wpilibj.shuffleboard.ContainerHelper.checkTitle(ContainerHelper.java:186)
at edu.wpi.first.wpilibj.shuffleboard.ContainerHelper.precheck(ContainerHelper.java:163)
The startCompetition() method (or methods called by it) should have handled the exception above.
at edu.wpi.first.wpilibj.shuffleboard.ContainerHelper.addDouble(ContainerHelper.java:106)
at edu.wpi.first.wpilibj.shuffleboard.ContainerHelper.addNumber(ContainerHelper.java:102)
at edu.wpi.first.wpilibj.shuffleboard.ShuffleboardLayout.addNumber(ShuffleboardLayout.java:69)
at com.swervedrivespecialties.swervelib.DriveControllerFactory.addDashboardEntries(DriveControllerFactory.java:11)
at com.swervedrivespecialties.swervelib.DriveControllerFactory.create(DriveControllerFactory.java:21)
at com.swervedrivespecialties.swervelib.SwerveModuleFactory.create(SwerveModuleFactory.java:47)
at com.swervedrivespecialties.swervelib.MkSwerveModuleBuilder.build(MkSwerveModuleBuilder.java:222)
at frc.robot.subsystems.DrivetrainSubsystem.<init>(DrivetrainSubsystem.java:121)
at frc.robot.RobotContainer.<init>(RobotContainer.java:82)
at frc.robot.Robot.robotInit(Robot.java:21)
at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:106)
at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:343)
at edu.wpi.first.wpilibj.RobotBase.startRobot(RobotBase.java:433)
at frc.robot.Main.main(Main.java:13)
Warning at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:358): The robot program quit unexpectedly. This is usually due to a code error.
The above stacktrace can help determine where the error occurred.
See https://wpilib.org/stacktrace for more information.
Error at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:365): The startCompetition() method (or methods called by it) should have handled the exception above.
[phoenix-diagnostics] Server shutdown cleanly. (dur:0)
[phoenix] Library shutdown cleanly
pure virtual method called
terminate called without an active exception
You’re attempting to use a SparkMax with CAN ID 12 somewhere and it doesn’t exist on the network. Either you have a break in the CANbus somewhere, that device has the wrong ID configured, or your reference in code is incorrect.
The SparkMax with CAN ID 27 needs a firmware update.
I suspect all those “checkNeoError” lines are related to number one. The shuffleboard error/stacktrace is odd to me, but im curious if it goes away after fixing the other two.
Hello, we have been trying to get the @democat swervelib working on our robot and have been having some issues with the offset calibration process resulting the wheels aligned to the offset values rather than to forward (0 degrees). I saw another thread that discussed BootToAbsolute as something the library uses when configuring the CanCoders, but was wondering how that factored into the usual process of aligning the absolute encoders or if there was something we needed to do differently.
We had previously used the original unmaintained library and are able to correctly calibrate it on this robot.
Thanks for any help!
Not sure what your usual process is, so I’ll just outline the full thing below:
In code, set the offsets to 0 and deploy.
Power cycle the robot.
Open Phoenix Tuner.
Rotate the modules until the bevel gears on the modules face the same way (for us it’s to the “left” of the robot). The wheels should be parallel to the side of the robot.
Use Self-Test Snapshot on the cancoders to get the reported absolute position of each cancoder. In code, put the absolute position into the offset degrees for each module.
Deploy.
Power cycle the robot.
Zero the gyro and make sure the robot drives forward!
We are trying to make this procedure work on our MK4i swerve but our front right module will invert the direction of the drive motor every so often such that it alternates between running in the right direction and then in the wrong direction. It seems to invert when we switch between rotating, driving sideways, and then back to front as if the optimization on the direction goes the wrong way at times. We’ve retiried this procedure half a dozen times and keep getting the same result, even when we try negating the offsets instead. Has anyone ever experienced this before?
We aren’t experiencing any other issues with the robot that we can think to look for.
As another data point, we have mk4 modules on another practice robot and it is working.
The democat SDS library code constructs the motors and the problem happens in robot and field oriented mode. We have the robot on blocks, so we aren’t actually moving.