Hello. We migrated our 2023 project over. Installed the libraries. But lots of errors. Will start with: Where are the sensors in phoenix 6?
Thanks. I looked there. I can’t see where sensors would be in Phoenix 6.
I did find phoenix6.hardware.WPI_CANcoder; but I can’t find any of the other ones… absolute sensor range, configuration etc…
Here’s is a link to their API docs (which is linked off the migration guide page you read already).
You can search for each thing you need and find what package it’s hiding in.
For example, that CANCoderConfiguration says at the top it resides in com.ctre.phoenix6.configs
Thanks. Appreciate it. Is there anything I can enter the Phoenix 5 into and get the Phoenix 6 equivalent? For example, I cant find MagneticFieldStrength. and AbsoluteSensorRange still comes up as error?
Not really. You need to figure out what you needed from the packages, and see if it’s still needed in Phoenix6.
Phoenix6 has a much different API, not everything that was there is there still.
For example, from their docs about MagneticFieldStrength
This device's Phoenix 5 API is deprecated for removal in the 2025 season.
Users should update to Phoenix 6 firmware and migrate to the Phoenix 6 API.
A migration guide is available at
https://v6.docs.ctr-electronics.com/en/stable/docs/migration/migration-guide/index.html.
If the Phoenix 5 API must be used for this device, the device must have 22.X firmware.
This firmware is available in Tuner X after selecting Phoenix 5 in the firmware year dropdown.
I certainly appreciate your help. It seems like a useful document. But I am kind of in a I don’t know what I don’t know situation. I know the phoenix 5 works. But I don’t know how to tell what the equivalent is in Phoenix 6, or if phoenix 6 has packaged in in a different way. We do not have the luxury of a coding mentor.
The link Joe provided up here is really your best bet. It (and it’s sub-pages) outline all the major changes to the API between phoenix 5 and 6.
Highlighting this from the top of that page:
Thanks so much for the help. I will keep at it. Appreciate the resources.
Lets ask a different question. Why are you using MagnetFieldStrength? Can you delete it? That seems like a pretty niche feature that seems surprising that someone without a lot of experience would be using.
Did you copy and paste code from somewhere else? Did wherever you got the code from already update for Phoenix 6?
MagnetFieldStrength was renamed to MagnetHealth, and the type for AbsoluteSensorRange is AbsoluteSensorRangeValue. All the enum types in Phoenix 6 can be found in the API docs for the StatusSignal getters and the configuration objects.
1 Like
Thanks everyone. Been chipping away at this. Worked through this. Right now the biggest hang up is pathplanner. Tried setting it up with Build an Auto | PathPlanner Docs
no matter what I do configureHolonomic is not reconciled.
Your method call doesn’t match the signature in their API.
Their documentation is pretty solid, and they provide example code that you can use as a reference.
Thanks. I used their sample code. Still can’t seem to reconcile the configureHolonomic. Do I need to do anything here ?
In your code, you need your arguments you’re passing to match what is expected.
Here is the sample code in their documentation:
// Configure AutoBuilder last
AutoBuilder.configureHolonomic(
this::getPose, // Robot pose supplier
this::resetPose, // Method to reset odometry (will be called if your auto has a starting pose)
this::getRobotRelativeSpeeds, // ChassisSpeeds supplier. MUST BE ROBOT RELATIVE
this::driveRobotRelative, // Method that will drive the robot given ROBOT RELATIVE ChassisSpeeds
new HolonomicPathFollowerConfig( // HolonomicPathFollowerConfig, this should likely live in your Constants class
new PIDConstants(5.0, 0.0, 0.0), // Translation PID constants
new PIDConstants(5.0, 0.0, 0.0), // Rotation PID constants
4.5, // Max module speed, in m/s
0.4, // Drive base radius in meters. Distance from robot center to furthest module.
new ReplanningConfig() // Default path replanning config. See the API for the options here
),
() -> {
// Boolean supplier that controls when the path will be mirrored for the red alliance
// This will flip the path being followed to the red side of the field.
// THE ORIGIN WILL REMAIN ON THE BLUE SIDE
var alliance = DriverStation.getAlliance();
if (alliance.isPresent()) {
return alliance.get() == DriverStation.Alliance.Red;
}
return false;
},
this // Reference to this subsystem to set requirements
);
Your code you posted looks different.
Notice specifically, before the PID Constants get passed there is a driveRobotRelative method and then the PID config. Your code doesn’t do that.
Here is the link to the actual example code they have in github, with the Autobuilder.configureHolomic() call.
You should try to make your subsystem look like their subsystem so it will behave similarly.
Awesome. Thanks so much for taking time with these questions. That cleared the configureHolonomic… which we were really stuck with. I noticed the linked code is different to the one posted. I copied the linked code in
Constants.Swerve.pathfollowerconfig, shows an error with Swerve
Their code has a Constants file, with a static class named Swerve, that has an object called pathFollowerConfig.
If you don’t have that, you’ll have an error.
Ok. Thanks. Appreciate the help. We were really stuck. I put the static class Swerve into our constants file. But pathFollowerConfig still does not reconcile.
Put your latest code in Github or somewhere, can’t really help much more without seeing it.