Hello chief Delphi! Our team is looking into developing differential swerve for future competitions as an alternative to coaxial swerve. On paper, differential swerve is amazing and much better than coaxial, but I noticed that barely any teams if any at all tried to implement it.
If differential swerve is so good and it exists, then why haven’t other teams been doing it/developing it further? Are there any complications implementing it? Any issues?
With the introduction of falcons, you don’t need differential swerve because you already have too much power at your disposal.
It’s also much more difficult to design and I’m assuming to program. Coaxial swerve is much more intuitive and less complicated. Also, the best swerve modules available (if you plan to buy them) are coaxial.
I have never attempted to do the software for a differential swerve drive, but the problem of changing absolute motor speed while keeping the relative speed of the motors so closely synchronized seems like a very hard controls problem, and one that I wouldn’t even be confident the FRC controls system is capable of achieving to an acceptable level for actual use. Sure, you get 1kHz control loops on a falcon500 these days, but I would guess you really need 1kHz control loops that act simultaneously on both motors without latency from exchanging data over CAN, if even that could do it to a level that compares to traditional swerve.
And Neos, a year earlier. But otherwise I agree with this take.
Differential swerve is harder to do and so far no one has shown any performance advantage that makes it worthwhile. The ones I’ve seen so far are so twitchy that the PIDs appear to be throttled way back just to keep the steering stable.
A long, related thread:
We were part of the Beta test program for those modules. We probably did not get as much out of the modules as we could, but our experience was that controlling diff. swerve modules is hard. You need to control 2 motors very tightly. Currently that is only possible over CAN bus, so you are dealing with timing and accuracy issues. In my opinion (but this is not my expertise), diff swerve really requires a custom control board which can control both motors “instantaneously”.
Here is some info about team 5687 Outliers and their differential swerve they ran this year.
Edit: On mobile I messed up the highlighting.
But here is the statement from the team themselves:
Would we recommend developing a differential swerve? For most teams no. I don’t think there is much of a performance advantage (unless you really need the torque), and there are significant disadvantages. Additionally, they take a lot of time to develop properly and that energy that would go into fussing with the swerves is probably better spent elsewhere.
Overall we had pretty good success controlling our differential modules on the Rio, but I would tend to agree that differential swerve is not particularly worth it when there exists an abundance of resources to program and design normal swerves.
We decided to use LQR and got a decent performance out of our modules yielding pretty much zero jittering on the angle and pretty dang accurate wheel velocities (something like 0.1-0.3 m/s error). Here is a video if anyone is interested.
This definitely wasn’t the easiest thing to program, but it was fun and we learned a lot.
One of the main reasons no one really does them (from a mechanical perspective at least) is that pretty much every concept for a diff. swerve requires some very complex machining on a 3 axis CNC mill. While there isn’t really any 4 or 5 axis needed, you still need axis to CNC and a very skilled machinist whose able to put in the time to make many complex parts (for example the spur-bevel gears that our team developed a few years back). You could maybe mold/3D print the gears out of PEEK for something with similar robustness to aluminum, however, that too is incredibly expensive and would require a sponsor that could mold it for you or a pricy high-temperature 3D printer. I’ve also seen some FTC teams make them out of what I believe is just standard PLA or ABS although that probably wouldn’t cut it for FRC where robots get hit harder and the power transmission through the gears is much higher. In general, for most teams, diff. swerves have a high monetary, experience, and time cost for what is generally viewed as unnecessary power gains. It is pretty cool though 
The advantages on a properly torque/traction limited robot for a differential swerve are largely efficiency related at this stage. You don’t really gain much total torque in level scenarios (though you could gain some when weight is shifting to one side); if you try to output that torque anyway, all you’re going to do is wear away at the carpet and tread faster.
Every time I think about differential swerve, I need to draw a picture and do some force and torque diagrams. Then I say, “OK, that’s how it works.”
While it seems elegant in premise, it is not simple. It also seems (as others have said) to be a big challenge to make it work well.
I propose your team attempts to manufacture ONE diff swerve module. Then program that one module. Maybe put it in the middle of a small square chassis that has four casters (or omnis) at the corners. Then see if it behaves predictably.
It will be a really educational experience. The CAD kids and builders will have a lot of work to do. The programmers will too. They can build skills that will be useful in all areas of FRC.
Then, you can decide if you want to try ramping it up to four corners of a 120lb robot that gets hit repeatedly!
This is 100% our reason for not going down this path… And we tend to have 1.5-2x the amount of contact patch on the ground vs most COTS solutions.
It’s a traction limited game now, not power.
When i had this convo with my teams mentors on why it didn’t exist they explained it as a code issue. They said that mechanically the problem is solved but code wise the finesse just isn’t there for differential swerve.
I’ve been working at the software problem on-and-off for almost 3 years at this point. We have fairly solid hardware at this point. But the controls are very difficult due to the complicated relationship between steering and driving, and I don’t think it is for the reasons most people expect. Here are just a couple examples of challenges that I’ve seen.
(1)
Imagine you have a module that is totally stopped, and you want to make it go full speed forwards and turn slowly to the right. This is something that happens a lot during normal driving.
You do the math to convert from steering and wheel speed to motor speeds, and get 6000RPM for Motor A and 4000RPM for Motor B.
You then pass these speeds on to a velocity controller for each motor. The controller decides to send 100% power to Motor A because the error is large, and… 100% power to Motor B because the error is also large enough to saturate the output.
Both motors accelerate at about the same speed until finally Motor B is fast enough to not saturate the controller. During this time, you have no control over steering.
(2)
Say you want to command the robot to drive full speed ahead while spinning. With a standard swerve, you can’t quite do this. Some of your wheel speed needs to go towards spinning the robot, so you won’t be going forwards at full speed. Fortunately, this issue can be painted over without doing anything too complex.
On a diff swerve, there is an extra issue. Driving while spinning requires your modules to constantly be steering. And steering takes away additional speed/torque from the wheel.
This is especially concerning at the start of the maneuver, when some modules might be pointing in the right direction and others in a totally wrong direction, meaning they need to steer at different rates and therefore have the wheels also accelerate differently.
I’ve observed this causing erratic behavior when try to go from stopped straight into a fast drive+spin, and be stuck driving out of control for 5+ seconds until either all the modules get lined up well enough to regain control or the driver lets go of the sticks.
I’m actually not sure it’s better on paper either at this point. The number of motors powering your drivetrain is not always the limiting factor in how your drivetrain performs. “just” four brushless motors for drive is already pushing the limits of what a robot can achieve with common traction materials at this weight class.
Discussions of differential swerve were thrown about mostly in the brushed motor era, when a four motor, non-shifting drivetrain was adequate but not ideal for all purposes. We have so much more available power now, that the very significant challenges of implementing a differential swerve aren’t possibly worth the relatively marginal benefit anymore.
Could this be solved by giving turning and driving separate “chunks” of motor control that together cannot saturate the output of a single motor? It could be a constant split (which would limit the overall output of the module) or you could scale the split based on requested steering/throttle outputs.
There’s already built in functions in wpilib to desaturate motor outputs.
I could be totally off base here, just spitting out what’s in my head.
You could definitely do that. A constant split would be easy, but it means you will be leaving some available power unused. Since the benefits of diff swerve are already pretty marginal, I feel like it isn’t worth running if you aren’t taking full advantage of them.
Dynamic scaling is better. It avoids the saturation problem, but even if your outputs aren’t saturated, there is still nothing working to keep your motor speeds correct relative to each other while they are accelerating/decelerating. The velocity controller is only effective once you’ve achieved the setpoint.
There are solutions to this problem, but they force you to move away from running a standard velocity PID on the motor controller, which means you lose that nice 1kHz internal control loop.
Every time I have done the math on this, you will either have way too much torque at stall which will cause the wheels to lose traction, or your top speed is so high that you can’t really control it. The peak power point is somewhere in between.
You could gear the modules to eliminate the traction limitation at stall. This would end up with something like 3:1 or 3.5:1 driving a 4" wheel which is insanely fast. By bringing in some current limiting at low speed (near stall) and then gearing around 5:1 you can get quite a bit more acceleration than a standard swerve at moderate speeds, be living right on the edge of the traction limit at lower speeds and still have more speed that you can really use.
But now, you basically allocate the top 10-20% of the motor speed to steering only (in other words the “drive” portion of the motor speed allocation is capped at 80% or 90% of the max motor speed). This is still probably faster than you can control in most circumstances, but it might give you that turbo boost you need in certain conditions so maybe it is useful. Now, with that 10-20% of the motor speed you can steer. If the drive speed passed to the module is D and the steering speed is S, then motor 1 gets D+S and motor 2 gets D-S. I would be willing to bet that if S was always limited to that 10-20% (even when the drive speed D was quite a bit lower than its maximum value) the modules would be plenty responsive. And now, when you are driving straight at max speed of say 80% motor speed, you are actually closer to the peak power point on the motor curve than you would be if you were running a standard swerve module geared right to the traction limit.
So, by taking advantage of the fact that you have double the drive motor power available, you can gear the module higher giving you the extra speed to use for steering and giving you greater power and acceleration in the mid to high speed range.
At least this is how the math works out for me. While we have talked about doing diff swerve for several years (it is the holy grail of swerve), we have not gone any further down the road than running the math. With a couple of other teams out there providing pretty solid mechanical designs that would not require crazy machining capabilities, this may be the offseason where we actually start cutting metal.
I still think it’s a fun controls problem and can probably compete on mechanical weight/complexity if designed cleverly (I’m a huge fan of designs that avoid the differential gearing and instead just drive two separate wheels on the ground).
A good COTS design and a few hundred lines of software support might be all it takes (it’s just an ordinary swerve which delegates to a PID-governed DifferentialDrive for module control).
When we test Diff Swerves, the biggest problem was that initial high G launch everyone wants from their robot.
We could never get the 2 motors sync’d well enough that we didn’t get wild oscillations when we floored the robot.
It forced us to set a far lower ceiling on max RPM and also max acceleration, which sounds like what everyone else has had to do as well.
RIO was not fast enough to run a PID loop to control the motors. Doing a velocity PID on the motor controller helped but didn’t completely solve the issue. We thought eventually to make sure this worked well, we would need to do a PID on acceleration as well, essentially some hybrid form of motion magic/motion profiling - generated on the fly, in real time, to control velocity and acceleration of both motors. I don’t think that is possible yet from a Talon FX.
On top of that, add in 3 other pods and they start introducing jitter into each other as well.
To the OP, this is an awesome engineering problem. Do it for the learning experience. But if you haven’t done traditional swerve yet, do that first.
Did you try running a PID faster than the main loop? By default it’s only 50hz but you could put the PIDs on a 100 or 200hz loop pretty easily