View Single Post
  #8   Spotlight this post!  
Unread 08-02-2006, 09:10
kaszeta's Avatar
kaszeta kaszeta is offline
Registered User
FRC #0095 (Grasshoppers)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2002
Location: Lebanon, NH
Posts: 334
kaszeta is a glorious beacon of lightkaszeta is a glorious beacon of lightkaszeta is a glorious beacon of lightkaszeta is a glorious beacon of lightkaszeta is a glorious beacon of light
Re: Robot doesn't drive straight

Quote:
Originally Posted by Donut
We've run into a similar problem; when runnning forward, the left side of our robot started before the right side, and we believe attained a higher speed. The same problem occurred in reverse, only with the sides switched. I'm thinking their is either a problem with the victors' calibration or that the CIMs have some kind of motor bias (this could have to do with the fact that motors on opposite sides spin opposite directions to drive the robot the same direction).
Bingo, this is probably a combination of motor bias combined with differences in each CIM motor. Are you sure about the 40%?

There are a couple of ways team 95 has handled motor bias like this in the past:

1. Calibration. If you have shaft encoders on each CIM or transmission, you can make a correction map that maps a "desired" pwm value to an actual one. You can also linearize the motor response like this.

2. Rotation feedback. You have a gyro, consider using it to stabilize undesired yaw with a feedback loop. I can probably give you some sample code if you have the gyro working already. I've seen this work well for bots that *really* can't drive straight without it (including a bot with a noticeably assymetric drivetrain last year, I don't recall the team number). You can also do PID rotation rate control on the motors, too, but this is more tuning.

3. Adhoc correction factors. Basically, trim your joystick so that the undesired yaw is offset.

4. Driver training.

From our team's experience, #2 is the easiest and most reliable way to go (although #1 and #2 in combination works better). I don't recommend #3 or #4.

Plus, whatever you can do mechanically to fix it makes the programming simpler. Programming can correct a lot of mechanical ills, but you're generally better off if you fix the mechanical problems mechanically.

Last edited by kaszeta : 08-02-2006 at 09:22. Reason: more in feedback