We bought cots swerve drive modules this year. It took some hours of programming, but now we’re up and running! I’ve reviewed several swerve threads and the common theme is: if you haven’t figured it out by now in your pre-season, don’t bother!
With that said I would love to hear from the community, how do we know (how did YOU know) when we’re ready?
Can you control it as well or better than a 6 wheel tank drive? If yes, you are ready, if no, it wouldn’t be as good as a 6 wheel tank drive in season.
If you’re close but not quite there, FIRST’s is all about risk and reward, play it by ear during the comp. Sometimes programmers should just go for it.
I partially agree with the first part, hard disagree on the second part. Having programmers “just go for it” has almost universally, in my experience, resulted in sketchy robots (to say the least). Do not plan for anything to exist in-season that doesn’t exist already. That goes for programming, time for machining, etc.
That may mean you’re leaving potential on the table, but it also greatly reduces risk.
Take risks. Have fun.
What do your drivers say? They are the ones who are ultimately your customer here. If they think it is ready (or think that they can “get there” with only a small amount of additional practice time), then I say, go for it.
Have you done your goal setting for the 2020 season yet. I had an FTC team that decided to do swerve to prove it could be done. In their goal setting they actually didn’t care as much about winning competitions. It was more about developing the technology. And that was agreed by everyone on the team. They did great. Won a decent amount of competitions (even though that was not their goal) and won the state level Inspire Award and 2nd Inspire at Super-regionals which was a recognition of their dedication to pushing the boundaries.
If you are clear as a team that this is something that you want to do and it aligns with your goals for the season, then I think you are ready!
I get what you’re saying, but not trying new things that are 1-2 weeks of development time away from being very usable is excessively conservative, IMO. I do agree that generally you should play it safe and not make large leaps during season (just starting to figure out controls during season would be, IMO, on the aggressive side here), but if you mostly have stuff working and just need a little bit of work, it’s not unreasonable to expect that you should be able to figure it out by the time robot mechanisms are built or whenever you expect to start practicing.
Our team hasn’t done swerve, but the biggest thing that stands out to me that people seem to forget is figuring out effective controls that will work in a match. For example: are you going to be able to pivot around each individual wheel to avoid defense? Are you, like some teams did this year, going to have field oriented controls during some parts of the match, and robot-centric other times? Are you going to have the robot be able to auto-align to fixed angles (for example, turn to face forward or some game element)?
If you’re going to potentially try some of these things, you need to figure out how to implement the features, but equally importantly, how to map these many different controls to something usable by your driver. Our team will likely be trying swerve during the next offseason, and I think we will (game permitting) try it in an offseason event before we actually put it on a real competition field, just so that we can get an idea of how it performs in a real match with defense and obstacles, etc. This isn’t strictly necessary, but you should have some idea of how it will perform in an actual competition before you put it out on the field.
“1-2 weeks” is never really 1-2 weeks. I think betting a drivetrain on time estimates made by younger folks may be unwise. 
Swerve in particular has a ton of small optimizations that make big differences in driveability and controllability.
So, you’ll put 1/2 of your build season for whoever’s working on it into that. Got it.
Remember, unless your first regional is fairly late, you’re talking a significant percentage of the build–and with swerve, it’s going to be very difficult to go “back to” a tank drive quickly. When you’re working with “new” stuff, ALWAYS have a fallback plan, just in case that 1-2 weeks becomes 1-2 months (it will try to). For swerve, the “fallback” is to lock the modules and drive 4WD… which may be a lot more interesting than you want it to be.
Going back to the OP: Are your drivers comfortable with it yet? If not, I would probably call it an offseason robot, and go with your normal drivetrain in-season. Then, in the offseason, get more practice and move the “magical scoring devices” over to the swerve base (or build new and improved ones), and compete at a couple offseasons. There’s more time, and it’s not as critical to get it right.
1-2 weeks was probably too aggressive, but the general point was that if something is very close and you’re very confident you can get it working quickly, there’s no need to be super conservative and only use things that you already have working perfectly.
Of course, this depends on what “very close” means – not having done swerve myself, I can’t comment on what specifically would make a swerve chassis “close enough” to want to try during the season. I would say that if you’re comfortable enough with performance/controls to be fine with putting the chassis into a competition robot as-is (even if that means its imperfect and needs tuning work), then you’re probably fine to do that tuning work during season. This way even if you miss your time estimates you won’t be dead in the water.
For drivetrains, I would need to be 100% confident that I would have that tuning work done by Week 3 of build, personally, AND that I had a plan to revert that I could do in 3 weeks with minimal impact.
One of the greatest strategic minds in FRC once said that the three most important parts of the robot are drivetrain, drivetrain, and drivetrain. Remember this: If a tank drive fails, with the way most of them are built these days, they’ll probably be limping but able to move (and ideally you won’t notice until the end of the match). If a swerve fails, there’s a better than 50% chance that it’ll be mostly disabled. And the last thing you want is an immobile robot when you need all 3 for that endgame bonus.
Now, if we were talking arm or lift or other scoring device on top of the drivetrain, I’d be a lot looser. But with a drivetrain, color me cautious or overcautious. If I had time I might even try deliberately inducing a failure to see if the drivers can figure out how to overcome it.
We worked on swerve in the offseason this year. Knowing the ins and outs of swerve control was really helpful going in, but we still spent about twice as long with it as I wanted to, and there’s still optimizations to be made. 50/50 on whether we’ll use it in season, due to a whole host of factors.
Correct me if I’m wrong, but briefly glancing through your code, you guys don’t seem to have used the example code provided by COTS swerve manufacturers. How much of the time you spent would have been cut down if you had used, for example, the 2910 public swerve libraries? How much further would you need to optimize controls/tweak coefficients/whatever else you have to optimize if you just got that code up and running during the offseason?
Most of our code is actually based on 364’s code, which is based on a couple other teams’ code.
We wanted to know how the code actually worked. Using MK2 example code is extremely easy for teleop, but has practically no extensibility without simply copying 2910’s code, and 2910’s competition code was much harder to understand than we had time for. Copy/pasting 2910’s swerve code without going way behind the scenes to understand what’s going on could cause any number of problems down the line, and we weren’t comfortable with that.
The hard part is not just getting the kinematics and teleop operation going- those were actually very easy. Implementing motion profiling and figuring out the best set of driver controls took a longer period of time to get acceptable. Our code is nowhere near as advanced as 2910’s, but we can also modify the behavior as needed without much effort. Keep in mind, we have spent about 30-40 hours programming swerve so far. I have no doubt we could have at least halved that time by using COTS code, but the risks could have been greater, and there was no way for us to know what problems we’d face with canned code in the future.
WPIlib 2020 will feature swerve odometry and kinematics, so we’ll definitely be researching those down the line. Odometry is one of those things that we could implement on our own, but WPIlib has enough support and is open-ended enough that we’d be a bit safer on using. Really, I’m quite happy with the teleop performance of our swerve. A much bigger question is how autonomous performance will compare with WCD.
So I shouldn’t plan to build a robot to play the game?
I know that’s a snarky answer, but it has merit. No one knows what the game will be. A mechanical team will have to create something that doesn’t exist at all. That’s kind of the point of engineering. Solving problems that others haven’t.
The issue resides in that most teams don’t give their coders enough time. Don’t expect greatness out of a subteam that you only give 1/10 the time with the robot.
To further clarify the above situation, it seems OP has a working drivebase for testing, so I really think that if they have confidence, they should pursue writing code for at least another week into build season to see if they can get to the level of driving capabilities as their tank drive. Unless mechanisms are incredible dependent on drive train type, don’t decide until you get closer to understanding its effectiveness.
Quick note on this- past performance is the best indicator of future performance, IMO. If your programmers got a week to program the robot last year, don’t plan on getting more than a week this year. Of course you should make efforts to the contrary, but the programming team shouldn’t bet on a miracle.
Some teams change dramatically in a single year. Most don’t. Most teams are in the “most” category.
As far as “shouldn’t plan to build a robot to play the game”, in some ways, that’s close to what I believe. If your team decides that you must have a flywheel to play the game effectively, then by all means build a flywheel. But if nobody on the team has made a good one before, expect to spend a lot of time on research, prototyping, and iteration. There are always unforseen issues that pop up, and those can take an unknown amount of time to debug. That time should not be spent on something as essential as a drivetrain.
One example is 971’s vacuum grabber this year. I would not have supported 1072 betting on a vacuum grabber when there were much safer tried-and-true rolly intake options available to us. As it was, we used a inside-out claw to grab the hatch, but this was easily prototyped and worked better than our roller prototype anyway.
I have never understood that kind of thinking. Every year I offer to the programmers that they program the robot and then we will build when they are done with the program. They have never have taken me up on it. The reality is a normal team building a typical robot is doing well to have it semi complete by week 4.5. It is a fact of life and you need to find a way to deal with it.
Spending development resources on a drive train during the season typically removes those resources from manipulator development efforts. That might not be true for certain teams that have enough resources to do the swerve project and still do everything else in parallel, but I know it would be a trade-off on our team. That’s why I see a swerve drive differently than I see a challenging manipulator. My bar would be higher for swerve in terms of how ready I’d want us to be in order to feel confident that it’s going to make us more successful instead of less successful.
It doesn’t have to be a fact of life though! The best and brightest mechanical mechanisms came from hours of iteration, constantly being adapted to new situations. The same should be with code.
An average team might take 4.5 five weeks to build a robot, but how long does it take to build a drive base? (If the answer is longer than 2 weeks, boy do I have a product for you!) Programmers should be given ample time to develop and test code on the drive base while other mechanisms are being developed.
Mechanical continues to dominate FRC culture, leaving little room for programming and drive practice. This is not a good mentality in general, but especially in developing a swerve drive. Swerve drives need time being build, programmed, and drive to be effective. Lack any one area, and you’ll get poor performance.
Note: For readers after 2020: multiple above numbers by 1.5 for build seasons after 2019 for those numbers to make sense.
This, so far, has been a great discussion. When I read through all the replies, I get the sense that it’s super “YMMV”. If we have enough resources, we can complete the swerve implementation, and not negatively affect the season. Efficient allocation of our available resources is always a plus. And decision to pursue is based on how much risk we take on. This part of the the conversation, however, can go on FOREVER. Can we shift this thread to this type of discussion:
Thanks @UnofficialForth for this answer! It’s definitely provided us comfort/discomfort where we are today?
Do people agree with @UnofficialForth ?
What are some of the ‘gotchas’ of swerve drive? --where you thought you were ready, but clearly were not.
Has anyone abandoned swerve drive after being confident in the preseason?
We introduced swerve last year and it was a great success. I agree with @UnofficialForth on his assessment. We had 2 very good student programmers and a great software mentor that worked with them as well. I would add that you should be able to do this by the end of week 2. The robot should be able to be run in field-oriented mode.
A couple of other considerations:
The only problem we ran into is when the turning encoder would slip. That was solved with some Loctite.
JMH