Our team has chosen to continue using Phoenix 5 this year due to the better API and configurable velocity measurement windows at the Falcon level.
However, CTRE has deprecated those falcon classes this year in the Phoenix 5 library. As a result, our compile has over 100 deprecation warnings. Is there a way to disable the -Wdeprecated-declarations. We don’t want these warnings to bury more important warnings in the console.
Example:
warning: 'CANCoderConfiguration' is deprecated: 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 [-Wdeprecated-declarations]
For the per-file approach, include wpi/deprecated.h and put WPI_IGNORE_DEPRECATED / WPI_UNIGNORE_DEPRECATED around the code where you want deprecation warnings turned off
Out of curiosity, what do you prefer about the Phoenix 5 API? We’ve generally received feedback that the Phoenix 6 API is a major improvement, so if there’s anything you feel is missing, we’d like to take your feedback into account.
To clarify, there is no configurable velocity measurement window in Phoenix 6 because we completely removed it. Instead, velocity measurements come from an onboard Kalman filter. We currently don’t have any way for users to configure the strength of the filter, but we default to a latency of around 1 ms, which is already ideal for use in flywheels.
I guess I missed the heading that this is C++ question…. For Java, we had to put @SuppressWarnings(“removal”) at the top of each class that used Phoenix 5 apis, and this in build.gradle.
//don’t show warning about using Pheonix 5 stuff still
tasks.withType(JavaCompile) {
options.compilerArgs.add ‘-Xlint:-deprecation,-removal’
}
To CTRE, we stayed on 5 last season and probably this season as a comfort feeling. We finally really dug into the API and understood what it’s doing. We finally understood the funny units it has, and how to do motion magic after multiple attempts in the past. (And figuring out what advantage we get using motion magic)
Another reason we are staying on 5 is some of the hardware we still use (Pigeon 1 and TalonSrx) are 5 only, and I thought I read can’t upgraded to 6 due to firmware issues (it’s been a while since I checked). Already having multiple interfaces for all the speed controllers, we didn’t see enough benefit to the upgrade yet to implement to another different API. (Insert “implement standard motor control interface between all vendors” comment here)
We’re running into the same issue where there are a ton of Phoenix 5 deprecation warnings, but it’s because we have to use a mix of Phoenix 5 and Phoenix 6. Peter’s solution would work, but I don’t want to suppress all deprecation warnings because they are useful to indicate where we may have accidentally used the wrong API.
On our robot, we plan to use Phoenix 6 for TalonFX, CANcoder, and Pigeon2, but we have to use Phoenix 5 for TalonSRX and CANdle. We’ve been careful to include the appropriate headers for each device so TalonFX, for example, is using the Phoenix6 APIs instead of the deprecated Phoenix5 APIs. We do this by including headers such as ctre/phoenix6/TalonFX.hpp for TalonFX and ctre/phoenix/motorcontrol/can/TalonSRX.h for TalonSRX.
Despite this, whenever we build our robot project, we get a ton of deprecation warnings about TalonFX and CANcoder Phoenix5 libraries we shouldn’t be using. I’ve gone through the code and the only ctre::phoenix:: symbol we’re using with a Phoenix 6 device is ctre::phoenix::StatusCode::OK for checking the result of ctre::phoenix6::configs::CANcoderConfigurator::Apply(const CANcoderConfiguration & configs).
Is there some best practice for utilizing both Phoenix 5 and Phoenix 6 in the same project without generating so many noisy warnings that the useful warnings are drowned out?
What is the rationale for leaving TalonSRX on Phoenix 5 indefinitely? I understand it’s not the top-tier product, but it’s still (IMHO) the best option we have for brushed motor control. Plus they’ve proven to be highly resilient in our robots over the past (almost) decade.
We are in the same boat. We removed the CANdle from our project for now so that we solely are using Phoenix6. But in order to get the CANdle in our project, we have to bring back the Phoenix5 library which re-introduces all the deprecation warnings.
We would prefer to keep deprecation warnings on as well. Therefore our path forward would preferably be to use a Phoenix6 CANdle library.
I see a previous question was asked about timeline for that library but no answer. Can we get an update on if we should be expecting a new library for it soon or if its not scheduled for 2024 season.
Also chiming in to say that I also feel like Phoenix6 is an improvement to the API over Phoenix5
One more strange behavior I noticed is that I only see the deprecation warnings when building in Windows. Our CI environment using GitHub actions using the configuration documented here shows no warnings and a GitHub codespace building with the wpilib/roborio-cross-ubuntu:2024-22.04 Docker image does not show the deprecation warnings either.
I was later answered in the unoffical frc discord.
They said it wasn’t their top priority yet but is planned, which is totaly understandable. This is a link to the message
This is probably caused by CI building on Linux with GCC, whereas locally on windows it’s building with MSVC. The compilers definitely handle things differently.
Nevermind, its the roboRIO compiler doing this.
Looking around, yeah just including TalonSRX has a bunch of deprecation warnings. That’s a CTRE problem somewhere. Probably for @bhall-ctre. Just including #include "ctre/phoenix/motorcontrol/can/TalonSRX.h" anywhere in a project reproduces this.
As you trace down, its this declaration static std::string toString(TalonFXFeedbackDevice value) {
Its because the enum in general is deprecated, instead of the function. The function is using the enum, so the compiler is seeing the use of a deprecated item in all case. It’s actually generally hard to deprecate a type because of issues like this. In WPILib we solve this by deprecating constructors rather than types. And in this case it could be solved by CTRE not deprecating the enum, and instead deprecating the toString function.
Good catch, and good advice. Sometimes, especially for enums, using X WPI_DEPRECATED("Use Y instead") = Y; can be very helpful. This is especially applicable to renames, but can sometimes help in other situations.
I tried this, but it did not work #include <wpi/deprecated.h> #define WPI_IGNORE_DEPRECATED #include <ctre/phoenix/motorcontrol/can/TalonSRX.h> #define WPI_UNIGNORE_DEPRECATED
Do I need to surround the whole .h and .cpp file where ctre code is used?
Alternatively, some more clues on how to edit build.gradle would be helpful. I have not used it before.