Is there any real benefit with going with a square over a rectangular chassis, as a lot of the top teams seem to prefer square chassis for their swerve bots this year? I would think that the only real difference would be in the coding, but even then it shouldn’t be that big of an difference.
The only code difference would be changing the module locations in the SwerveDriveKinematics constructor. If you are given the wheel base and track width and use that to calculate locations, then it’s as simple as changing those two constants.
6 Likes
As far as I know it is just for simplicity; no major code changes, as long as you still know where the mods are, you would just plug in the rectangular locations.
6 Likes
The only other consideration might be the stability of the robot in the narrower dimension. Given the limits on frame perimeter, if you make the rectangle too long you might make it less stable and prone to tipping on the short axis. A square is, of course, equally stable (or not) in any direction.
2 Likes
We did a very rectangular Swerve This year, and I would not recommend it for most situations. We liked the long space for our ball path, but the stability of a 36x23 was rough. We had a lot of creative code to minimize tipping. We also found if you t-boned us on the long side, we could not rotate off the defense, which was a major flaw. However, this same flaw was also a hidden strength. We used this to our advantage when playing defense and it worked fantastic. We could shut down even fast swerve teams like 6800 or tank teams like 176 quite effectively, and they could not pivot off of us due to our length. This led to that combo picking us for defense on Roebling, which was an incredible alliance that would have been hard to beat had it not been for our mechanical issues on Saturday combined with various bugs that appeared with 6800s serve. If we remade a robot for this season it would be a square swerve, but rectangular is both possible and effective in situations
9 Likes
Relative to the swerve itself, the shape of the chassis has very little effect on the drive characteristics. As @Strategic noted, you gain stability on one axis by making it square, but you lose a little stability on the other axis. Depending on the CG of the robot, stability can be a factor (in general if your CG is low enough, the wheels will slip before you will tip).
This is the first year that I know of that we have done a square chassis for our swerve (we may have had a square chassis in 2015, I can’t recall). In previous years, there was some other constraint on the robot that drove us to a non-square geometry. In 2020, for example, we wanted to be able to get all 5 PCs in a straight line in our conveyor, so that drove us to a longer chassis in that direction. It also helped to move the shooter further away so from the intake so that we could make shots in the high port while in the protected zone. It also made the robot narrower which made the trench runs a little easier (more room on either side of the robot to get under the WoF. We were actually worried about how long and narrow the robot was in 2020, but it turned out to be just fine from a stability standpoint.
I could give similar examples of design constraints on other aspects of the game and robot design that drove us to non-square frames in other years. These other consideration are what dictate the frame configuration, not the swerve drive itself.
2 Likes
If you actually have a square layout with all 4 modules oriented the same way, there’s a significant software optimization you can make when calculating the rotation vectors for each module (the X and Y magnitudes of the decomposed rotation vectors will all be the same for all modules, with only the signs flipped), so you might be able to squeeze a little extra out of your CPU. Some of the earliest code examples you can find online used this trick, actually.
Rectangular layouts have a similar but less significant optimization because X and Y rotation magnitudes won’t be identical for a single module, and will alternate X and Y for adjacent modules.
But I would imagine most teams are using the built-in kinematics software now and wouldn’t realize the gains anyway.
2 Likes
This is a pretty trivial optimization and won’t be noticeable at all in practice.
8 Likes
Back of the napkin, even if you figure trig functions on an ARM Cortex A9 take hundreds of clock cycles (which is reasonable based on most library implementations) it’s not going to be more than 0.1% of the 20 ms loop time even if I’m being generous.
So yes, I agree, it wouldn’t be noticeable.
4 Likes
On the flip side, @JN25 on 2363 observed on discord that this simplification might make a noticeable difference in the performance of swerve trajectory optimization (since in that context you’re computing a whole lot of kinematics transformations as part of, say, a gradient climb) - so perhaps there’s some use for it yet!
3 Likes
Where? They didn’t actually make that approximation in their implementation:
It hasn’t been implemented yet; we only discussed the possibility.
At least based on the implementation above, I don’t see how that’s saving you any work. The module states are linearly independent, so you have to compute four copies of the math regardless.
EDIT: If you disallow kinks in the swerve drive trajectory (probably OK in practice since it’s holonomic), you could speed up trajopt by exploiting differential flatness of x, y, and heading. Then your decision variables can be about 10 spline coefficients instead of x, y, heading, and velocity decision variables for each timestep (adds up to potentially thousands of decision variables).
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.