Trouble-shooting Low Traction

[RyanCahoon]

A couple of things come to mind:

- If the loading cord is above the ground (it's hard to tell from the video), there's a torque moment rocking the robot onto its back wheels. If the wheel that's slipping is in the front, that may be part of the reason why.

- (This may apply more later than now) Be careful you aren't applying too much power to the wheels. If the motor command is a step from 0 to 100%, there could be enough torque for the wheels to start slipping (regardless of the loading - simply because the rotational inertia of the wheel is probably less than the inertia of the entire robot), and then you're into dynamic friction which is (theoretically) less than the full static friction coefficient. Try ramping from 0 to 100% over a couple seconds.

- Have you tried an inclined plane test to determine coefficient of friction?

[cbale2000]

Originally Posted by RyanCahoon

A couple of things come to mind:

- If the loading cord is above the ground (it's hard to tell from the video), there's a torque moment rocking the robot onto its back wheels. If the wheel that's slipping is in the front, that may be part of the reason why.

I was going to suggest this also. Try connecting the cord in such a way as to have it running at the same level vertically as the center of the wheels. The main downside to 4wd aside from turning is that it's very sensitive to weight and force distribution when attempting to maintain traction.

[alecmuller]

Excellent suggestion!

I forgot to account for the weight transfer due to the cord being 5.5" off the ground. When I did a free body diagram, I found that just over 2/3 of the weight is resting on the rear wheels in that configuration.



I rigged up an extension to lower the cord to about 3/4" off the ground and re-ran the test. It still barely lifts the 3 pavers, but this time 3 out of 4 wheels spin (the left front wheel does not spin in any of the tests - I suspect I have a lot of internal friction losses in that one).



I still need to re-write the code to ramp up the torque instead of going full-bore from the start of the test.

[alecmuller]

p.s. I have not tried an inclined plane test for traction yet.

Edit: For a moment I thought I'd found the problem in my calculations, but it turns out I still have a calculated torque that's far higher than tests are showing.

The CORRECT formula for total robot traction should have been:

Traction = [# of wheels] x [CIM Torque] x [Gear Reduction Ratio] x [Gearing Efficiency] / [Wheel Radius]

For my setup, the numbers were 4 wheels, 4.84 in*lbs CIM torque (assuming 30A limit and linear torque vs. current), 23.18:1 gear ratio, 80% assumed efficiency, and 2" wheel radius. I made the mistake of forgetting to include the 4 wheels AND multiplying by the 2" radius instead of dividing by it (i.e. my mistakes canceled each other out).

4 x [4.84 in*lbs] x 23.18 x 0.80 / [2 in] = 179.6 lbs.

So I need to fix what might be causing torque loss in that one wheel, and I need to write power-ramping code.

Thank you all for the help!
Sincerely,
Alec

[philso]

Are all 4 wheels bearing the same weight? How stiff or flexible is your chassis?

[Electronica1]

You "might" be able to get away with lowering the pressure on your suspension to keep all 4 wheels on the ground.

[Chris is me]

How many points define a plane? If your frame is too rigid and not perfectly square, this could be a big part of your problem.

[KrazyCarl92]

Another way that weight distribution issues can be mitigated in a tank drive (at least front to back) is by chaining, belting, or gearing the rotation of the wheels together. It appears that this is not the case in your setup. Coupling together the rotation of the wheels by some method that can transmit the torque makes it so that in order to lose traction on one side of your drive train, the total output from the motors/gearbox(es) on that side has to overcome the total tractive force of all the wheels on that side. This is instead of it being on a wheel by wheel basis.

This may help because once you have 1 wheel slipping, it kind of screws up the rest of the experimental set up. Let's suppose the weight of the robot is 100 lbs, that your wheels have a static CoF of 1 and a dynamic CoF of 0.5, and that your wheels are not chained together. If your front wheels are supporting 20 lbs each and your back wheels 30 lbs each, then your front wheels will begin to slip early on and go from 20 lbs of tractive force down to 10 lbs of tractive force. Then since those are already slipping, your back wheels will both have 30 lbs of tractive force just before they start to slip, but that will only give you a total of 80 lbs of tractive force. If you were to chain your wheels together in this example, you would get 100 lbs of tractive force.

This wouldn't solve weight distribution issues side to side, but it is a very easy and simple way to solve the problem front to back.

[alecmuller]

Thank you for the ideas. That 3/4" plywood is essentially the whole chassis (all 4 drive pods are screwed to it), so it's pretty stiff relative to the weight of the robot. I don't have a whole lot of margin on the pneumatics (which deploy the traction wheels), so I don't think I'd be able to get away with reducing the pressure very much. I believe all 4 wheels are carrying pretty close to the same weight (due to symmetry), but I don't have 4 identical scales to verify that with.

Coupling the front & rear wheels tank-style sounds like a great solution for most 4 & 6 wheel robots; unfortunately it defeats (or complicates the heck out of) the mecanum part of the Octocanum in my case.

At the moment I'm still trying to debug the power-ramping code (to avoid going straight to full power and slipping the wheels). My first attempt (based on the arduino clock time) didn't move at all. I need to find an easy-to-use clock function in Arduino . . .