View Single Post
  #2   Spotlight this post!  
Unread 22-01-2009, 12:50
Jared Russell's Avatar
Jared Russell Jared Russell is offline
Taking a year (mostly) off
FRC #0254 (The Cheesy Poofs), FRC #0341 (Miss Daisy)
Team Role: Engineer
 
Join Date: Nov 2002
Rookie Year: 2001
Location: San Francisco, CA
Posts: 3,078
Jared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond repute
Re: Accelerometer success?

Quote:
Originally Posted by Bongle View Post
One big issue is your on-carpet acceleration: On a carpet, your robot's potential acceleration will be higher than on regolith. So if you artificially cap wheel acceleration to your on-regolith acceleration, you're hurting your peak performance.

Another issue is your ability to push trailers or pull a loaded-up trailer: Your in-code maximum acceleration will be higher than what your robot can physically achieve, and so your wheels will be able to speed up and start spinning despite the code being there.

However, these arguments from me are mostly based on our system's theoretical performance. It may turn out to be not reliable enough for a full-time implementation, at which point a static setup makes sense.
Well put.

In short, static acceleration limiting will prevent slip as long as (1) no external forces are manifest and (2) you know your CoF with high confidence. Once these assumptions are broken, however, you can lose traction and - with the static approach - you will have no automatic way to detect that this has occurred and, by extension, will have no automatic way to regain traction.