Mecanum. What's Best

[Ether]

Originally Posted by kgzak

Ok so from what I got it does not necessarily matter your ratio wide-long...

Correct.

...and the wheels have to be in an X.

As viewed from the top. Right way Wrong way

Thank you so much. Now does the COG have to be in the center of the wheels?

No, but it helps. See Jared341's post.

[Chris is me]

above post reported

[jamie_1930]

My opinion is
- Use a long frame, so that the wheels are square with one another. Having the wheels, in a "long" or "wide" orientation can cause the robots rotation to be skewed from the center due to a different force being applied in rotation of the robot due to an irregular center of gravity.
- Direct driven will be better to use because the signals sent to the motor will be better applied to the wheel, especially in changes in direction due to any slack in the chain causing the wheel to not move for a short interval of time, while the slack shifts.
- During this years game we had the option of using both field-centric and robo-centric drives and switching between both during the same match. Even though we had that option we never switched from robo-centric. field centric can be thrown off and change completely the direction the robot will travel relative to the joystick, this can occur during quick changes in direction due to fast turning, bumping into the field or with other robots. Therefore I would endorse robo-centric, however field centric would be a good thing for your programmers to learn how to do, but I wouldn't implement it until your drivers feel confident with it.

Also as Ether said the wheels can be a major concern. you want to have the sub-wheels all freely spinning, but ideally wheels of this design would be the most prefered, http://www.chiefdelphi.com/media/photos/25159, because they will prevent the wheel from bumping up and down. Similar to the difference in performance between single and double omni wheels.

[Ether]

Originally Posted by jamie_1930

field centric can be thrown off and change completely the direction the robot will travel relative to the joystick, this can occur during quick changes in direction due to fast turning, bumping into the field or with other robots.

This problem can be mitigated by adding a "calibrate" function in your software and binding it to a driver-convenient button or trigger on the joystick.

Whenever the robot's field-orientation sensor loses calibration, the driver can quickly rotate the robot to some pre-determined orientation (most likely aligned parallel to the length of the field) and push the button to re-calibrate.

[Ether]

Originally Posted by jamie_1930

Use a long frame, so that the wheels are square with one another. Having the wheels, in a "long" or "wide" orientation can cause the robots rotation to be skewed from the center due to a different force being applied in rotation of the robot due to an irregular center of gravity.

Not entirely sure what you mean here by "irregular" CoG. As long as the CoG is equidistant from all 4 wheels it doesn't matter if the wheels are located at the corners of a square or a rectangle (within reason). As Jared341 explained in an earlier post, the purpose of centering the CoG is to distribute the normal force equally on all 4 wheels.

[jamie_1930]

When irregular CoG I meant non-centered, and that's probably the word I should have used, because I find that on most, if not all, FIRST Robots you will see a non-center CoG. If anyone has proof that they have built a CoG centered robot I would love to here how they did it.

[Ether]

Originally Posted by jamie_1930

When irregular CoG I meant non-centered, and that's probably the word I should have used, because I find that on most, if not all, FIRST Robots you will see a non-center CoG. If anyone has proof that they have built a CoG centered robot I would love to here how they did it.

Yeah, it's pretty tough to control the CoG precisely. But CoG should always be on your mind as the robot is being designed. The design criteria for mec wheels is equal normal force on all 4 wheels, as much as possible. This does not mandate locating the wheels at the corners of a square.

[lbarger]

Originally Posted by Ether

Yeah, it's pretty tough to control the CoG precisely. But CoG should always be on your mind as the robot is being designed. The design criteria for mec wheels is equal normal force on all 4 wheels, as much as possible. This does not mandate locating the wheels at the corners of a square.

Well said. The challenge is to try to get as close as possible to the same normal force on each wheel. If your CoG is skewed to the front, move the rear wheels forward some.

From my experience, the normal force does not have to be exact. We had the CoG off by several inches (front biased) and did not have major issues. We had more of a problem with our budget built gearboxes having different amounts of internal friction. If I were to do it again, I would vote for toughbox (standard or nano) driving each wheel.

[Ether]

Originally Posted by lbarger

We had more of a problem with our budget built gearboxes having different amounts of internal friction. If I were to do it again, I would vote for toughbox (standard or nano) driving each wheel.

You could go one step further and use wheel speed sensors to control wheel speed, thus mitigating not only friction variation but also differences in motor torque gain.

[Katie_UPS]

