My team is working with swerve for the first time this summer, but we don’t have enough of the same motor for 5 modules (4 on the robot + one spare). The motors that we have right now are 8 Falcons and 8 Neos, so we only have enough for 4 modules. We are using SDS MK4i (L2) modules. Our current plan is to have the driving motor be a Neo and the steering motor be a Falcon, since this will allow us to have 5 modules. Before we proceed with this plan, we would like to hear of other team’s experiences doing this.
Questions we have:
Which motor should we use for driving?
Is there any preexisting code for this?
Would it be better to have only 4 modules and use the same motors for driving and steering?
TLDR we used neos, swerve is a pain to program, use the link for some code you might need to tweak.
Last year in our offseason we started swerve with only 4 modules, we used all neos and not previous experience. Me, as the lead programmer, had to figure out how to program them. I started with the library given be SDS but turns out it’s old and not very efficient. Switched to base falcon swerve and it only supports falcons. Found a neo version of base falcon swerve and it had problems. Fixed those problems with much pain but now I have experience, yay .
I recommend for you to use BaseFalconSwerve except you will have to do some tweaking for the neos
From my teammate’s personal experience with driving two robots similar in weight and size, falcons are better suited for speed rather than torque, and neos can do a combo of both (if geared correctly). Since turning a wheel requires less torque than driving it, i agree with your decision of using neos for driving and falcons for steering.
From a software perspective, you may want to use the Falcon as a drive motor since the velocity encoder feedback is far better than the NEOs. I don’t think the speed or torque differences between the two motors matters very much, but the difference between open and closed loop velocity control can make a very large difference for autonomous accuracy.
We had a similar situation this past season. Eight Falcons from previous stock, but lots of NEOs. We’ve found that Falcons give us a bit more ground speed for a given gear ratio. It’s a nice little boost without moving to a higher gear ratio and a lot more speed but less torque. We chose to run Falcons on drive and NEOs on steering. This gave us enough Falcons to have spares, but we got the little speed boost and we got the Falcon velocity control advantage for odometry.
I don’t know if there is any pre-existing code for doing this or not. It’s not particularly hard to create objects and call methods for both Falcons and NEOs. Rev has some nice syntax conversion documentation that’s useful whether you have experience coding for Falcons or for NEOs.
As long as you are constrained to eight Falcons and eight NEOs, it’s a much better plan to mix them on your modules so you have spares. If you get more of either, your decision opens up again. Teams have been successful with NEO/NEO, Falcon/NEO, and Falcon/Falcon. It’s really your choice about which ecosystem(s) you want to support, your ability to purchase particular motors, your take on pros/cons of integrated vs separate motor and controller, and how you feel about cost differences.
I’ve linked it a lot, but FRC 3512’s code is basefalconswerve for neos. It doesn’t have the updated 2023 odometry though, but that isn’t too hard to fix. Our team was able to do that and can be found here.
My suggestion would be to use the Falcon for the drive and the NEO for the rotation. As other suggested above, the Falcon is debatably slightly stronger than the NEO but it really won’t make a big difference. The difference comes in the motor controllers.
NEOs have a known issue with the filtering on the closed-loop velocity controller which may make tuning your drive PID harder. And if there is a power advantage, you want the stronger motor on drive.
The SPARK MAX have the ability to take direct input from an absolute encoder. If you were using Falcons, you would need to use either a CANcoder or the RIO as a middleman. With the MAX, you can get absolute position feedback for the swerve angle without having to add devices to the CAN bus or manually code it through the RIO.
If the motors are sticking up, it’s not an inverted motor setup. If that’s actually an MK4i, I’m not sure I want to know what modifications you guys did that could have been better done by just getting an MK4.
I’m genuinely curious here. The MK4i is designed to have the motors inverted, for better protection. With a CIM, I can understand running non-inverted (though I do maintain that an MK4 would have been a better choice–cheaper, though not by much, too). But the NEO should be able to be installed correctly (inverted).
At the beginning of the season, we built the robot’s systems on a tank chassis. then (2 weeks before the competition) we decided to use swerve, but we could not put the system on the swerve chassis. we were crossing the chassis size limit. we cross mounted swerve modules. but when I did this, the Neo coincided with the profile. so we flipped.
Prototype Chassis;
Our team runs neos for turn and falcons for drive so we can get the extra speed and control that the falcons provide, and we have never had any issues with that combination.
One of our other head programmers put together a little tutorial series on how to code swerve from scratch. We also created SwoLib , a serve library with full custom odometry and dynamic autonomous pathing, if you don’t want to code everything from scratch. Feel free to reach out to me or anyone else from team 2875 if you have any issues with programming swerve.
Since the motor shafts are cantilevered in the assembly as designed, it seems like just flipping the motors over while using a pinion spacer of the correct length and 8mm push-on rings for retaining the pinion is all that would be needed. No real functional difference. The motors could be attached directly to the upper plate rather than using the long screws and spacers as-designed which is kind of a functional advantage. You, of course, lose the motor protection and add some obstacles to design around above the chassis, but if that’s not a showstopper, it looks like this would be an easy change.
If those motors got hit, there is a good chance of bending the upper plate, so this would not be a mod that just anyone should try, but in a pinch, there is some value.
.
