Do any teams have open code for Swerve Drive using a Falcon500 for the drive motor and a NEO for the steering motor?
I highly doubt any team has this and/or has it public but it shouldn’t be too hard to make. I recommend looking at two libraries that use each of them separately and working on merging them. How much experience does your team have in programming?
1 Like
A good amount but first year working with NEOs due to all the stuff going on with Falcons
1 Like
Sounds good, what Falcon library did you use for swerve last year? (if you did swerve that is)
also the first year doing swerve
I’d recommend going with just Falcons or just NEOs. Mixing two motors, two motor controllers, and two* programming APIs seems like a whole big integration mess. Going with just one makes wiring and programming simpler (and I am a big proponent of KISS). It also may make it easier to swap modules if stuff breaks.
Also, it’s likely that the power difference between a Falcon and a NEO is not going to be the limiting factor in your robot’s performance—a swerve with weaker motors driven well is way better than a swerve with stronger motors driven suboptimally.
2 Likes
If you do wish to mix Falcons and NEOs on a single swerve module, you may want to consider using Falcons for steer and NEOs for drive. The drive motor really just needs a percent output, while the steering motor needs a tight PID loop to operate at all, and given you’ve said that this is the first year your team has worked with NEOs running a precise PID loop on NEOs may be out of reach.
2 Likes
It shouldn’t be hard to modify the BaseFalconSwerve example code to use a neo instead of a falcon for either motor. The hardest part will be getting the PID loop correct, as the neo uses different units from the falcon. I agree that the falcon might be easier to use on the angle shaft the first time, but it’s up to you in the end.
You’ll be looking for anything that touches the angle motor in SwerveModule.java.
Team 340 has swerve code using 2 falcons, but shouldn’t be THAT hard to swap in a NEO for one. https://github.com/Greater-Rochester-Robotics/RapidReact2022-340/blob/main/src/main/java/frc/robot/subsystems/swervelib/SwerveModule.java
Absolutely. This is most definitely the play. Most Falcon implementations only run percent outputs, so switching to SparkMAX only takes a few minor code changes.
If you want to try to modify our swerve code, you can find it here.
It assumes two falcons in each module, but you can change it to one falcon and one NEO in the SwerveCombo class.
Second using a NEO for drive by the way. Making a PID loop on a Falcon is way easier.
This code uses a bunch of unit conversions to get to a velocity control mode on the drive. Going to percent output means you would need to bypass it. I think you could set driveConstant to 1 and have it work, but I would need to check.
We set our absolute encoder offsets in Phoenix Tuner instead of in the code. Not a great practice, but it gets the job done.
We haven’t used this code in a while. If you have any questions about it, feel free to ask.
Can you expand on why a tight position loop is hard on a NEO? There’s been lots of discussion on the velocity filter making tuning velocity PID hard, but that isn’t applicable. For example, from Thoughts on NEOs and Spark Max - #61 by Oblarg
Just because OP said that this was their first year using NEOs, that’s really it. Also I have heard the CTRE API is a bit easier to work with, but I don’t have almost any first hand experience with it so I can’t really say.
The Phoenix API (like Ian said) is much better and easier to work with, and in general, doing PID with Phoenix is a lot easier and more consistent, reliable, and documented.
Also, the NEOs have a much lower encoder resolution (42 vs. 2048 for Falcons) that makes precise position PID less reliable.
If you use external encoder for module position (like mk2s for example) you can do the PIDcontroller for position using the WPILIB implementation and you don’t have to use the sparkMax PID controller. That’s what we did this year with NEOs on mk2 and it worked just fine.
If you wanna use the internal encoder you will have somewhat reduced resolution vs say a falcon, but even at gearing as low as 12.8:1 (std mk3 and Mk4) that’s still a tick every 0.67deg of module which isn’t terrible. I’d recommend going external or having a larger gear reduction for steering for best accuracy though if you can.
Edit: now that I think about it a little bit more without field oriented control I think because the motors are 14 pole designs the motor is most likely going to want to sit with the rotor aligned to the stator, so might not get as much precision unless you use larger reduction, maybe why mk4i went to a larger steering ratio as well
1 Like
Swerve Drive Specialties has a template code that has an option for falcon drive, neo steer. Here
Might be worth looking into
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.