Diff Swerve Beta2, The Controls & Software Boogaloo

FIRST General Forum
, , ,
1

Join the Diff Swerve Revolution!!!

TJ2 (Team #88) is working to make Diff Swerve a reality. An FRC drive system that is easier to implement than tank drive while just being better in terms of mobility and pushing. It’s a tall order (see this thread for more details on the design Dr Joe’s Diff Swerve).

We had a beta test with 3 teams over the summer (Thanks Ligerbots #2877, Ursuline Bearbotics #6391, & Robo-Falcons #8179). The beta test taught us a lot and we are making improvements to the mechanical design as a result. The MOST important thing we learned with the Beta Test is that Diff Swerve Controls Software is hard. Swerve software is hard all by itself but it has been around long enough that a lot of the hard bits have been figured out. Controlling Diff Swerve is another level of complexity. The coupling of the steering & driving outputs is really straining the limits of what ad hoc PID Feedback loops are capable of.

We want to take a step back build a global control structure, one that can smoothly handle autonomous and teleop modes, handle module level constraints like motor speed and torque limitations but also global constraints such as such as total drive system current limitations, brown out avoidance, smart brown out recovery, …

Beyond the “well behaved robot” problem we need help building Software Dashboards, Setup, & Debugging tools.

Ultimately, we want to publish a code library that makes Diff Swerve Sing while also making it super easy to implement, debug, maintain, and drive.

Next steps: Diff Swerve Beta2, The Controls & Software Boogaloo
We are reaching out to the FRC community to help us get the controls & software right. We are going to select a handful of teams to participate. DM me if your team is interested in applying. We need teams with solid controls & software capabilities.

Details:

  • TJ2 will provide 4 diff swerve modules (your team provides the chassis, FRC control system, Falcon motors & CANcoder sensors).
  • Oct. 31 Betat2 Team selection complete
  • Nov. 6 modules shipped to Beta2 Teams
  • Nov. 8 (week of) Start Weekly Zoom Planning meetings to coordinate efforts and share results
  • Dec. 31 Beta2 Ends (hopefully with a concert of Singing Diff Swerve Chassis).

Will we have a Beta3 for teams that want to try out Dr Joe’s Diff Swerve in the 2022 season? Possibly. But we have to have a successful Beta2 first.

Final message:
DM me if you want to be considered for Diff Swerve Beta2, The Controls & Software Boogaloo. Tell me a little about your team and why you’d be a good fit to help us make Diff Swerve Sing.

Join the Diff Swerve Revolution!!!

Cheers,
Dr. Joe J.

14 Likes
3

Austin Schuh wrote an interesting post talking about the limitations of CAN controlling a differential swerve in 2017. I think it is worth a read for anyone planning to take on this challenge. I know there were some changes to the CAN stack in 2020, but I’m not sure anything was changed to resolve the concerns mentioned in that post.

Excited to see what people come up with here!

3 Likes
4

I wonder if there’s a possibility of making a variation on the “follow” mode for this? There would be one motor designated as the “main” motor and the second motor is told to mimic the “main” one. When steering you would have a signal to tell the follow motor to loose or gain some encoder pulses. Maybe we could get a revision to the firmware for the Falcon and SparkMax to implement position following with a ± shift?

1 Like
5

Interesting idea. I am not sure that it addresses the problems we are having. It isn’t that hard to mathematically decouple the two inputs and outputs (in fact it is sort of trivial - it boils down to a few matrix operations).

To first order, you can just treat the motors like any other swerve module.

BUT… then you are left with a ton of corner cases where you need to be sure that you’re not asking for more speed than one or other of the motors can provide. Even that wouldn’t be so bad except for the 8 Bad Dad Motors all pulling juice from an increasingly undersized battery.

It is surprisingly easy to generate conditions that brings the batteries to its knees. Coupling the motors the way the Diff Swerve does, makes it easy to cause one or other of the motors to have to rapidly reverse course causing huge current spikes.

Even this, you can kind of paper over with code by trapping a bunch of special cases but in the end I think these are band-aids on a deep wound. There has to be a better way.

And so we are looking for that better way.

Join the Beta2 Boogaloo and help us find it.

1 Like
6

Thanks for that post. Very interesting indeed. @AustinSchuh if you are in the sound of my voice, I would love to have you on the team trying to make this work. DM me.

Diff Swerve for the Masses. It’s coming IF we can get the controls good enough (and plug and play enough). Help make it happen.

7

Joe, have you done any testing to see how having 8 (or even 6) drive motors gains performance over 4 drive motors?

In testing I (and 33) have done previously between 4 and 6 drive motors (done with NEOs), we found that in time to distance trials at various lengths that there was barely any difference in performance. The 6 motor test barely got there any faster.

I’m not sure what the main advantage of diff swerve will gain here without the robot getting heavier to increase traction, or a significantly lighter robot to make it easier to go faster, or some other way to increase traction. In addition without a new battery, I’m not sure how much there is to gain from more motors without the power to feed them all simultaneously enough to make a noticeable difference.

If you’ve done some testing and have found some measurable performance gains with the extra motors, I would love to hear about them.

1 Like
8

We haven’t done exact A/B comparisons but we should.

The biggest difference we have noted is the trade off with top speed and pushing force. With a traditional swerve set up (4 motors driving wheels, 4 motors steering) set up with a full weight robot, reasonable top speeds and grippy tires, the 40A breaker on the motors becomes the limit to pushing. While with Diff Swerve (and its 8 motors), the pushing limit moves to traction.

Is that worth the extra baggage of having to manage coupled motors and potential battery sag? TBD.

I will say that the tradeoff is cleaner in this case vs. just throwing more motors at a tank drive (and not just because shifting is more straightforward in that case).

Any good Swerve is going to have 8 motors in the system anyway. Steering has a much lower power requirement than driving. It seems to me that if (and I know it is a big if) the controls problems of Diff Swerve can be effectively addressed, there will be some cases where it will be an advantage over standard Swerve by simply moving some of that power from the steering over to the wheels.

I don’t want to say it’s free money but it kinda is… (again if you can develop effective controls).

9

We found that traction can be an issue even with 4 motors however this problem runs neck and neck with battery sag. I concur with Nick that as far as a benefit from more than 4 Modern brushless drive motors is not there but I wouldn’t let that get in the way of diff progress. I say this in the interest of science!

How about shrinking the motors.

You should be able to set current limits in the controllers to stop brownouts and popped breakers. If the math comes out right, 8 drive motors at 25A per motor. This is still 50A per wheel (which is where we run our current limits for the drives). At this point, you can run 8, NEO 550s or 8, RS775s. At 25A you won’t hurt either motor. 2, NEO 550s make about the same torque at 25A as a Falcon makes at 50A and at a faster RPM.

I would think (not a software guy) that you should be able to handle your corner cases by first coming up with a “center” speed for the motors and when you azimuth, 1 motor goes down and 1 motor goes up. If you’re about to command the up motor over 100% then shift the center speed so the down motor makes up the proper difference or just have the down motor make up the difference. I think you understand what I’m trying to say. I realize this might not fit in the current software architecture but it’s a theory worth pondering.

3 Likes
10

Are you looking for a full software, or someone to build on existing code? If you’re using CAN, as others have noted, you may be severely limited by the bus if you’re doing PID on the Roborio. Using the internal Falcon or NEO PID for control is a must if you want those tight 1ms loops.

Updating your setpoints should be done as fast as you can without killing the bus for your initial tests. You can always slow it down later once you have the ideal. A 1ms update rate might not work well but 2-3ms on 8 motors should be achievable.

11

This falls pretty quickly out of the differential drive kinematic equations if you solve for \omega_\ell and \omega_r (\omega s are motor speeds and module rotation speed):

v = \frac{r_{wheel}}{G_{drive}}\frac{\omega_r + \omega_\ell}{2}
\omega = \frac{\omega_r - \omega_\ell}{G_{steer}}

The problem is that if you shift the desired wheel speed or module rotation speed down to account for actuator saturation (limits of how fast you can spin your motors) you stop tracking the commands generated by your upper-level swerve steering system, so one of your wheels is spinning slower than desired or pointing in the wrong place. In theory you would have some control law that coordinates the actions of all four modules to try and match the commanded full-robot (v, \omega) while accounting for saturation and making sure all wheels obey the swerve constraints.

2 Likes
12

:THIS: is exactly why I say we need to have some sort of global solution to the problem.

Here is the terrible logic:

  • With Swerve, any two module azimuth angles defines a center of rotation.
  • Once you have a center of rotation, you define the ratios of the rotation speeds of those two wheels (defined by distances to the center of rotation) or you will be dragging tires.
  • Every set of two modules defines its own center of rotation and has its own ratio of wheel speeds.
  • All pairs of modules have to agree or again you’re dragging tires.
  • And so, every module’s azimuth and wheel speeds are coupled to every other module’s azimuth and wheel speed
  • Diff Swerve adds the coupling of the azimuth angles and wheels speeds (which rapidly multiplies the conditions in which you’ll run into a constraint or limit – want a module to steer rapidly to another angle? Too bad! the module’s wheel is already spinning at top speed. If you want to steer you have to slow down! Sucks to be you)
  • Soooo with Diff Swerve, running into any limit on just one motor needs to be coordinated with changes to all 7 of the other motors.

It is exactly cases like this that have convinced us that we need to take a much more global approach to the problem that is possible with PID loops, some linear algebra, and a standard Swerve control scheme.

Interested becoming part of the solution? Join the Beta2 Boogaloo. DM me. I’ll give you the deets.

2 Likes
13

As you stated, diff swerve has the potential advantage of making pushing traction limited rather than limited by the 40 amp breaker.

So, you should apply the full stall torque of the motors to the wheels up to the traction limit at a lower overall gear ratio.

Let’s assume that the overall gear ratio is 6:1 with a 4" wheel on a traditional swerve drive. This gives a theoretical free speed of the robot of 16.8 ft/s with Neo motors. This gives a sprint time to 30 feet of 2.24 sec according to the ILITE drivetrain simulator. This design is not traction limited for a 125 llb driving weight.

With a diff swerve, if we reduced the overall drive ratio to 4:1 with the same 4" wheel, you would have a theoretical free speed of 25.2 ft/sec and would have a sprint time to 30 feet of 1.72 seconds. This design is in fact traction limited for the first part of the sprint and the overall ratio could be reduced a bit if you wanted to go even faster. And this design provides 33% more pushing force than the traditional swerve configuration assuming neither is traction limited.

So, with diff swerve, you can reduce the overall drive ratio and still get increased pushing force. The lower overall gear ratio means higher speed.

So, with that higher speed, you could simply reduce the maximum “center” speed (as @Mark_Wasserman called it) giving you ample “headroom” between that maximum “center” speed and the maximum motor speed to allow for a decent azimuth speed. Even if you capped the “center” speed at, say 85% of the maximum motor speed, the theoretical robot free speed is would be 21.4 ft/s which is still significantly faster than a traditional swerve. With the 15% of the motor speed that you held in reserve, you could put +15% speed from one motor and -15% speed from the other motor into azimuth steering rotation while still maintaining the same average motor speed to the wheel. Thus, you do not defeat the upper level swerve commands (since they limited the average speed to 85% of the maximum motor speed).

Honestly, I think this is a completely viable approach. As long as you adjust the total drive ratio to account for the fact that you have more available power, you should have the excess speed you need to slow down enough to steer.

IMHO.

1 Like
14

Having fielded a 21-ft per second tank drive in 2017, that is more than enough. After that experience I push towards 17-18fps as being Plenty Fast Enough. Which puts your steering headroom closer to 30% with your same theory.

2 Likes
15

I would tend to agree with you with regard to the maximum speed. We made a mod to our drive ratios that increased our theoretical speed to 21 ft/sec as an experiment on our swerve drive and the drivers were struggling to control the robot (on the 2020 field). But, there may be field configurations where this faster speed makes sense.

With Diff swerve, you are allowing the power from all 8 motors to go to the wheels. You can use this power to increase your acceleration, increase your max speed, increase your available pushing force or some combination of all of these depending on how you gear it. Trying to max out all of the above is likely too much (especially with Falcon or NEO drive motors). Opening the door to smaller motors to save weight is also an option although the weight savings associated with smaller motors would likely be offset by the additional gear reduction needed due to the faster motor speeds.

I think you and I are in agreement that with the extra motor power, there exists a reasonable compromise to the max speed that allows a KISS programming solution while still preserving the extra pushing force and probably still being able to increase the max speed and acceleration considerably over a traditional swerve configuration.

16

Great points. I like the idea of artificially limiting wheel speed to keep some in your pocket for steering. It might be a viable approach.

This might be something that a team joining the Beta2 Boogaloo may decide to explore.

I ALSO like the idea of doing some fancy math and controls work once and gaining the benefits forever more. So until I am convinced that there isn’t a better solution available (via MIMO control theory or some else), I am still going to be pushing for a control system that rings every drop of performance that we can out of Diff Swerve. If it turns out not to be worth the bother, I’ll sleep well, knowing I fought the good fight.

2 Likes
17

We have already been down the same road with traditional swerve. We allow the motors to go up to full speed when driving straight, but once you introduce some turning only one of the motors can operate at full speed. Therefore we reduce the speed of the other motors in the swerve math by multiplying the resulting matrix by a factor such that none of the terms in the matrix can exceed 1. This is done dynamically (the factor is calculated each cycle as the inverse of the largest term in the matrix) such that you always are able to maximize the available speed while satisfying the desired motion. It does cause the robot to slow a bit if you command a radical maneuver. But generally, the robot is going to tip over if you command a radical maneuver while travelling at top speed, so at a higher level, you are probably going to need to limit the input commands as a function of speed anyway and it is probably wise to stay away from this particular corner case.

With Diff swerve, instead of 4 motor speeds being the terms of the matrix, you now have 8 terms in the matrix for each of the 8 motors. So, you could use the same trick of multiplying the entire resultant by a factor such that no one term exceeds 1. Since the largest term will likely be further above 1, you may end up reducing the max speed more significantly with this technique. But it may be worth trying.

18

From personal experience an MIMO system for each module worked out the best for 5687s differential swerve modules (Although I didn’t try any alternatives). Last year I implemented a LQR controlled module with the introduction of WPILibs state space controls. We created a wrapper class for each module running at 200hz. This followed the same structure of what WPILib did for other state-space systems (i.e LQR controller, Kalman Filter state estimator, etc.). We used a bore encoder for the azimuth angle and the integrated encoders of the Falcon500’s for module wheel and rotational velocity. As stated in a post above we never allowed the modules to reach full translational speed so the controller would have the capacity to have azimuth angular velocity control. I cheated a little bit by not used the estimated state of the angle as there was an issue where when our angle surpassed -pi to pi, the state estimator would go though all the states between those values. Thus causing the module to always take the longest path. This could be fixed but time and laziness got the better of me, so I just used the encoder value as feedback. As for performance of the modules, if I recall correctly we got it to be about 10A per motor for each module under normal use. I only have our first iteration of our modules on video, but we also have a video of our robot driving from the at home challenges.

I should point out the the modules were perfectly operational by giving ~6-10% of translational speed for a chassis bot.

19

I don’t have a huge amount of time, but I wouldn’t mind discussing options. I like meaty controls problems :slight_smile: Assuming you are willing to run the actual control loop for per-module controls on the RIO, that is actually pretty straight forwards to design. Especially if someone wanted to help put together the physics model for a single module, I could be persuaded to sketch out a statespace controller that would probably work rather well with minimal tuning.

If I ever get enough time, I’m tempted to go the way of team 900 and move over to my own CAN stack on another controller on the CAN bus. That is legal as far as I understand. That should enable much more control over the bus traffic, and I could then use it to show what becomes possible with some more control over the bus.

There is something very nice about running a current loop on your motor controller. It gives you much more control over the thing you end up caring about (either torque, breaker current, or motor current/heat).

8 Likes
20

Dumb question, wouldnt an lqr cost function tuned to prioritise efficiency solve the battery issue?

21

Say more about current loops & motor controllers, especially with regard to Falcon 500 motors. What does it buy us? What are the reasons against it?

With regard to moving the CAN stack to another controller, again, help me understand what that means, why I would want to do that, and the difficulties we’d encounter. In general, of course, I would like to stick with code running on the RoboRIO BUT… if high performing, well behaved Diff Swerve requires adding a Jetson (or two) to the mix, I’m not going to rule it out.

2 Likes