so I’ve been hearing great things about how much better phoenix 6 is than most other vendor libraries for programming and that has brought me to a question. Is it worth it to use our falcons (we have 7 of them with a partially broken 8th) to be able to use phoenix 6 and its pros? What we’d be loosing is using all one type of motor (neo vs falcon) (we’d have to be using neos for our drivetrain because we have max swerve) and we’d be using potentially unstable motors. I don’t think we’ll be getting krakens for 2024 either.
1 Like
So this is more preference than anything, while I personally prefer the CTRE libs over the REV libs I would also prefer to use all one or the other.
With that said, motors and controllers are expensive, so if you can’t afford it don’t be afraid to mix and match. If you can afford to but aren’t going with Krakens, I would probably use the Falcons for prototypes and what not, then build the comp bot with all REV motors.
TLDR: One or the other isn’t going to wave a magic wand and make your bot better, you just have to figure out what’s best for your team resource wise.
1 Like
I’m pretty sure we could get some krakens if we really wanted but it would put a good size dent in our budget. So far it seems like our mentors aren’t opposed to getting krakens but not many and/or not till other teams have used them since they’re a new product. We did use falcons last year and they were fine but with vex being vex and qc issues I’m pretty sure we wanted to move away from them but phoenix 6 is looking awfully tempting. I guess my question is, is it worth risking using falcons with potential issues for nice api and easy wiring and such, or should we just stick with rev and the so so api
If you haven’t ordered them yet, I wouldn’t count on getting krakens in time.
I don’t know anything specific, just basing that on previous years.
In addition, the real benefit doesn’t happen till you have all CTRE on a canivore so you can benefit from the improved library with all the neat features like improved timing.
4 Likes
It sounds like you are using max swerve which means the steering encoder is probably not a cancoder also your steering motor is probably always going to be a neo 550. This means you can’t take advantage of most of the pheonix 6 features (timesync wont be as useful since steering and can coders and steering motors can’t be apart of it.) Since you have 7 working falcons and you can only use 4 with a max swerve you should be good if you want. The big advantages with falcons is the integrated wires, sensors and good temperature monitoring mean they have been the most reliable motor for us. Falcons are also more efficient and more powerful but I wouldn’t get too hung up on that.
If you have a working swerve drive right now with neos and you are considering switching make sure you have enough time to test it. I don’t think you are going to see that many advantages on the programing side of things with phoenix 6 and max swerve.
And yes it’s a little late to by krakens for this season.
2 Likes
I also realize you may be talking mechanisms and not swerve drive. If that is the case then I think falcons are great. But you need to understand what advantages they have for mechanisms. The main advantage with falcons is CTRE’s motion magic. This feature is particularly nice with arm mechanisms, elevator mechanism (basically anything that has positional control). Also falcons are nice for wiring. Our main reliability issues with neo’s this past year was encoder cables and canbus cables disconnecting or breaking from spark maxes and neo’s.
For things like shooters where you are just using a velocity PID control or intakes that are just go a certain speed I don’t think phoenix 6 has any real advantages in those use cases.
1 Like
It is not hard to use both libraries in code; most of the time you’re just using WPIlib functions anyway. REV and CTRE both have their quirks, but at least the units mostly match up now with Phoenix 6. You will not be API-limited with either one.
If you are using NEOs for drivetrain, and have enough to kit the rest of your robot, don’t use Falcons just for the API. The extra power won’t even help you above the wheels. If you are using a Falcon drivebase and are doing fancy odometry stuff, then a Phoenix 6 + CANivore setup makes sense.
1 Like
so what I’m seeing here is falcons are nice outside of the drivetrain area but maybe not worth it. I’m currently using yagsl for swerve so unless that can make better use of falcons over neos there isn’t really a benefit to using falcons in there besides the bit extra power.
I would not use them on your drivetrain without having at least 8 working motors + at least 2 spares.
1 Like
we can’t use 8 falcons on our drivetrain we use max swerve
Right now, given the paucity of CTRE motors on the market, i wouldn’t bank on making an ecosystem switch.
The Phoenix 6 API (with or without the “pro” subscription) is definitely the better of the two software interfaces available now, and is likely to interoperate more smoothly with some of the newer WPILib features by virtue of a fairly modular composition-forward design, and their sensor framing/timestamping features are currently unmatched. But none of this matters if you don’t have the hardware to use it on.
I am hoping REV and CTRE eventually work to offer functional interop on the CAN FD bus so that teams don’t have to make exclusive ecosystem decisions. I genuinely think everyone involved would make more money in that case. But this would require a fair bit of work and for the management at both companies to see things the same way.
2 Likes
well we do have some motors. and I know all but that 8th motor work because they were all used in 2022 (and four for drive motors 2023) so its a matter of do we use falcons with their issues.
Go with whichever you can get working. Both Motors are fantastic. You can’t go wrong with either! Its about making whatever solution you decide, work!
if you can verify that the Falcons are in good shape, by all means, use them.
We are currently trying to work out how to re-write our Falcon based Swerve Code currently written using Phoenix 5 to Phoenix 6 format and we are really struggling. I cant find any meaningful documentation other than what is auto generator from the header files, which to say the least is not very informative.
I’m currently trying to replace this phoenix 5 line
m_turningMotor.SetSelectedSensorPosition(powerOnAbsoluteSteerAngle / 360.0 * kSteeringRatio * 2048.0);
with the equivalent line for Phoenix 6 and I can’t for the life of my work out how to initialize the internal position of a Falcon.
So at the moment I’m answering No to the original question in this post. Having said that we have worked out how to use the continuous wrap and SensorToMechanismRation stuff which has completely removed a bunch of code from our swerve modules class, so I can see some advantages, I’m just not completely sold yet.
The method you’re looking for is setPosition, documented here.
You said you couldn’t find any documentation. Have you looked at the Phoenix 6 documentation, the API Javadoc, or the examples? The Migration Guide for v5 to v6 is especially useful.
1 Like
That is blatantly obvious now that you say it. I did read through the Phoenix 6 Documentation and the Migration Guide and didn’t notice anything on the lines of code to use to initialize a position of a motor. I did noticed the stuff about sensor to mechanism ratios and continuous rotation PID and using turns instead of encoder counts, but it was more conceptual stuff then actually how to code it.
After doing a github search on the phoenix examples for “setPosition” I can find the word.
Obviously I just need to look harder and learn my way around the API reference a lot better.
Now I just need to work out the replacement code for
m_armMotor.Set(ControlMode::MotionMagic, m_MotionMagicSetPointPosition);
Thanks for the help.
Motion Magic® usage is documented in the Motion Magic® Controls page and in the migration guide.
We’ve also added a few new Motion Magic® controls in Phoenix 6, those being an onboard exponential profile, a velocity profiler, and a version that allows changing cruise velocity, acceleration, and jerk directly in the control request.
Thanks @bhall-ctre
I’m starting to come around, maybe Phoenix 6 is worth it. Just hard to teach an old dog new tricks.
1 Like
@bhall-ctre
Just to clarify, is the 0 turns used in making the m_request object of any importance in this example?
or does the .withPostition(100_tr) ignore the 0_tr value and just tell the motor to motionmagic to 100 turns from where ever it is at the motment?
Does the controls::MotionMagicVoltage object need to be initialized with an arbitrary value?
// create a Motion Magic request, voltage output
controls::MotionMagicVoltage m_request{0_tr};
// set target position to 100 rotations
m_talonFX.SetControl(m_request.WithPosition(100_tr));
Am I right to assume that you should create one instance of the controls::MotionMagicVoltage object than every time you want to go to a different setpoint using motion magic you should call the second line with your new setpoint where the 100_tr is?