I was not sure about what is the pronlem, so I ignored this this mistake and just went to next step. Then other problems happened, the fisrt one was that I couldn’t use the “Encoder Calibration”. I checked the light, and one of those for was sparking red light. Below is the light:
Not sure if it is the same issue but we had a similar issue. Needed update our rio to 2024 beta first. Then we weren’t able to access the can devices. We tried temporary diagnosics server but found out it doesn’t yet work with 2024 to maintain compatibility with 2023. The solution was to upload code that has the 2024 Pheonix 6 installed and at least one device initialized.
I appriciate your solution, and do you mind to share more about the code because I don’t understand clearly. Do the code need to be a 2024 swerve code, or just a falcon motor code?
Hm… not sure then. The “server” is generally the software component running on the rio, which gets deployed with your code. Sounds like a “beta” but that should be reported to CTRE (perhaps through the wpilib beta test repo on github?)
I don’t have the code available but we used a base code. Installed the 2024 beta version of Pheonix 6 and initialized a pigeon 2. There is something Pheonix installs on the rio or something (I don’t quite understand it myself). If you initialize and CTRE device that uses the libraries then it calls whatever it needs and can communicate with the canbus devices. Once we uploaded new code we were able to see the canbus devices when connected to the rio though usb.
Alternatively for code any 2024 CTRE example that can build and upload to the robot should do the same thing.
The Swerve Generator is much easier to set up than YAGSL, no questions asked.
It was setup in about an hour with very little coding knowledge.
The limitation is having to have all the newest CTRE components so not available to everyone but I think that everyone who has those components should be using it.
Our latest firmware is 24.0.6.0 and latest vendordep is 24.0.0-beta-5.
Based on the Pre Check for the server version being too old, I’m assuming you’re still running 2023 API/Diagnostic Server. You’ll need to image the rio with the 2024 beta image, and deploy a project using our beta API. The examples are all updated to use the beta API so deploying any of them should give you an up-to-date diagnostic server to do the generation on.
I have all the firmware up to date to 24.0.6.0 but when doing encoder calibration it errors with
“Failed to zero cancoder with status: firmware version is not compatible with this version of Phoenix. Make sure your firmware and api major versions match”
Tuner X is version 2024.5.6.0
Edit:
Ended up being vendordeps running beta 4 not 5, however I have a new issue where steer verification never ends.
It spins the wheels and is stuck on the message “running steer test”
Thanks! After changed the software vision to 2024 beta, I successfully generated the project.
I just checked the code, and found the differences between two are that the example project have the pathplanner code in CommandSwerveDrive file, LimelightHelper,
I would use the SwerveWithPathPlanner example (or my improvement below) if that applies to you. The example has more features and that example will likely be updated more often. All you need to do is copy over the TunerConstants.java file and replace it.
It is hard to parse out what specific differences you mean from your message. Phoenix pro will be used by the fused CANCoder line but will automatically default back to the remote CANCoder if not licensed. The specific callout for licensed or not was removed.
I would also recommend my expansion of that example. It improves on a couple of the concepts, adds sysid (hoping to test later today), and has several different controller layouts and speed settings.
Sound cool! I just scan your project, overall I think I will use your project in the future, and I especially love your Limelight support. I recently tested the LL, and found the errors might affect a lot, so wonder if you are planing to use some filter. Moreover, I have questions about PathPlanner and sysid.
Why don’t you follow the method PathPlanner Wiki gives?
Why do you decide to use sysid instead of some software like advantage scope, because I saw a topic is about sysid is going to disappear. Could you specialize the usage of sysid? (I not familiar with sysid, so if there is any mistake, please feel free to correct me)
In the end, I want to say thanks to you again, your project must will help me and others a lot.
The code I have there for the limelight does several things filtering for distance to target and distance from current estimated pose all based on the number of targets in view. I am not saying this will be perfect out of the box you will likely want to tune it and your pipeline but at least it will give you some working ideas.
The runAuto line is actually leftover from CTRE example, I have removed it.
I am not sure where you are seeing that in the wiki but it looks like you are following the section for loading a single path or auto. Here is where I am loading all of the autos into the chooser and where I shamelessly “borrowed” the code from.
SysID and AdvantageScope really do two different things. This code logs lots of data to datalog and hoot files for viewing in AdvantageScope so it is both supported and recommended. SysID is used to characterize your drivetrain, this gives you the constants for your swerve needed to accurately follow paths and do closed loop control. SysID used to generate robot code and then analyze the results of that code in the data files it output. This code generation part is going away but the end analysis piece is staying and is still very valuable. The code I have here is (hopefully!) replacing the generated part of SysID that is going away but will still log the data for use in the new version of SysID. This process is still very “beta” as the WPILib PR will be merged soon along with the PR to load the files. If I was you I wouldn’t try this process till after kickoff till we get a bunch of things straightened out then it will be a much more pleasant experience (hopefully!).
I see, and what about the FOC for motors? All my devices were Licensed, but my motor closed loops in the TunerConstant are like
// The closed-loop output type to use for the steer motors;
// This affects the PID/FF gains for the steer motors
private static final ClosedLoopOutputType steerClosedLoopOutput = ClosedLoopOutputType.Voltage;
// The closed-loop output type to use for the drive motors;
// This affects the PID/FF gains for the drive motors
private static final ClosedLoopOutputType driveClosedLoopOutput = ClosedLoopOutputType.Voltage;
Accroding to the doc, it should be TorqueCurrentFOC instead of Voltage, what is the reason of this stituation?
Voltage control supports FOC, and FOC is enabled by default when licensed. Since TorqueCurrentFOC requires FOC (which requires Pro), while Voltage control is also supported without FOC, we currently default the generated project to Voltage control so it works without Pro.
The difference between Voltage control and TorqueCurrentFOC is the output units. Voltage controls the output voltage of the motor, whereas TorqueCurrentFOC controls the output current of the motor, which is proportional to torque. There are some advantages with using TorqueCurrentFOC for closed-loop control, namely the ease of tuning PID/FF gains as explained here.
