To win a pushing match is a combined effort of Mechanical, Electrical and Software design. This article will cover an overview of how each of these engineering disciplines contribute as well as to provide some testing tips and tools to help assist in the design for each.
In the study of dynamic physics we learn about force (mass times acceleration) and cover friction. In statics, this is analysis when no motion is involved and we get more in-depth into the components of friction as we learn about the mechanics of materials. That is, the analysis of behavior for internal forces happening within any material entity in terms of stress and strain applied to them or their interaction with other materials (e.g. equilibrium equations). For a pushing match from a static perspective there are 2 factors that can determine the outcome:
The weight ([mg] mass x gravity) is a given where we make the robot as heavy as possible, and the coefficient of friction (CoF) is a coefficient ratio of how much force of friction (Fr) can be yielded from the Normal force and Gravity of the surfaces being pressed together. The take away from this is that when we go to pick our wheels, somewhere in the specs will list the rated coefficient of friction usually a 1.0 is very good (I've seen some rated higher like 1.1 or 1.2). However, sometimes these ratings do not match their actual performance in which case we can put the robot on a official match carpeted board and start to tilt the robot (A trick I've learned from JVN). Lock the wheels so it will not roll and then measure the angle just before the robot slides down. From this we can find the actual CoF. When we talk about CoF it is implied meaning static friction, and not kinetic unless we explicitly say so. Kinetic friction occurs when skidding happens, and is drastically reduced.
One important point which is a common misconception is how traction relates to how much surface area is in contact with the ground, I use to fall victim to this, for example, there is more surface area contact of 8 wheel drive versus 4. While this is true, it does not give the 8 wheel drive more traction. The reason is because the more weight that gets distributed, the less downward force can be applied for any given area of the materials in contact. There is something to be said about how the materials mesh together to affect the CoF, but this is insignificant in regards to the number of wheels and the contact materials defined. That said, the less contact surface used for the same amount of weight to distribute, the more stress can be applied to any given area. For the carpet, it is conceivable for the wheels to sink in a bit deeper with more of a "pierce". When this happens, it is like wearing cleats on a soccer field, more traction. To get an idea of the significance of this can be tested (somewhat) using the tilting technique mentioned above. Note: this piercing concept is one possible explanation of how CoF ratings can be higher than 1.0
The thing with kinetic friction (i.e. skidding) is that we might as well concede if this happens against a robot that does not have it. There are steps that can be taken to avoid skidding mostly from a programming perspective, which I will cover later, but for now I should point out that tank drive uses skid steering. So if a tank drive does any turning during a pushing match, it will have some material subjected to kinetic friction, where the swerve kinetic friction is minimized because the wheel angles align to the direction of travel at all times during any turning moments. As a rule of thumb the CoF during kinetic is usually around 1/2 of it's static cousin, and in some cases worse.
One important need from a dynamic perspective is to obtain the highest acceleration possible as needed. Just moments before contact in a push if we can take a snap shot of the motion. The robots most likely will come into contact at different momentums. Force = mass x acceleration where acceleration is the rate of change in the velocity, and momentum is the value of kinetic energy available defined as mass x velocity. So when two equal mass entities collide, whichever has the highest stored momentum will have the slight advantage, especially if the resolve causes a skid. Honestly though in the spirit of the game, it is best not to collide at high speeds to avoid damage, but this principle certainly can be useful and apply to slower speeds and shorter distances where a higher momentum can give an advantage, especially on partial contact cases. Acceleration of course benefits maneuverability which is one alternative strategy to a pushing match that can accomplish the same goal.
The last mechanical requirement is to ensure the gearing ratio is high enough for a robot to pull its own weight, and then even a little more to avoid stall torque at full voltage. We cannot push more than our own weight, because we would then start to skid, so if we get into a dead heat between an equal foe, stall torque on a motor at lower voltage is less heat and less current draw.
When using the JVN spread sheet, we need to pay close attention to the total current draw, and this has been something that has been neglected in past seasons with drastic consequences. If during a pushing match we draw too much current, either the breakers will trip and a particular motor shuts down, or worse, we may have a brownout and the entire robot stops working while the system reboots for the remainder of a match (e.g. those matches where sometimes the robot mysteriously works again during the end game). Let's assume the software will avoid brown outs, in which case for too much current draw, we would have to back down the desired voltage and lose the pushing force to compensate. The battery has a max limit rate of amps it can expend at any time, and there is a smaller limit on individual breakers for each motor. Excessive current draw can be mitigated/managed by a mechanical advantage of efficiently balanced gearing, where the tradeoff is top speed vs. torque.
If the gearing reduction is set too low, while it gains top speeds, it also causes pushing forces to delegate too much stress on the motors which results in pulling more current draw to do the same amount of work than otherwise. If the gear reduction is too high, the top speed may be too slow. To have the best of both worlds, we have used a gear shifting mechanism in the past, but as I wrote in a previous article the top speed gain given the amount of field to travel at one time is not significant, and so I tend to lean towards mechanical simplicity. Written there it shows that ideal top speeds are anywhere from 10-14 fps where the cycle time differences are negligible for games that have average field travel requirements. Aside from gearing, motor selection is absolutely vital in the current draw budget. We can look at the final numbers and have the same pushing force numbers among various motors, but different motors will yield better current draw for the same amount of work than others. This makes it necessary to invest in good quality motors for best chance of success. The JVN Calculator makes it easy to factor in the gearing and compare the current draw numbers, just plug in the motor curve data, and then gear it down to have a satisfactory pushing force for each motor of interest.
For now I'm going to skip explaining the details of the current draw, but I will give a quick overview. The motor curves offer specs for both stall torque and stall current. When entering the stall current, the total current draw is shown and per motor. Ideally, if we use a 40 amp breaker try to keep it under a 40 amp draw. It may go a few amps above, and the way teams describe this should be fine because we can go a limited amount of time in stall current before it would trip. However, the total draw also needs to be considered, as well as the total amount of motors being used at one time, which can be managed in software.
Since this article is more for mechanical design, I'll keep the software explanation to a minimum and expand more on it elsewhere. Software must manage for brown out prevention, and can monitor the voltage drop to help with this. Hopefully it will never happen especially if the design has a good current draw budget on motors. Software can do things to help actively manage this as well. (e.g. slow down the drive or stop when a heavy resource manipulator is used like a shooter, or ensure a sequence of manipulator motors does not overlap.)
As mentioned above we need to avoid any skidding opportunities, if the robot wheel torque is optimal it should be strong enough to skid aka peel out (not that we want to do this). While it is possible for a driver to practice accelerating to avoid skidding, there is no guarantee they are just below the threshold at all times. With motion profiling the driver can high-stick it and the robot can be tuned to the ideal acceleration rate just below the skid. Using encoders can ensure the wheels never skid because if they start to skid the PID will back off the voltage within any given 10 millisecond slice of time, this is similar to antilock brake technology used in a car.
This last point is something I have learned from Team 33's leader Jim Zondag. Driving with encoders (along with other localization odometry) ensures success of not skidding and can respond quicker to this than a driver for 2 reasons. First because on average a person takes about 200 ms (milliseconds) to respond, and second because the driver relies on vision and this can be extremely difficult to gauge especially from the other side of the field. Also if a pushing match happens where the front of the robots are not perfectly aligned, the ideal amount of voltage needed will be more on the contact side and less on the non-contact side to avoid a spin. The driver with tank steering may be able to react to this, but a swerve driver does not need to worry... they simply move forward and the PID will compensate and also avoid any potential skids as well; Moreover, the reaction to this will be quicker with more precision accuracy of voltage distribution. So then during that split second, if there is any moment of skidding or lower-voltage-to-compensate from the other team's robot, they will simply rotate out of the way.