We have been endlessly trying to resolve this issue, so any help is much appreciated. I know that there were a lot of teams having posted on this same issue, but none of their solution methods worked for us.
We keep getting this error on the devices connected to our Canivore, and although all of our devices run the latest Phoenix v6 software and also have a pro license, we cannot get past this error. We have also checked our CAN circuit and we have all the components needed, as well as the IDs matching in the code.
And also the motors that are not connected to the CANivore (rio CAN devices) are working just fine.
It looks like your Talon FXs are on a CANivore bus, but the name of the CANivore bus isn’t in the error. Where you construct your devices in code, make sure you use the second parameter to specify the CANivore bus name.
I’ll reply if the issue persists after that, thank you for the notice. The code we had before migrating to version 6 did not necessarily specify the canbus as canivore, especially the swerve motors, but it didn’t cause any errors. Do you know whether this is a change in v6?
We don’t currently have the code public on Github but I provided a snippet below. This is from v5 and it seems like we only used to instantiate only the CANcoder with the CANivore CAN bus.
I wouldn’t expect that to work, then, unless you’re re-assigning your mDrivemotor and mAngleMotor variables with a new WPI_TalonFX that contains the CAN bus name.
Is it possible to put your code on Github or possibly give myself or one of the other CTR employees access if it’s a private repo? I think we’re missing something if your code was working without the CANivore name.
Another test is to go back to your old code and verify it works in your hardware configuration. If it does, then we’re missing something in code. If it doesn’t, then I suspect those motors were originally on the RIO bus, but were later moved to the CANivore bus where they’re at now.
The problem is probably about the issue you mentioned and we fixed it by adding the CANbus name, thank you! However, another problem is that version 6 seems to support the CANcoder rotation to only be between 0,1 or -0.5,0.5 Is there any way of converting that to match with our wheel offsets for each module (which are in 0,360 scope) without having to write a calculator code in v6? Thanks again.
The difference between the two is the units each are using.
In Phoenix 5 the CANcoder was primarily in degrees, in Phoenix 6 it’s in rotations.
So all you need to do is divide your degrees by 360 to get your rotation offset.
Or you can use WPI’s degreesToRotations() method.
We solved that issue, however we are having serious problems when migrating from v5to v6 in our swerve code, I can send you the two repos if you would like.
Thus, my question is that whether the support from CTRE will be discontinued for v5 in the 2024 season? We can figure out the migration later in the upcoming offseason if v5 will be available throughout this season.
The plan is to continue to support Phoenix 5 for the 2024 season. Devices present in both the Phoenix 5 and Phoenix 6 API (TalonFX, CANcoder, Pigeon2) are marked as deprecated in Phoenix 5 with the intention of removal in 2025, however that won’t affect usage in 2024. Phoenix 5 in general will continue to be supported for the foreseeable future, just with those devices removed in favor of their Phoenix 6 counterparts.
If you’re running a fully CTR Swerve system, using TalonFXs for the drive/steer motors, CANcoders for steer positioning, and Pigeon 2 for robot orientation, I’d recommend using our Swerve API and Tuner X’s Swerve Generator, as these tools are meant to get Swerve up and running easily and quickly. Feedback on it has been very positive, so I believe it’llLimelight, an integrated vision coprocessor help you as well.
Otherwise, I’d point you to the migration guide we have for porting Phoenix 5 code to Phoenix 6.
