What are benefits/downfalls of swerve drive and is it necessary to have to do well?

FIRST General Forum
21

Nothing in FRC is always “necessary to have to do well” other than a consistent, reliable drivetrain and at least one reliable mechanism. Some games will require a little more than that, like passable software or a second mechanism. Other games require less.

It is much, much easier to make any tank drive consistent and reliable than it is to make a swerve the same way.

Swerve drive will absolutely never be a requirement to be a team that “does well”, and you shouldn’t poison your team’s thoughts with what you have to do to keep up with other teams. Build the best robot your team can build, and don’t build anything more than that, or you’ll end up worse off than you started.

3 Likes
22

Agree with all these points - except maybe that 1717 in 2012 may have also been best in world. and maybe 2767 in 2017. ( at least an argument can be made)

We were inspired by 1717, after being across from them at worlds, to start our swerve journey - we used it in 2014, 2015, 2017, 2018 and 2019. Each year it inspired several of our students to improve the mechanical design and the programming - which became a big reason for doing it. As for competitive advantage - for us probably not, we would have some nagging issues with it that would take until later in season to correct. But it is also great fun to drive.
This year we did not use it - concentrated on a turret, along with the shooter instead - and I believe this is our best robot in years (1st event did not show its full capability) and we look forward to using it at postponed or off-season events down the line.

It is expensive and it does use up a lot of PDP slots, which would have been a concern this year for sure, and is likely not the area to concentrate on to improve your competitiveness. It can be a fun and engaging project, that can inspire and teach many engineering and software principles. But in your situation I concur with others that it is unlikely the best bang for the effort.

We will likely have another off-season project to improve our modules, and our students!, as we have every year since 2012, but may not use them next year as we didn’t in 2013, 2016 and 2020. We recycle most of the expensive stuff and have moved to more 3D printed elements, like others.

6 Likes
23

There is no universal right answer here… the above points on opportunity cost are all very good.

To play anecdotes, 148 ran swerve for their first time in 10 years and was able to go 17-1, win their first district, and set the world high score… 1323 on the other hand has run swerve for quite a few recent seasons and failed to win a single match!

48 Likes
24

I disagree

This. What is the opportunity cost of swerve, i.e. what are you giving up by implementing swerve? It might make your alignment to scoring marginally faster and your ability to get around defense a bit better, but no one defends the guy that couldn’t score in the first place. If you struggle to build effective manipulators to intake and score game pieces you should work on that instead.

Swerve can make a good team great. It can also make a good team miss elims at every event.

5 Likes
25

Ummmm what about spending a single off season and then implementing it that season? (I am going to ignore the fact that we broke it because is was working great before that)

26

We decided to use the AndyMark swerve modules in 2018 without any offseason practice with swerve and we were very successful. It is possible to do swerve without offseason practice, but it is difficult. We spent the first three weeks of the 2018 season figuring out those swerve modules and getting the MA3 encoders to work on them to get steering to work correctly. Getting the swerve drive math figured out also took a little bit of doing.

The reason we were successful with swerve in 2018 is because of how much time we (programmers) got to test with the modules. If you buy the modules at the beginning of the season and give your programmers a breadboard to work with, it will help a lot. You should also ask your programmers if they are comfortable doing swerve.

Things (for programmers) to get swerve working:

  • Individual wheel steering
  • Swerve drive math
  • Field centric controls (Yes, you NEED field centric controls for driving to be intuitive)

If you decided to actually machine your own swerve modules, then you also have the complexity of making sure everything work mechanically (I can’t comment on how difficult that is). Mechanically, we haven’t had any problems with the AndyMark swerve modules yet (just one time we didn’t put long enough bolts in when we put a CIMcoder on the drive wheels, but that was our fault).

If you successfully get swerve working, intaking game pieces is SO much easier and lining the robot up is a lot easier. This is of course assuming that your driver likes swerve drive. I know one person on our team who is better at driving tank than swerve.

27

This year, 708 decided to build a swerve drive for their very first time. Due to time management and a number of other factors - they effectively implemented it “in season” - though the practice chassis was largely built in December, without any programming.

