BLOG: FRC 2021 Kickoff
Hello FRC Community!
We’ve just released our 2021 kickoff release of Phoenix Framework (5.19.4.1). The Phoenix Windows installer and zips for macOS and Linux are now available.
You can find the latest firmware CRFs at each product page (the installer also installs them).
The new features included in this season’s release are listed below.
Simulation Support
We’ve spent our offseason investing in a new suite of simulation features designed to allow effective development without requiring access to hardware.
8 Likes
Awesome!
I just updated our code to the new updated API and I was wondering why methods in BaseMotorController changed the return types on most of the methods to doubles when their underlying implementations all return ints (from what I could tell from decompiling).
The link in the post actually explains this pretty well. But I still don’t understand why raw sensor units would ever be a decimal value. Could you elaborate more on why certain things need to be doubles instead of ints?
Also, is there a place we can browse the source code of the new APIs without finding the sources jar in a zip file from the releases page? It looks like this issue.
Other than the change from ints to doubles, everything compiled perfectly from our 2020 code. Awesome job!
The link in the post actually explains this pretty well. But I still don’t understand why raw sensor units would ever be a decimal value. Could you elaborate more on why certain things need to be doubles instead of ints?
Guess this is the answer: BLOG: FRC 2021 Kickoff — Phoenix documentation
In anticipation of future releases that support custom unit scaling, several of the Java and C++ routines have been updated to use doubles instead of ints.
The link in the post actually explains this pretty well. But I still don’t understand why raw sensor units would ever be a decimal value. Could you elaborate more on why certain things need to be doubles instead of ints?
Because we want to be able to express distances in units like feet or inches (with doubles). I’d like this to be customizable like it is with CANCoder. We decided to prioritize simulation features first given that remote development is significantly more important this year.
Also, is there a place we can browse the source code of the new APIs without finding the sources jar in a zip file from the releases page? It looks like this issue .
I have just added a clarifying comment to that tracker.
4 Likes
Just to make sure, when using the configFeedbackCoefficient on a CANCoder doesn’t change the fact that in the talon I need to call close-loop routines with the desired raw encoder units right?
I guess that’s exactly what you guys want to fix?
Right, this is the case when you are using remote CANCoder as the sensor for the talon running one of the firmware closed-loop modes.
wdym?
We (our team) always want to use CANCoder, because, in this way, you define every component with its own object.
So, in the end, we what to use (set Coefficient and things like that on) CANCoder even on a TalonFX integrated encoder, will that be possible?
Short answer is yes - you’ll be able to set what units you want on Talon like you can with CANcoder.
What Omar was referring to was the fact that when you use a CANcoder as a remote sensor for a Talon, you currently have to deal with native units on the Talon even though CANcoder has the ability to scale. This will also change when the units feature is eventually released.
But if I won’t use it as a remote sensor right now, I will still need to activate the position loop on the talon for example with native units, right? I mean right now, not when the support for custom units will be added.
So about the TalonFX, I could always create a CANCoder and update the Coefficient in it? Even if it’s an integrated talonFX encoder?
Yes, you’ll still need to use native units.
CANCoder is a specific hardware product:
So creating a CANCoder object only works with that specific product. You cannot use a CANcoder class for say, an integrated FX encoder or an encoder plugged into Talon SRX.
Oh, I totally missed that, I was sure it’s just a separate class to describe any CAN encoder.
I really think it’s a good idea to separate all functions of the talon (i.e Encoder, PIDController, MotionProfileController…) to their own dedicated classes to support OOP conventions.
As a mentor, it’s really hard teaching students about OOP principle while showing them the TalonSRX class. Do you have plans on doing something like this in the future?
We don’t currently have plans for this, but I’m not going to say we’ll never do it.
Currently our API is organized around the concept of 1 primary object per CAN device.
Just to let folks know, there’s a basic Java example for using TalonSRX simulation with WPI’s DifferentialDrivetrainSim:
1 Like
I guess keeping adding our own warpers will be the way to go for now.
Anyway thanks for clarifying things for me, sorry for hijacking this thread 
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.