We got our first ever mk4i modules last week and are going to start building in a week. Some other teams warned us about not damaging NEO’s as they did. We have no back up material so what could be your safety tips. Such as setting a voltage compensation and current limit etc.
Thanks in advance!
Initially get swerve working with something raising the wheels off the carpet cause you can cause a decent amount of damage by accidently spinning the drive modules really fast against each other or the steer motors really fast in circles
1 Pro Tip for “do no harm”: SET your current limit to something in the 20 to 40 Amp range. Seriously! Don’t use the default!!! Just do it, you won’t regret it… 20 Amps is plenty for steering. 20 Amps is plenty to start driving too. 40 Amps is likely a good driving current limit!
After you start driving, THEN you can do some testing and find out what current is required to break your tires loose and set your limit just under that.
+1 on the test on blocks too!
Use a template or library, set limits LOWWW current limits AND artificial maximum speed with desaturateWheelSpeed https://github.com/BroncBotz3481/YAGSL-Example/blob/main/src/main/java/swervelib/SwerveDrive.java#L473-L476
Don’t let PID loops wildly oscillate, slamming back and forth. Just plain not good. Especially when up on blocks and there is no resistance.
I assume you mean supply current limit. Stator current limits should be pretty aggressive. Setting a stator current limit of 20a will probably result in the robot not moving in a fair amount of scenarios.
I’m referring to the current limits set in the motor driver. IE the SparkMax current limit. Honestly, its never really clear WHAT that limit sets, but 40 Amps was all our battery could support on four wheels, and that was close to our wheel slip threshold too.
20 Amps current limit on a SparkMax/NEO should make your robot drive… IF the wheels are all pointed the same way and driving the same way. Which, of course, ALWAYS happens 
20A on steering is what was suggested
Testing your code in simulation and unit tests are another way to validate that your code doesn’t do anything unexpected.
I do admit that this is a bit over the top but using simulation we were able to get our robot moving around virtually before we tested anything on a real robot, so that gave our mechanical team a sigh of relief that the code had been through at least one environment before potentially harming motors.
Please, if you’re testing on blocks, do not overlook this. Disable (or substantially weaken) your feedback when the system is unloaded.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