Based on what we saw, the biggest hurdles to overcome are actually controls related - there are a lot of small details that can make or break the system as a whole, but nothing paralyzes a swerve more than bad software. To compound things, in the current FRC ecosystem there are a number of COTS swerve options, and a number of COTS Motor and Controller Options. For those of us who live in the future and have transitioned to Brushless - this means NEO Motors and Spark Max Controllers (since Falcons didn’t / don’t exist for everyone yet) mixed with 775’s and Talons for Steering.

This mix of Controllers meant that 708 couldn’t use a direct port of anyone’s code to start, after reviewing 1323’s, 2910’s and some others, their code ended up being a heavily modified version of 1323’s.

That being said, by the time everything actually worked - it worked reasonably well. Once the system started getting some run time, we started to notice that all of the little things really mattered. By little things I mean:

  • Current Limiting
  • Gear Ratios
  • Voltage Ramping
  • Properly Zeroing the Modules
  • Proper PID Tuning

And the list goes on and on. If you’ve got the bandwidth, and commitment to doing it well, swerve is literally, actually amazing. If you can’t commit, and don’t have the bandwidth, you may as well not have a drivetrain.

Notice how I haven’t mentioned the Mechanical Part of the System Yet? This was intentional.

Now that we live in the future and there are Multiple world Class Swerve Options - why would a team trying out Swerve for the first time not start with them? It’s hard enough to just get the wheels spinning, so both building your own from scratch, and coding it from scratch - or even a reference is largely a HUGE task, arguably harder than building the robot that goes on top of your Swerve.

For what it’s worth, outside of all that’s listed above, the biggest single annoyance of Swerve isn’t weight, or complexity (FWIW, if you implement a BLDC swerve in the Modern Era and it weighs more than 30lbs, you’re doing it wrong) - it’s the Motor Count. For this years game, assuming you’re running a Limelight, between the LL and Swerve, you’ve used 9 of 16 PDB Slots, leaving 7 for Motors. Building a good Robot with 7 Motors leaves little room for excess (can’t just throw power at things) and makes you really focus on design optimization. In the case of 708 - (1) extra motor would have been a game changer in the ball path, or made the climber much easier.

Also, to whoever noted the WCP Modules being out of Stock - the Falcon Model does appear to be out of stock* - however the V1 Module (which is still better than just about anything else out there) is in stock.

*(Also, like, you’d need Falcons for a Falcon Swerve. Too soon?)

5 Likes
28

Everything said here.

Coincidentally, we also started running swerve in 2018 with the AndyMark modules. We used some time in the offseason prior to kickoff to write the code, and even though at our first competition we had several matches where our bot failed to even move due to some mechanical failures in the modules, we had a fantastic finish to our season. Our team has swerve to thank for our breakout success that year, going to DCMP and FIRST Championship for the first time in team history and becoming alliance captains for the first time in history (twice, both at DCMP and FIRST Championship). We’ve now qualified for DCMP for the third straight season.

I will particularly second the statement that field-centric control is vital to be an effective swerve bot.

29

This might be a controversial opinion but I think the primary limiting factor for swerve for most teams is resources/programming knowledge. This is all speaking from personal experience of course.
In the off season we designed a custom swerve. Custom swerve in our experience is a great way to reduce cost but requires immense design/manufacturing resources. We didn’t get a mechanically functioning until about the 4th iteration, but the final product resulted in each module only costing about 150 dollars not including the motors and motor controllers. Our swerve chassis this year only cost about 200 more than a west cost drive. All of these design and manufacturing struggles can of course be avoided by using a kit but that costs more money.
On the programming side, our coder started and finished coding and tuning swerve in about 3 days and most of that time was spent diagnosing mechanical issues. Granted I think he is a very exceptional computer science student, but in my opinion the difficulty of programming is overhyped.
In season, swerve definitely does provide a greater challenge, we found it difficult to manage our pdp slots this year, but I think this can be both positive and negative. It forces clever mechanism design, for example this year we were forced to power both our climber and shooter off of the same motors through a ratcheting bearings. If we had the extra slots we would have just slapped more motors on for the climber.
All in all we had a great experience with swerve and I think on the whole swerve is not as daunting as most would think, not that it isn’t a difficult process.

