thank u 
You should look at many of the COTS swerve modules (lots of discussions in CD on COTS swerve options) to find a range of these ratios that have proven to be good choices.
The very popular modules from Swerve Drive Specialties use between 8:1 and 6:1 for drive and 4:1 for steer. The wheel diameter is an important factor in selecting a good drive ratio.
Edit: as several have mentioned, the steering ratio on the newer SDS modules is 12.8:1 (60:10 on the belt and 32:15 on the gear). Sorry for the error.
1 Like
From SDS site, MK4 steering ratio is 12.8:1.
MK4 Swerve Module – Swerve Drive Specialties.
1 Like
4:1 for steering? Maybe you meant 14?
4 is way too high.
In the spirit of mentoring (i.e. teaching how to solve the problem), here are the factors to consider.
Drive: Generally, drive speeds are set based on trying to achieve a certain on-field performance for the robot. There is a trade-off between acceleration and top end speed (higher gear ratios give you more acceleration but lower top end speed and vice versa). Since many FRC games involve a relatively short “sprint” to grab a game piece or move to a scoring area, teams generally lean a bit more toward the acceleration side of this trade-off. However, with modern brushless (i.e. Falcon) motors, you very quickly run into traction limitations (your wheels loose traction with the carpet and just spin). Depending on your wheels and wheel size, this limit will be somewhere around 6:1 ratio. As it turns out, this also results in a top speed that is pretty fast. Going much faster is generally going to push the limits of the drivers in terms of robot controllability. So, in this day and age, there is a fairly narrow “sweet spot” of drive speed / ratio. Using a driveline simulator (there are several that are available) will let you see the effect of different gear ratios on time to target for different sprint distances and show you when you have hit either a current limit or a traction limit with your drivetrain.
Steering: Steering speed is also a tradeoff between responsiveness and controllability. There is a 3rd factor which is reacting the drive motor torque that probably only comes into play if you are using some of the smaller motors like the NEO 550 for steering control. A few years back the “free speed” for the steering motor (the speed at which the module would theoretically spin based on the free speed of the motor and the gear ratio) was in 150-200 RPM range. This limit was set based on the stability of PID control. If you are using an absolute controller for steering control, this is probably a good number to shoot for. However, if you are using the internal motor encoder for the input into your control loop, it removes the deadband associated with the backlash in the geartrain between the motor and the encoder from the control equation and it is possible to develop stable PID control at much higher rotational speeds. Many teams are using 350-500 RPM for their steering speed. As a cross-check, A Falcon motor (6380 RPM free speed) with the SDS MK4 steering ratio of 12.8:1 gives you a steering free speed of 498 RPM.
4 Likes
This is very interesting. Forgive my ignorance on this (I am not a programmer and know little about practical aspects of PID control). I thought the SDS MK4 used a CANcoder for azimuth control. Are you saying that you use the CANcoder for azimuth control but use the integrated Falcon motor encoder for PID control of the azimuth angle?
I am not a programmer either and I cannot speak for the SDS code.
On our code, we use the absolute encoder only to read the initial position of the module. Once we get that value, all the control is done using the built in encoders in the motor running a PID control in the motor controller itself (not in the main code running in the RIO).
In the past, we have used the absolute encoder for control. We were able to tune a stable PID loop using the absolute controller, but we needed to run slower steering speeds to do so (they seemed fast at the time and were in line with what other teams were using as their speeds). Part of the problem is that the backlash in the gears will cause a deadband between the rotation of the motor and the rotation of the module. If you started with the gears fully contacting for CW rotation of the module, you could spin the motor shaft in in the CCW direction quite a lot of degrees before all the gears were in contact in that direction. This deadband results in a lot of “twitchy” behavior where the motor will really get going in one direction before there is any response of the module in that direction and then you will get overshoot and it will reverse directions and get going in the other direction before getting a response.
The other thing that affected how fast modules could spin using absolute encoder control is the difference in the loop time between the main code on the RIO and the local code on the motor controller. The motor controller is running a faster loop which helps the stability of the PID and allows you to run a faster speed.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.