View Single Post
  #13   Spotlight this post!  
Unread 07-01-2009, 18:05
MikeE's Avatar
MikeE MikeE is offline
Wrecking nice beaches since 1990
no team (Volunteer)
Team Role: Engineer
 
Join Date: Nov 2008
Rookie Year: 2008
Location: New England -> Alaska
Posts: 381
MikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond repute
Re: Implementing Traction Control for an advantage in the 2009 game

Quote:
Originally Posted by Abwehr View Post
I think you meant first derivative of wheel velocity (or second derivative of wheel position). This is your acceleration.

Here's the rub - encoders are digital sensors, with limited resolution. The "derivative" operator is continuous. You can approximate the derivative with the "difference" (i.e. accel = speed - last_speed), but this is only ever an approximation.

Luckily, the straight difference isn't the only way to approximate the derivative. For example:

accel = -last_last_speed + 2*last_speed - speed;

This is a smoother derivative approximation, but it is now time-delayed (since it is centered around the time of last_speed). This is the tradeoff of filtering - with smoothness comes time delay.
No, I actually did meant the second derivative, or more precisely the change in the first derivative, i.e. looking for a sudden increase in acceleration as an indication of slippage.

I haven't thought through the resolution necessary to get reliable performance, but I am certain that processing power won't be the limiting factor.

And I agree with Eric's comments about Labview. I've spent too much of my working life re-implementing signal processing code to want to do it unnecessarily.