30

I’ve already posted in this thread, but in the spirit of full disclosure I want to add some points:

  • This year for the first time in the ten-year history of my current team 3620, we decided to go with a swerve drive train. We bought the MK2 modules from SDS and we have not been disappointed.

  • Swerve would not have been possible for us without the tireless efforts of several build students and mentors, and one Senior who is both a programmer and our driver. While he and our coach waited for build to iterate through several stages that ultimately led to a completely populated robot, that student worked tirelessly on swerve code and autonomous routines, and on practice driving, both using a practice swerve chassis that had nothing on it but bumpers and an electrical system. I thought he was a very good tank driver last year, and he became an even better swerve driver in 2020.

  • Reading between the lines above you’ll see that we built two swerve drive chassis, and completed one of them as a competition robot. Expensive, but without two chassis we could not have been competitive in our first swerve season. My highlight was watching our students confidently replacing drive wheel treads during a Finals time-out (300 sec) at St. Joe. Mentors were all in the stands. Every season I am on the lookout for that magic moment when our students step up and say, “We’ve got this.” It is the moment all mentors live for, and I got to see it happen with a swerve drive during my 25th season in FRC.

8 Likes
31

You do not need to have a swerve drive to do well. While there are teams like 1323, 2910, 4911, etc. that use swerve, there are many teams that use swerve and don’t do as well but people avoid talking about those teams. There are plenty of teams who made great robots in 2019 (a game in my opinion where a tank and a turret was just as effective as swerve if both were pulled off well) without swerve like 195, 254, 971, 1114, 1678, 1690, 2046, 2056, etc. so you can pull off great robots without swerve. In my opinion, the biggest thing that separates the best teams in the world and the next tier down is how much drive practice their drive team gets.

This is a bit outdated (2011) but it’s still on 1114’s website and it’s a good representation of when you should invest in which drivebase:

image
image905×689 106 KB

In my view, running swerve is similar to using a turret. They purpose of both is to try to get more maneuvering abilities while not sacrificing other components other than complexity. The differences are a tank drive + a turret is better for games like 2016 where it’s important to deal with field obstacles while swerve has a bit more maneuvering abilities. In my view, the reason to do swerve is so you can avoid using a turret.

My advice to any teams looking to do swerve is don’t even consider using swerve during the season if you don’t already have a swerve developed in either previous years or in the off-season. Build season too short to waste time so if you don’t have a drive base in CAD basically done prior to kickoff use a tank drive.

1 Like
32

Absolutely this ^^^

2 Likes
33

Which is kind of odd given that a turret is a lot simpler than a swerve drive. We 3D printed our pulley this year and just ran a bearing stack that allowed a 3/16" plate to ride in-between them. Threw a limelight on it and it just worked. It also seemed like it was a lot easier for us to tune a PID on a turret than our swerve drive in 2018.

4 Likes
34

I think there’s a few cases where this ends up not being the case (disclaimer: haven’t done either but have researched a good amount into both):

  1. In a pick and place game, where you likely have an arm or elevator that you would need to turret

  2. Your options are off the shelf swerve (with all the preexisting code and support that exists with that) compared to a custom turret option. I would argue that just because you have to write your own code (or at least, not use things provided by the manufacturer or built directly into WPILib) it will be more complicated for some teams to do a turret.

  3. You’ve had the opportunity to do a completely identical swerve project over the summer, but haven’t done an identical turret. This is the big one to me, because the benefit of swerve (if you can get it working in the offseason) is that once you have it working, you don’t need any major changes to what you got working. By contrast, with a turret, you may adjust size, what you mount on top, cable management based on the above, where it mounts, etc.

2 Likes
35

There has been a clear preponderance of the advice that swerve is not the right choice for the OP’s team. I totally agree. However, there may be other teams reading this thread that aren’t as resource and experience limited as the OP, and are asking the same question.

