View Single Post
  #2   Spotlight this post!  
Unread 31-10-2007, 22:25
Kevin Sevcik's Avatar
Kevin Sevcik Kevin Sevcik is online now
(Insert witty comment here)
FRC #0057 (The Leopards)
Team Role: Mentor
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Houston, Texas
Posts: 3,705
Kevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond repute
Send a message via AIM to Kevin Sevcik Send a message via Yahoo to Kevin Sevcik
Re: Contact Area and its Relation to Friction?

Quote:
Originally Posted by sumadin View Post
I also don't understand the idea of PID traction control. I've heard of PID velocity control using encoders, and I'm planning to implement that on our robot this year, but I don't understand the idea of PID traction control. How would you do that?
PID traction control is pretty simple, just not anything that's typically done in FIRST. The whole point is to keep your wheels from slipping. Wheels slip when applied force exceeds the static friction force. Applied force is proportional to applied torque which is (mostly) proportional to motor torque which is proportional to motor current. So your goal would be to PID control the current being supplied to (or sourced from) the motors. Current-mode motor drivers and amplifiers are awesome for this, but we don't have any, sooo the idea would be to use a solid state current sensor on your motor leads, and PID control this.

Now, I'm not sure our available loop rates are really adequate for good stable control of this current, but you could certainly easily implement a simple controller to back-off on commanded PWM signals to keep the current in an acceptable bound that you know won't slip.

Quote:
Originally Posted by techtiger1 View Post
The easiest way too figure this out is to put the bot pushing against the wall and record the numbers from dashboard when the wheels slip then set them up in programming as limits.
The above means I'm slightly skeptical about programming hard limits into your code based on what PWM values caused slipping at a stand still against a wall. The PWM values control (to a 1st order approximation) the voltage that you're applying to the motor, not the current. As a motor spins, it creates its own source of voltage (back EMF) proportional to the motor speed that cancels most of this out, with the left over voltage differential driving the current flow and thus creating torque. What this boils down to is that, if your robot is moving forward while you're commanding a constant voltage, you're theoretically applying less torque than you could get away with. Annoying, but not really a problem. However, if you're applying your constant voltage and still getting pushed backwards without slipping, this actually increases the torque you're putting out. Which means that if someone pushes you back fast enough (and it doesn't have to be a lot if you're cutting things close) you'll suddenly put out too much torque, spin your wheels, and very rapidly lose the pushing match. Plus, you'd be pointlessly limiting your top speed when you're not pushing someone, because you've simply put in a limit to how much voltage you'll put out and, thus, what your top speed is. Now, there are ways to compensate for this using velocity feedback and such, but they're not going to be as accurate and reliable as a current sensor feedback.
__________________
The difficult we do today; the impossible we do tomorrow. Miracles by appointment only.

Lone Star Regional Troubleshooter