First of all, this thread is purposely designed as a branch of the massive traction control thread – not trying to duplicate threads, but just trying to narrow the scope of the discussion.
The traction control thread talked in detail of the different ways to measure and implement a traction control system. However, one detail I didn’t see mentioned was that all the theory was applicable to linear acceleration (or robots that had dedicated steering).
Most robots, I think, will be implementing tank or skid steering. The gotcha here is that by definition, you need wheel slip to turn – by it’s very nature, skid steering creates angular acceleration by sliding the wheels. Its been a few years since I took a physics class… does anyone know how to figure out the acceptable slip to achieve a certain angular acceleration?
A linear traction control system (“launch control”) is simple. How about one that performs well while turning for a tank-drive robot? Thoughts on different wheel configurations (4powered x 2motors, 4powered x 4motors, 2powered x 2motors)?
Assume no-slip condition, and calculate force vectors exerted by each wheel. Estimate robot-trailer CoM, and use vector arithmetic to calculate assumed torque around the CoM.
Using a gyro (needs to be right on the CoM?), calculate actual angular acceleration.
Compare actual angular acceleration to predicted angular acceleration (derived from torque in step 2) – this is your traction control system’s wheel-slip-error measurement. If actual A_angular < predicted A_angular, you’re slipping and you need to cut power.
Does this sound legit to you more mechanically-inclined people out there? It’s an approximation since we’re ignoring all the friction forces created by the the robot/trailer wheels sliding, but will it be close enough?
How about the process of combining linear traction control with angular traction control? Do people predict any weird dependencies, or can we just use good ol’ superposition?
Your thinking on that seems sound, but as you can’t “track” (no slippage condition) and turn, by definition, as you mentioned, I am not sure it will lead to a performance inprovement. Moreover, I think all traction control schemes will run into problems when pushing other robots or being pushed, and could have some unintended consequences. That is, turning and pushing could give incorrect results, decreasing performance. Perhaps a button on the control panel might be advised so the pilot can disable (toggle on/off) traction control for pushing and turning scenarios.
What exactly do you mean by this? I don’t quite understand. Can you elaborate?
And I completely agree with you regarding usage of traction control in a pushing match – a TCS would probably do the exact opposite of what you want. You definitely need an on/off switch.
Here’s my progress as of know, use to integration functions form the math pallet (f(x)) in labview, solve for velocity ( input divided by 9.8/32 deciding if you want to work in metric or standard), that gives velocity as far as i know were testing it this Saturday. The only issue is that integration functions send there last saved value first (therefore, the last velocity they output will be the first velocity you receive, shouldn’t be that bad).
But all that gives us is well, straight line, by comparing difference between y and z would give us the steering, i’ll work on it…
We are taking a much simpler approach to tank steering with traction control. We don’t care about lateral slipping, which is required, we are more concerned about linear slipping. we are using the KOP encoders on the gearbox, and a second encoder on each side near the center drive wheels. We will compare the values and try to keep the drive wheel speed at or below the encoder wheel speed.
On a side note, the drive team has asked that we include a bypass button so they can turn off traction control to allow them to “drift” in turns if they desire.
All this is theory, we don’t yet have all parts necessary to implement this for testing. Will let you know how it goes.
The whole idea behind anti-slip control is that the wheels have a higher coefficient of friction when they are not slipping (they are tracking true), so the robot can accelerate faster and push harder. Any slippage at all and the wheel force drops about 20%. As you will be slipping in turns, by definition with slip steering, you will lose traction anyway and there’s really nothing you can do about it. So anti-slip control makes sense only for straight line acceleration and straight ahead pushing.
I once looked into racecar launch control systems. The things I read said the fastest launch speeds are achieved by allowing about a 10% slip. Is there a basic-physics explanation for this, or is it due to the non-linear characteristics of rubber tires?
Second, say you mount one pair of wheels inline with the robot/trailer CoM so that the force produced is tangent to the path traced (well, assuming no linear net force). Do /those/ wheels slip in a skid-steering configuration (in the ideal case)? If not, would it be beneficial to have an angular TCS if you built your robot like this?
[edit] By CoM, I mean axis of rotation. If you put a pair of powered wheels in line with the axis of rotation, the path that they would trace would be a circle (with the wheel’s direction of movement tangent to said circle). Therefore, the ideal turn would be such that there was no slippage on these wheels, and you could theoretically program some kind of rotational traction control system. I don’t quite remember how to figure out the axis of rotation given a few force vectors on a rigid body, though. Also, this would only be the case if the wheels were in line with the axis of rotation… once you get off that axis, the wheels by definition need to slip, and you’re in the useless case which rwagner described…
i have thought about using the comparative math earlier that looks at the forward momentum and then based on the case, modifies the casestrucutre and ultimately modifies the scaler going to the system
Right off the bat we started with a ‘master’ disable switch on the driverstation and a momentary reset/disable button on the joystick, and thus far its been quite valuable in testing differences, as well as the fact that if something goes, say, kablooey [a strictly technical term], it can be both reset temporarily or shut off. using something like this could save your drivers in a dire situation.