One aspect of the Java library that was nice is that VSCode would automatically decompile the class files and I could jump into the Swerve code. This was useful for two reasons:
Understanding the behavior. The CTRE API docs are fairly good, but the instruction docs are fairly barebones. I found it necessary to read how the swerve thread was set up to make sure we using it right. Two examples were that I realized how to do logging correctly by reading the source, and figuring out the units for the PID/FF constants was difficult without viewing the source.
Explaining how the swerve code works for students. Reading through the Java source was highly useful for this.
Using a closed source library that even I don’t understand for our core control code makes me nervous.
Looking through the CTRE Swerve Library helped me realize numerous things we were doing wrong when we were using the library, and I 100% agree with both of your points. The Java source code was also available online in the javadocs for the swerve library.
Part of our changes (introduced around the end of last season) is a Telemetry class in the user code that plumbs up basic logging, which users can use as a reference.
All of the units match the control mode units, just like our normal API. So voltage control would mean feedforward and PID in volts assuming you are using the default Voltage control.
The primary intent was to allow cross-language swerve. With the moving of the Swerve API to C++, this allows out of the box swerve support for Python and C++, as porting the Swerve library to Python and C++ would be difficult to maintain and in Python’s case, poor performance.
However, if you have specific questions and documentation concern, there are numerous ways to reach us. We aim to be extremely responsive and take customer feedback extremely seriously. Many of our features, API shape, and general direction comes from our customers feedback.
CTR crew, any chance of giving us some info on the four quadrant operation of the Krakens?
You’ve got great data on two quadrants (forward driving, reverse driving), but nothing on forward deceleration and reverse deceleration. Of course, nobody in FRC publishes that data either… You could be the first! From my test bed I know that when you command a Kraken to slow down, there is some rectification going on transferring rotational kinetic energy back into the power supply.
Brake mode data would also be nice! IE, brake mode torque vs speed curve.
I’d encourage you to act in those concerns. I wholeheartedly agree that using code that the students can’t easily understand undermines the whole activity. Black boxes are bad. You could use the WPI example code, you could use YAGSL, you could even fork our own team100 lib if you want.
There’s a very low-value current sense resistor that would not be in the path this way. Other than that, it would be down to copper thickness, etc. You’d need to run a certain amount of current through it and then measure the voltage drop, using a 4-wire measurement (Kelvin) set-up to get data, which would be really good to have.
If you are a team that is using heavier-gage wire, short main power runs, etc. there could be something here in this same range. Batteries are where you can loose all of this back really easily though.
I also haven’t done C++ in 10+ years, but this is an hpp file, which to me, sounds like a combination of the .cpp implementation file and the .h header files that I remember.
Regardless, I see implementation in this file about how the thread is managed.
Yeah, I’ve noticed that some of the code seems to be understandable and there, but other functions or methods are just completely empty (like this one in the SwerveModuleImpl)
.hpp is just a header. The extension is not .h to signify that it’s not compatible directly with a C compiler. IIRC that’s just convention and compilers don’t prevent you from that mistake.
On the topic of the Swerve Library and it’s move to C++, while we think the new Swerve Library will overall improve the experience with teams on a whole, we still have our old Swerve library under the Legacy* naming scheme.
This means if you want an implementation where you can see the details of the swerve library, you can still do so by using the Legacy variant.
The only things you lose on the Legacy variant are the performance improvements with the transition to C++, and any additional development we’d do on the Swerve library, which we’ll be prioritizing in the C++ stack so all languages benefit from it.
At the moment, the two are very close implementation-wise. The only differences in implementation are a de-templatization of kinematics/odometry so we could support non-4-module swerve in Java/Python, and some improvements to support the new Module Feedforwards provided by PathPlanner and Choreo. A lot of this is source visible in the C++ header files, primarily the Swerve Request implementation. Other aspects will remain at the language API level, such as device configuration, so you’ll always see their implementation.
Right, I’d just like to see some numbers comparing the options because (while seemingly unlikely) who’s to say there aren’t some design issues that lead to a net same or higher resistance, or so we can determine if the feature loss is worth the resistance decrease.
