Recently my team got a bunch of new CTRE products and we are faced with the options of writing our own code or using the swerve generator in phoenix tuner. What are the pros and cons of each and which is recommended for my team to use?
1 Like
Without getting into specific details:
- If you have done swerve before and have specific needs or ideas on what you need from the code: custom code
- All other cases: ctre swerve
6 Likes
Can you give me some examples of the specific needs that I would need that I can’t get out of ctre swerve?
1 Like
If you want to do things like playing with different physics models of swerve or experimenting with really unique control ideas it might not be your thing, but outside of some really intense research stuff I don’t think there is any reason. If you are doing those things and aren’t really confident in everything else you are doing software wise I would argue you are miss allocating your time.
That being said I do think there can be value in going through either the “legacy” version of the code or the something like YAGSL to explore and learn what is being done and how.
5 Likes
We used the CTRE generator for our off season and it is definitely a lot easier and faster than writing custom code, especially if you don’t have any experience with swerve code.
1 Like
Tbh if you are asking what the benefits of a custom implementation are you likely do not have time (it’s mid November!) to be able to take advantage of the benefits for this season. Probally better off saving the energy of other endeavors this year and if custom swerve code is still of interest tackling it for 2026 over the off season.
2 Likes
We wrote our own swerve code, I we have recently rewrite it to fix some bugs.
We are happy with our own custom code because we don’t like to use stuff as a black box.
We didn’t try to use the CTRE swerve, because it didn’t exist when we wrote our swerve code and we have already commited to our custom solution.
1 Like
I would try to get out of that mindset, frc code is very easy to blow away and recreate from the ground up.
The CTRE code will always be better than custom code bc it’s maintained and optimized by CTRE for CTRE hardware. You can recreate it but can you maintain it? Including new features? While building out the rest of a robot program during build season?
Probably not, very few teams can.
3 Likes
We actually don’t have any problem to maintain things like this,
this year we actually added new features and fixed bugs.
I don’t know how sustainable that will be in the future, because we have 2 people doing it, and making sure it is up to date (myself and another person) who are currently seniors.
But I do agree that for a lot of teams it is not sustainable.
Beyond that - CTRE employees have far more expertise and knowledge of how their hardware works than 99.9% of the teams out there.
As a result, the CTRE code is almost always going to out-perform team solutions, save a few rare examples.
As far as black boxes go, it doesn’t have to be. While most teams rely on on-motor motion and velocity control, it’s very easy to teach the basic theory so the team members know what they’re doing. The same goes for swerve. Ether’s original papers and excel can be used to teach all the theory.
You can spend the rest of your time addressing the unique facets of the game challenge, rather than worrying about if you’re going to move around the field effectively.
But - as always - everyone approaches this differently. What works for 1498 might not be the way you want to go.
2 Likes