From our experience with mecanum:
-Make sure all wheels are touching the ground: Aside from wheel orientation (diamond vs. X), its been our biggest problem with mecanum. Make sure your frame doesn't warp or use a "suspension" chassis (we did this with pods and springs).
-Use 8 inch mecanum wheels: The 6 inch ones (back in '08) pinched the rollers. I've heard that the 6" wheels have been improved, but we switched back to 8" since.
-Don't pinch the rollers: Otherwise the wheels WILL NOT WORK (I think most people know that, though).
-As said, orientation (diamond vs X)

All of our mecanums that I can remember have been chain driven so I'm not sure the difference it makes (asides from the general pros/cons of chain vs direct driven).

We've found mecanum to be good for manuverability and its pretty easy to get used to when you drive (we drive with two joy sticks-one for back/forth/left/right, and another for orbiting/point turns). We also think it makes for great demos (people get a kick out of robots driving sideways).

They do, however, get pushed around fairly easy, and messing up wheel orientation is a pain. Also, if your frame warps or rollers get pinched, it doesn't play nice at all.

[JesseK]

My personal preference is the same as forbes' for the Mechanical setup. It's simple and easy to build since it requires very little modification from even the KOP chassis.

My personal preference for Controls is to drive it like a normal bot ("Tank" controls or "Arcade" controls) and use a joystick hat to control 8 possible strafe modes (where "Up" and "Down" on the hat are the same as forward & back). This greatly simplifies the control element and allows a driver to gain practice very early on.

For most teams, I'd say let the rest of the robot integration sway the vote for wheel setup/orientation (wide vs. long). So long as the bottom makes an "O" & c.g. isn't way out of whack, the robot will not have problems turning. "Integration" in this sense is "how wide" the robot needs to be in order to accomodate the forseen mechanisms your team will come up with (intake to conveyor systems are predominantly wide drive, whereas most other years it can flip either way).

[Ether]

Originally Posted by JesseK

This greatly simplifies the control element

Could you elaborate please? What is it greatly simpler than?

[JesseK]

Originally Posted by Ether

Could you elaborate please? What is it greatly simpler than?

It greatly simplifies it from control setups can be observed at (I'll conjecture) any FRC Regional, where the drivers themselves do not seem to have a full understanding of the best way to move the bot around. That problem is a result of either complex controls or lack of practice. In either of those cases, it's advantageous to simplify the controls. My case here also assumes that the drive train is geared for a balance of speed/acceleration (10-11 fps) for a typical* 140-150lb robot.

Here are what I consider 'bloated'

• 2 Joysticks that control different degrees of freedom**.
• 1 Joystick that has a "twist" action for a z-axis rotation, in which users (from novices to veterans) unknowingly twist it ever so slightly while trying to strafe
• Control software code where (as an example of negligible amounts) 10% more rotation control input from a joystick translates to 10% more rotational output from the robot even while the robot is strafing
• Overly sensitive controls where fine muscle movement is needed (like game pad thumb sticks) for the difference between (example) strafing left and strafing the forward left diagonal. This is particularly noticeable when combined with the 3rd bullet.

Additional programming or practice may alleviate the problems of the above situations. However, starting with something fundamentally simpler would also alleviate the problem with less impact on the robot's schedule. In other words, the drivers get more practice learning the robot's interaction with game elements rather than learning how to make the durn thing move as expected.

I was able to observe many matches with Mecanum drive trains as Scouting mentor in 2010. I was also able to observe hundreds of little kids at the USASEF last weekend as they drove a couple of Mecanum drive trains on the mini field. So really, this is all just based upon my observations and opinions, for whatever one feels they're worth.

*Typical here is what I've seen on field. A CIM motor that drives a 6" Mecanum wheel that is mounted directly to an AM Toughbox (or Nano) moves the robot at roughly 10.5 ft/s. Under normal conditions, the motor load across 4 motors for such a setup is near peak efficiency of the CIM motor regardless of a Mecanum drive train's wheel base (since all 4 force vectors assist in turning on a Mecanum drive train).

**I've yet to observe a driver who is naturally a master of the Halo-style of driving without having spent many hours playing Halo already.

[Ether]

Originally Posted by JesseK

Here are what I consider 'bloated'

• 2 Joysticks that control different degrees of freedom**.
• 1 Joystick that has a "twist" action for a z-axis rotation, in which users (from novices to veterans) unknowingly twist it ever so slightly while trying to strafe
• Control software code where (as an example of negligible amounts) 10% more rotation control input from a joystick translates to 10% more rotational output from the robot even while the robot is strafing
• Overly sensitive controls where fine muscle movement is needed (like game pad thumb sticks) for the difference between (example) strafing left and strafing the forward left diagonal. This is particularly noticeable when combined with the 3rd bullet.

...starting with something fundamentally simpler would also alleviate the problem with less impact on the robot's schedule. In other words, the drivers get more practice learning the robot's interaction with game elements rather than learning how to make the durn thing move as expected.

Thanks for making that clearer. I completely agree with the general point you are making (about making a driver interface with a quick learning curve).

I think we disagree slightly on the implementation of that goal, specifically the first two bullet points:

2 Joysticks that control different degrees of freedom

Experience has shown that there is a mecanum driver interface with different degrees of freedom on 2 joysticks which has virtually no learning curve for a driver with prior tank-drive experience. It's an implementation of the "Tank-drive" approach that you mentioned. The left and right joystick Y axes control the vehicle just like tank drive, and the right (or left) X axis controls strafe (but only when a button is held down). More detail available here.

1 Joystick that has a "twist" action for a z-axis rotation, in which users (from novices to veterans) unknowingly twist it ever so slightly while trying to strafe

The above objection is valid, but is easily mitigated by adjusting the gain curve of the Z-axis so that small signals have little or no effect. See this post for more detail.

[Chris is me]

Originally Posted by JesseK

[*]2 Joysticks that control different degrees of freedom**. [*]1 Joystick that has a "twist" action for a z-axis rotation, in which users (from novices to veterans) unknowingly twist it ever so slightly while trying to strafe

I think these two points are related in that the second one demonstrates why one would want to control their robots using the first method...

In all seriousness, "splittling" an arcade drive into two joysticks greatly increases drivability. For mecanum drives I happen to be a fan of "halo style" controls with independent joysticks for movement and rotation, and I don't even play Halo, but I also happen to be a very big proponent of not using a mecanum drive. I guess it just has always seemed more intuitive to me and whatever random kids drive the demo bot...