SDS MK4 Confusion

We ran l2 ratio this year and found it to be quite nice. L1 is traction limited so you don’t get much more pushing power or acceleration. The extra free speed of l2 is very helpful for outswerving defenders and general maneuverability, and can still be easily controlled with some driver skill.


Oh I see, thank you!

Might be worthwhile to meetup with a local-ish team and talk to them about their experiences with swerve/test drive their robot.


My team ran L2 (with falcons, not neos). With quite a bit of practice, I was able to control it at full speed and get a significant amount of pushing power from them. I did run most of the season at about an 80% speed limit because L2 can get quite quick if you’re not experienced with swerve driving.


Remember, it’s not all about top speed – acceleration makes a large difference as well. So it’s worth thinking about time/distance to top speed, and it would be nice to have some of this data more readily available. This does bring in the mass/weight of the robot and the number of modules, but it’s reasonable to make assumptions when sharing this data for purposes of comparison.

One way this might be done is for teams/vendors to publish SysId data for a given drivetrain, with the test drivebase weighted to some reasonable total weight.


Besides the obvious cost difference , what are people’s thoughts on Falcons or Neos for SDS modules ?

1 Like

I know the “real” swerve drive people here all preach the gospel of Falcons, but it will be much easier for my team to buy our first swerve and test it this summer if we can use new NEOS and eight Sparkmax that we already own.

$135 per motor less money. $1080 less for four.

And even if we buy new sparkmax controllers, still $55 less per wheel.


Will do, thanks!

Got it, L2 does sound like the sweet spot so far…

I will say that using falcons is much more ideal and maybe in the long run more economical. We have had 3 neos brake, 1 neo 550 brake and 3 sparkMax’s break in the past 3 years. This post is nothing against Neos or Rev (we have still gone back to using neos on everything but the drivetrain) it is just from my expreience that you have to be much more careful with neo’s/neo 550’s. That being said, in @BigK8816 's case, neos seem like the obvious choice.

1 Like

Right, as a rookie team that just finished its first season, my team really shouldn’t be spending more than 2k on any one component of the bot from a sustainable finance perspective. We aren’t fully opposed to going for falcons in reality (pushing the total cost to about $2.6k) since there will always be a way to make up for the extra cost, but where it gets difficult is that we are unable to purchase items over Summer, when the MK4 will most likely get back in stock. If we miss that chance, then we miss the L2 option so yeah we’re trying to see what options we can get as of now.

I don’t think there’s any reason to switch away from Neos if that was your plan.

If you really want to make sure you pick the right ratio I recommend you put some numbers into @JesseK 's iLite drivetrain simulator. You can adjust the parameters to find out what ratio will get you to the end of any given “sprint distance” fastest (including acceleration, wheel slip, current limiting etc.)

TLDR: Anywhere within ~20% of the KOP ratio (10.75:1 on 6" wheels, 7.2:1 on 4" wheels) will pretty much optimize the 15 to 20ft sprint IMO.

1 Like

You want an external encoder for velocity control with a NEO. Other than that, the only differences are wiring, convenience, and price.

We have used the WPILib Ramsete library for our autos since 2020, which uses closed-loop velocity control afaik.
We ran a very successful 5 ball auto with NEOs in 2022 (won an auto award for it).
We had a very reliable 10 ball auto with NEOS in 2020 (also won an auto award).
So I dunno, maybe there’s extra performance to be had if the Spark Max’s had less encoder latency, but we haven’t found it to be necessary.


Ditto with above. We ran some good autons with only integrated encoders on our swerve and saw no meaningful affect. At the highest level of play, there may be an impact if your auton requires abnormally high precision, but we haven’t hit that roadblock yet.


We also had a 5 ball auto using built in encoders on a swerve using wpilibs swerve classes.

1 Like

That’s mostly position control, not velocity. The encoders work fine for odometry.

1 Like

How much a mechanism can accelerate in one timestep (e.g., 20 ms) determines how much the filter delay matters. It matters more for low-mass things like flywheels than for drivetrains.

You could try plugging in the feedforward gains and filter delay for your mechanism into the Python script here to see what performance you’re leaving on the table.


Do you know if anyone has good numbers to put into the calculator? The gear ratios are easy to grab from the SDS product page but I’m not sure what else to put in for coefficient of friction, voltage ramp, or current limit.

Some of these you have control over in your design. Others you can adjust to see how “sensitive” the results are to changes. But I generally use:

  • COF = 1 (about average for FRC wheels on carpet)
  • Voltage Ramp = > 1200 V/s (leave as default, unless you already limit voltage ramping in software for whatever reason)
  • current limit = 40 or 50 A per motor (or whatever value keeps your voltage above 8V and prevents brownouts) assuming you do current limiting, and if you don’t you should.