4020 asked the same question after Deep Space and we made the decision to give COTS swerve a try. We made the switch successfully based on our one play of Infinite Recharge. Based on our experience, I’d suggest a list of topics that a team needs to consider to make their own decision around COTS swerve. There would be some different questions regarding custom swerve, which is not the objective of this reply.

  1. Do you have the programming team to handle it? If you think that you’ll be in the mode of copying some template swerve code and expecting that it will just work, you aren’t ready. Your programming team needs to have experience and history with solving tough problems, having deep knowledge of making motor controllers work reliably and smoothly in challenging applications, and a very good handle on closed-loop control.

  2. Do you have the budget to make the initial investment? SDS has really changed the game with their extremely well-designed and machined MK2 COTS modules. However, they don’t come cheap. The cost for the most common option to outfit a single robot is:
    $1640 (4 module kits with steel gears - which you want)
    $320 (8 NEO brushless motors)
    $600 (8 Spark MAX motor controllers)
    $32 (4 Spark MAX data breakout boards for absolute encoder input)
    $196 (4 MA3 absolute encoders with wire)
    $28 (4 VEX Versawheels)
    Total $2816
    This does not include the cost of any spares, which you really need to have. If you run the Versawheels, you’ll need to buy them by the case, but they aren’t that expensive compared to the total cost. If you buy the SDS billet wheels and tread, you’d be adding $165 rather than the $28. For many teams, an extra $3000+ for just one robot or $6000+ for two robots is a non-starter. For others, it might be very do-able.

  3. Can you allocate more than half of the robot BOM cost (a paltry $5000 in 2020) just to the drivetrain? Your team has to be ready to use KoP items, vouchers, and FIRST Choice in a very efficient way in order to reduce some of the cost of the robot, whether in the drivetrain itself or elsewhere. Your team needs to be able to design effective manipulators that are also relatively simple to keep costs down. If the BOM limit is raised in future years, this point may be less important. However, in 2020 this was BY FAR the biggest hurdle we had to overcome. Trying to design an event-winning robot with somewhere around $2500 of non-drivetrain cost is a formidable challenge. You may need a home-brew vision solution. A $400 Limelight is a major luxury with a $2500 budget. Expensive sensors or high sensor counts would be a major issue as well.

  4. Can your team design and create a robot to meet your team’s performance objectives with 8 remaining PDP slots and 4 of those less than 40A? You may find that the BOM cost limit is going to impact you before the electrical limit. The simplification needed to deal with the BOM may keep the motor count low enough in the first place. The ability to put two BAG motors on one controller and one PDP slot came in very handy for us to manage this issue in 2020 but you need to have the build team that can find solutions of that type.

  5. Does your team have a mature fall season where you can get way up the build, programming, and driving learning curves? Contrary to many statements I’ve seen, multiple years are not needed for reasonably talented drivers to pick up swerve. In many ways, it’s easier to pick up game-relevant driving skills with swerve than with tank. Nonetheless, you risk wasting a season if you try to do everything needed to make the switch to swerve during winter build season. By kickoff, you should already have very solid code, strong understanding of needed controller configuration, a very good idea of how you would build a drivebase frame, and driver candidates who are very comfortable with swerve.

Having fielded a COTS swerve robot in 2020, we don’t view it as a no-brainer that we’ll bring it to bear in 2021. The BOM cost limit is a huge problem with COTS swerve. Custom swerve teams that design and machine their own modules every year are impacted less by this, although they do have that machining issue to handle. If the 2021 rules push the BOM limit back up to $5500 or higher or swerve maneuverability looks like a major advantage in the game, we almost certainly will. It was really nice to have for Infinite Recharge even though the game is not one where swerve adds critical gameplay ability.

3 Likes
36

Wow this is wrong.

15 Likes
37

You thinking of 118 2007, by any chance? (Though that was a CRAB as I recall.)

38

Nope, just that a turret and a swerve drive have very different use cases and the idea that if you have swerve, you therefore do not need a turret to fit your priorities is very flawed to me.

3 Likes
39

We (2767) used to think swerve = turret but have since changed our view. 2017 was based on this idea and we found that tuning the robot to servo quickly (key word is QUICKLY) to aim took a ton of effort and still not as fast as a turret.

3 Likes
40

We have found that the swerve is very effective at aiming. The hard part is the vision and rotating algorithms. Both turrets and swerve positioning have these problems. Once the algorithm is developed, tuning is the key. Take lots of shots and collect data, refine.