[AlexanderTheOK]

I'm seeing a lot of posts stating the difficulty of programming a swerve drive as a con.

I would really have to respectfully disagree with this sentiment.

In 2015 my team built a swerve drive for the first time in it's history. I was in charge of programming. The first thing we did was build a miniature swerve drive out of VEX EDR Components. That took 2 people 3 days to design, build, and assemble, and me 2 days to debug. With programming, it is almost always possible to get things working before the robot is even built. If youre scared programmers can't handle it, simply test if they can handle it. (note this also works to a lesser extent with EV3 kits)

Throughout the entire process the only issue was that we had chosen suboptimal sensors for the rotation, and that there was a bug in the wpilibraries causing our configuration not to work.(edit: yes it was fixed, rather quickly too.)

No system should be avoided because of "programming difficulty" because the programmers should be starting solving problems day one with working mockups.

fun fact: I was unaware of the existence of Ether's whitepaper at the time, and can attest that working out the equations needed to direct the wheels in the correct directions at the correct speeds is trivial if the student has taken trigonometry, difficult if he/she hasn't.

fun fact 2: The derivations are even more trivial if you view a swerve drive as a "center" and a bunch of individual modules with relative coordinates x and y, instead of using L and W and constraining the code to work with a rectangular chassis. This has the side benefit of being generalize-able to accommodate changes in "center of rotation" (if your driver want's that) and swerve's with fewer/more wheels (west coast swerve anyone?)