Quote:
|
Originally Posted by SlimBoJones
Looking for some advice.
This may not be so applicable to FIRST since most robots are a little "underpowered," and have their weight bias and drivetrain layouts set-up to prevent wheel-spin.
but,
Would the current sensors be a good indicator for loss of traction? I have heard that the outputs are a little bit noisy, and noticed in the default IR navigation code, an average of the last 10 readings as actually being used to resolve the current current. Is this still fast enough? Would a simple RC circuit smooth things out?
If they are a good indicator of wheel-spin, how do most traction control algorithms react when wheel spin is detected? Would you drop your motor output by a fixed value? to a fixed value? by a fixed percentage? kill the output all together for one cycle?
Then, there's detecting wheelspin in the first place. You could create a look-up table of expected current values for a motor speed, and if it's significantly lower, then, you've got wheelspin.
I'm sure someone has, or is thinking this through too. Post your ideas!
|
This is kind of a lengthy answer, but here it goes...
First, I think it would be beneficial to describe how an automobile typically performs traction control (of course, this is going to be different depending on the system supplier, but here is one generic method that is used):
The first thing you need is the inputs to the algorithm. For automotive traction control this is typically wheel speed (to infer vehicle speed based on wheel angular speed) and an inertially calculated vehicle speed (i.e. integral of acceleration measured with an accelerometer).
The algorithm can then compare the two vehicle speed calculations. If the wheel speed is higher than the inertial speed, you know the wheels are spinning. You can then adjust the motor torque output until the two calculated speeds match.
At first glance, a simple linear (PID or compensator) algorithm appears to fit the job. However, this type of algorithm is typically too slow to do the job well. Instead, a rule-based algorithm is usually used. In other words, the algorithm compares the two calculated speeds to some look-up table, performs some if-then-else logic, and then adjusts the desired motor output based upon the lookup table and the logic. The basis of the tables and logic are usually created by a lot of testing and trial-and-error. Therefore, to answer your questions on what to do, I guess the answer is "everything you mentioned". In other words, you'll probably need to do a lot of trial and error to determine your own set of rules.
Now, back to the robot.
The current that a motor draws is directly proportional to the torque it is producing. Therefore, the current sensors are basically torque sensors. For traction control, you would ideally want to sense the velocity of your wheels. You may be able to estimate velocity given the torque (i.e. current) and the commanded PWM. I don't know if this is feasible or not since I've never deeply studied the problem. The look-up table that you mentioned would do this.
The one thing to keep in mind is that the current draw will also vary somewhat due to the temperature of the motors, and maybe some other outside factors. Therefore, even if you can estimate the velocity given the torque and your commanded PWM, the accuracy may not be good enough for traction control. In order to make this work, you're probably going to have to put a lot of work and research into your solution.
Even if you can accurately determine the wheel speed, you will most likely need another source to determine the robot speed so you can make the comparison. The reason is because your algorithm will not know if the wheels have their current speed because the wheels are slipping or because the robot is moving.
Whatever you end up doing, good luck with it. If you do get it to work, let us all know how it turns out.
-Chris