I’ve had a look at the different posts among those using swerve drive and am impressed by the knowledge that I see.
The gap, for our team, is to get started and with today’s motors. We have NEO, NEO 550 and Falcon motors and it seems reasonable to use these in suitable combination with off-the-shelf swerve modules and easy-to-use / adapt java code base that could move us in that direction. We have a couple of MAXPlanetary and a half-dozen ULTRAplanetary gearboxes.
It would be great to have current recommendations of specific swerve kits, motors and gearing. Are external sensors still required or could the intrinsic sensors be used - all of these motors are providing useful data for us this competition season and last.
We are very much at the start of this journey so anything that could bootstrap a newbie small team to embrace swerve drive next year (or the year after). We are prepared to spend the time and effort now at the end of this season and into the fall to make this happen.
It would be even better if we could call upon an experienced swerve team to mentor us through the process, starting with acquisition and ending with functional swerve drive base.
Thank you and I hope that we can make this happen.
We bought SDS set up for Falcons…Now…we are doing NEOs. And while it isn’t that much of an issue (change the pinion)…it is still overwhelming as to what to actually get. Never mind the code to run.
We are in the same boat as you…we have been running KoP since our Rookie year…and 8 years later…we are looking at swerve.
The motor combo and the actual swerve drive stuff that works depends on several things…Budget being the largest part. Realizing that each corner needs 2 motor combinations…you would be looking at 1200 plus motors and encoders for a bot drivetrain…depending on the setup.
REV has a nice setup…runs NEOs (regular and 550). SDS can run Falcons and NEOs (no 550 that I can tell). With both, I would recommend more tread and wheels when you buy them.
I would also start building them and coding as soon as you get them and the frame. Mostly because of the learning curve there is for swerve. REV would be the easiest to set up…however…with the plastic rims…everything comes from together. They are working on it.
Arguably, we are in the same boat as you…we are trying to get a program together. We are trying to do this solely after school…and with no real robotics classes…it is hard to do a lot of it. I think we will document a lot of our struggles and put something together.
There are others that will weigh in on this…a huge portion will have WAY more experience than I do. Another thing is talk to the teams in your area that have swerve…get their feedback on what works and what doesn’t.
Lots of good options out there. Here is some advice to make the selections a bit easier:
Get a corner module. This is a module that puts the wheel in the corner of the robot with no tube mounted to the outside. This helps maximize your wheelbase and track width and gives you the most stability you can get from a swerve drive. The stability is really important when you can move in all directions
Try to avoid really rectangular frames, for stability purposes. With swerve you can accelerate in any direction, which means you need to consider your stability in any direction. This is why you see more square-ish drivetrains with swerve. With a tank-style drive you can go really rectangular, but with swerve you’ll want to go more square. Doesn’t need to be perfect, but the closer to square the better your all-around stability is.
Protect the motors. Many modules have either top or bottom (or both) plates that are used to protect the module and the motors from external contact. You’ll absolutely want this as an option. If it isn’t an option with the module you go with, consider making your own, or just go with a module that has top / bottom protective plates.
Whatever module you use, use aluminum wheels with black roughtop tread. You do not want to risk your wheels falling apart during a match. I believe all major swerve retailers offer aluminum wheel options. Use them.
Use the motors you are most comfortable with. All major modules on the market can use NEOs and Falcons. Use what you know best.
Start in the summer. If you want a swerve drive in the 2024 FRC season, start by making it work in the summer. Then compete with it in off-season competitions in the fall. When you’ve done all that and have found yourself with a pretty bulletproof understanding of how to successfully implement swerve, then send it in the 2024 season.
Consider what has the most team support near you. What modules are teams at your competitions running? Odds are they’ll have spare parts if you need them, or be able to help diagnose and solve problems should you have any.
If cost is a major factor in your decision, don’t use swerve. Swerve is expensive. You’re going to want 4 modules, at least 1 spare module, and all of the motors and sensors that go with it. If you’re looking for the cheapest option, maybe swerve isn’t right for your team. The major modules are all pretty close in cost, so if you’re at the point of trying to save money based on module type, you should consider a more cost-effective drive system. I know it sucks, but sustainability is more important than moving sideways.
Use the external, absolute encoders whenever you can. Knowing where your wheel modules are rotated to in software makes your swerve infinitely more reliable and robust. Not having this requires you to manually set your wheel positions pre-match every single time, and the one match you forget or do it wrong your entire match is ruined. Use the external absolute encoders to get the initial angle of your modules, and then use the built-in motor encoders during the match for your control code.
Gearing is pretty dependent on the game and your strategy, but I will say you are almost always better off gearing for a slower top speed and making fewer mistakes than gearing for a high top speed and having to constantly correct yourself. Is your driver among the top 8% of drivers in FRC? Sure, gear for a fast drivetrain. Otherwise pick the slower ratio. Something around 14 ft/s to 16 ft/s is perfect.
My team just started using swerve for the first time this year, so I can’t say we’d be effective “swerve mentors”, but I’d be happy to try and answer any questions you may have. We use the WCP SwerveX, so I am most knowledgeable with that module, but you are sure to find experienced mentors on this site for swerve with whatever modules you end up using.
Another point is to make sure your drivers get practice and know how to drive swerve! I’ve seen many teams transition to swerve and drive it like tank. Make sure they are comfortable spinning while driving, as it is one of the things that make it so good, as you can use it against defense. I personally prefer using a controller with swerve, as opposed to large joysticks, as I find I can be more precise with a controller. Also, avoid binding very many actions to thumb buttons for your main driver controller, you want to be in full control at all times.
Outside of the cost the development / programming is where most teams struggle. If you have the money to do swerve then do it. MANY teams are struggling with the learning of how the system is intended to operate from a programming perspective. I noticed nobody here seems to have any links to useful code or other examples of working systems that teams have. Feel free to add too links !
Strongly suggest you take advantage of the great third-party libraries out there. YAGSL seems great. We’ve had swerve wheels on our robot for years, but this was our first year doing “true” swerve drive, because of the code. Also more than happy to help with specific questions.
Since we used SDS Mk4i modules (like a lot of teams) we adopted the open-source implementation from Team 364 as our base. We got the platform working ~2 weeks into the season and had time to practice with it, which was really key. We’re still not nearly as smooth as some of the expert teams, but it’s light years beyond where we have been.
Definitely make sure you have spare parts. Swerve modules are complex, with a lot of moving parts. Every year we’ve managed to strip a gear or something, and needed emergency fixes.
Do not use CANCoders. There are plenty of encoders out there that do not have a significant chance to report zero during start up. The issue can be mitigated but not fixed.
Control code in swerve can make a huge difference. The swerve systems with brushless motors are very powerful and responsive. Too so in many cases. Exponent on inputs and slew rate limiters are very important to make for a driver experience. Also we have chosen to use a ‘gas pedal’ control. We took velocity of the translation stick. The translation stick only controls direction of translation, the right trigger controls speed. This takes controlling 2 things (direction and speed) of the sticks and makes it easier to get the correct direction of translation while doing slow movements. We don’t use the gas pedal on the rotation stick as it only has 2 directions so it isn’t as touchy. We also implemented a slow mode on a bumper that cuts the speed by 1/3 for even finer control.
We got the REV swerve modules and built a test chassis. Set-up went well and after setting CAN IDs and matching the REV-shared code (on GitHub) to match these, all were tested and the motors indeed turn when we tell them too. Final steps before driving this coming week include verifying each module’s calibration (the ease of use of the calibration cube is appreciated) and greasing the gears.
The wheels that shipped with the modules are the plastic hubs with rubber wheels. It seems that therse are the ones that are good for tens of minutes of use (according to other Chief Delphi posts) so we did get aluminum wheels (REV sold out so we got wheels from Thriftybot). We did a test fit of the slightly wider aluminum wheels and they fit fine.
The template from REV for cutting and drilling the treads results in quite a gap. Reading further, we learned that the template is designed for 2-ply treads. These were not available but 3-ply was and we got that. We’ll have to make an adjustment, probably redesign the template - willing to share the STEP or Onshape file when we get that sorted out.
According to other Chief Delphi sources, the aluminum wheels with treads applied have tens of hours of use. We’ll use the plastic/rubber wheels first, until they break… As this is likely a permanent substitution, we might need to modify the calibration blocks (at least one of them) to fit the wider wheel or 3D print an adapted version.
So far so good… We are thankful for Chief Delphi and advice offered by those who seem to live here - some replies arrive within a very short time indeed.
I think we have the bases covered - anything we missed?
Sounds good. The REV SwerveMAX worked really well for us this year, and I wish your team good luck with them next year. Side impacts (Specifically with the charge station) were really what ruined the wheels the fastest from our experience, so for the off-season, I would definitely recommend prototyping custom tread solutions, at least until REV releases an improvement for 2024.
We are a team of similar vintage who went ‘swerve’ this season. The process was time consuming. It did not help that we’d graduated our entire programming crew and had a year off due to Covid!
Our first attempt was with Thriftybot swerve. I really like the TB people/company. They had the advantage of not needed two brushless controllers each. And we did get them working after a fashion just prior to the 2022 campaign. But it was not a reliable sort of functionality and we had many other issues to work out in a major rebuild year. Oh, and Ryan and co. said they’d not be continuing the product line. He suggested SDS.
We’ve gotten pretty good at grant writing and got a community foundation to fund the switch to swerve. SDS Mk4s, Neos, Spark Maxs. Not cheap. And our programmers dug in and worked. One of them did heroic stuff over the summer. And we still only got the swerve test bed running reliably around kickoff.
From there things got easier in some ways. Custom frame was a breeze. The CAN issues some mention were not major for us as we have a very compulsive wiring czarina. Oh there were things nobody told us and we did not know to ask. Like how often to change treads!
Anywayz, if you are interested in our journey - and it was a success - send a PM and I’ll put you in touch with some of the students who got the system up and flying.
If you mean the AM14U5 (kit chassis), no, unless you heavily modify it, at which point it’s cheaper and less effort to get another chassis.
This changes from year to year. A general rule is to try and be relatively square, as this will keep your robot equally stable in both directions. Some other things to consider:
larger wheel base results in a stabler, less tippy robot
smaller dimensions result in faster rotating* robots
sometimes you need to fit into tight spaces in games (i.e. charge station triple balance)
* As long as your robot has a relatively low moment of inertia and decent center of rotation. Otherwise it may get tippy or rotate about the same speed.
The mechanical team does some magic with bolts and stuff and at the end of a 9-hour long meeting a chassis with wheels spawns in.
(I’m not a mechanical person.)
Reiterating @CuteRedpandas, get as much programming help as you can. Good controls are a major separation between average and great teams. Not even advanced control, just consistent, reliable, code, will put you in the top 50%. Treat your code like it’s controlling a surgery robot; everything should be precise and controlled, every possible code path should be accounted for, all errors should be handled gracefully, and most importantly, it should do what you tell it to do.
Here’s a whole thread containing tidbits of helpful info:
You are much better off finding an established team (or two) located near you and build a relationship with them. Visit their shop and ask questions about how they do things. Bring your robot and ask them to give you advice on how to improve it. As a younger team, it is likely that there are things that you don’t know that you don’t know and so you can’t ask about those things. Someone experienced looking at your robot may be able to pick up on things that you don’t know can be done better.
Excuse me, does anyone here know how I can calibrate my swerve model “mk4i” is there a specific way? manually? Or based on the code? Anyone who can help me would greatly appreciate it.