In comparison to Holonomic or Swerve drive, Mecanum is quite simple. All you need is four independently driven Mecanum wheels. These can be bought or built. I bought mine from AndyMark (www.andymark.biz), but that doesn't mean you should.
Mecanum is a certain amount heavier than a comparable tank drive system. One probably uses the same number of motors, but two more transmissions (one per wheel total), and the wheels themselves are heavier than usual. My skateboard*, with 4 AndyMark Super Shifters, 4 small CIM motors, a 2005 electronics board, and an aluminum frame, weighs around 70 lbs.
One challenge I did not work on was how to ensure that all four wheels stay in consistent contact with the floor. Usually, the issue comes when the robot runs over an object. A bolt likely wouldn't be an issue, but a small poof ball might be. Sitting the chassis low enough to the ground that such objects get pushed would work. The other option is to include suspension of some sort. Standard bumpers, if placed well, can substitute as the former of those. I do not know how to use suspension in a robot. I personally would recommend considering Swerve drive if active suspension is a likely option (student project opportunity!).
Speed is also supposedly a concern. My mecanum bot is not really a fair case either way; the sprockets from the transmission to the wheel are by far not designed for speed. Changing some things in the transmission and/or the sprockets would help significantly.
In short, there's not too many problems with mecanum drive from a mechanical standpoint. The wheel type and wheel independence are what determine a mecanum bot. The software makes up for the mechanical simplicity, though. The software will be covered in a future post.
*Skateboard in this case is either a technical term or language abuse
Thursday, February 21, 2008
Tuesday, February 19, 2008
What Still Needs To Be Done
These range from the necessary to the wishful thinking. All are tasks that could be done with some reason for doing so, but aren't yet.
- Motor Balancing: When all of the motors spin at a slightly different speed for any one given signal, your bot quickly becomes rather uncontrollable. So, we're using the encoders built into the transmission to try to correct that. Once the motors react predictably, the bot should be more controllable, or at least there should be fewer variables to work with.
- Sideways-to-Forward Speed Balancing: The bot moving forward better than it does sideways seems like an issue to me. If the motor balancing doesn't take care of this, I'll see where exactly the problem lies, and how to fix it. Once fixed, the bot should respond more consistently.
- Drift Removal: If neither of the previous two take care of this, then I need to trace through the code and find where the drift comes from. Removing the drift will make the bot more controllable and therefore maneuverable.
- Clean up the code: The code right now is quite hackish, and needs a lot of cleaning up and converting before I'm satisfied with it. I expect to release it as a library when I'm done, so that the team doesn't have to re-write it each year.
- Increase Maximum Speed: I personally doubt I need to do this before I leave for college, but it would be good to know how speeds map on the mecanum wheels with what RPMs. The fact that you have rollers taking your energy does decrease your speed, but how much? What gear ratio do you need to make up for that loss?
- Pushing Power: Do the rollers change the pushing power of the robot? If so, by how much? Mecanum bots obviously aren't going to win matches, but just how much can they push?
- Add PID Loops: If I convert the code to work with speeds, rather than PWM values, I'll need to add PID loops to make sure the motors are actually being driven at that speed. The changes shouldn't appear on the surface, but would likely make autonomous easier, because the drive code is now working with sane units.
- Self-calibration Mode: This would be a special run that records how fast each motor can go at various speeds, and in all gears, and uses that information to set constants for the drive code, and write those constants to EEPROM. This mode would have to be run at least once, and another time if the motors, transmissions, or controller is changed significantly. Specifically, you wouldn't need to run this mode again if you swapped a motor with a spare, but if the motors had different bias, you would. The advantage here is more reliable calibration, probably faster calibration, and certainly easier calibration of some very complex things.
The Project
My project for the 2008 FIRST Robotics Competition season: Build and program a skateboard that runs Mecanum drive. I was given a budget, and I imposed deadlines. Some tasks are much harder than they seem.
For those that don't know, Mecanum drive is a drive system that relies on a specific type of wheel to move in all directions. Forward, backward, left, right, a combination thereof. When programmed correctly, Mecanum can even "frisbee", or turn while driving in a particular direction.
With this maneuverability comes a new way to move a robot: field-oriented drive. Field-oriented drive means no matter which way the bot is facing, pushing forward on the joystick makes the bot move up the field, and pushing left on the joystick always makes the bot move to your left across the field. Compare this to robot-centric drive, the traditional control system. Push up on the joystick, the bot will move in the direction it considers forward. If the bot is turned to the left 90 degrees, and told to go forward, it will move left across the field, because the robot's forward is pointing to the field's left.
For those that don't quite understand field-oriented vs. robot-centric drive, I'll see if I can get a better explanation up in a while. Until then, just trust me that it's a good thing to have.
I had it driving as of last week Saturday. Forward, backward, strafing, and turning worked. Frisbeeing came along Sunday, if I recall correctly. It has some drift depending on the exact maneuver, and it doesn't drive as fast sideways as forward. I'm tracing most of this back to the motors, but my parents think it won't drive as fast sideways because of the nature of Mecanum. Could be, but I don't see how the physics works out for that.
I had 1.875 people working on it at once. These might have been mentors, fellow team members, mentors from other teams, ex-mentors, pretty much anyone I could justify borrowing. There is no way I could have gotten this far as fast as I did without them.
This post probably leaves a lot of unanswered questions. Some I will answer in future posts (I know there will probably be at least one more post today), others I will need comments asking them before I answer them. So, if you have a question, hold on to it for a while, and see what else I post. If I don't answer it in a couple of days, post a comment.
For those that don't know, Mecanum drive is a drive system that relies on a specific type of wheel to move in all directions. Forward, backward, left, right, a combination thereof. When programmed correctly, Mecanum can even "frisbee", or turn while driving in a particular direction.
With this maneuverability comes a new way to move a robot: field-oriented drive. Field-oriented drive means no matter which way the bot is facing, pushing forward on the joystick makes the bot move up the field, and pushing left on the joystick always makes the bot move to your left across the field. Compare this to robot-centric drive, the traditional control system. Push up on the joystick, the bot will move in the direction it considers forward. If the bot is turned to the left 90 degrees, and told to go forward, it will move left across the field, because the robot's forward is pointing to the field's left.
For those that don't quite understand field-oriented vs. robot-centric drive, I'll see if I can get a better explanation up in a while. Until then, just trust me that it's a good thing to have.
I had it driving as of last week Saturday. Forward, backward, strafing, and turning worked. Frisbeeing came along Sunday, if I recall correctly. It has some drift depending on the exact maneuver, and it doesn't drive as fast sideways as forward. I'm tracing most of this back to the motors, but my parents think it won't drive as fast sideways because of the nature of Mecanum. Could be, but I don't see how the physics works out for that.
I had 1.875 people working on it at once. These might have been mentors, fellow team members, mentors from other teams, ex-mentors, pretty much anyone I could justify borrowing. There is no way I could have gotten this far as fast as I did without them.
This post probably leaves a lot of unanswered questions. Some I will answer in future posts (I know there will probably be at least one more post today), others I will need comments asking them before I answer them. So, if you have a question, hold on to it for a while, and see what else I post. If I don't answer it in a couple of days, post a comment.
Subscribe to:
Comments (Atom)