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.
**
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.
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.
**
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.
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).
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 USASEFlast 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.
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.
**
[/li]
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…
For those of us who don’t play video games, could you please state what “halo style controls” means ? i.e. what mecanum function is assigned to each of the joystick axes. Thanks
**
Movement is assigned to one joystick (either forward or strafing, the robot moves in the direction the joystick is pressed), and the other joystick controls rotation / orientation. Much like Halo and other console first-person-shooters.
I agree with your Chris. Since the student sthat are going to drive the robot generally have played halo, or at least a game similar to it, it makes it very easy to pick up the controls. Also, if someone came up with a better way to control omnidirectional drive systems (mecanum, swerve, etc), I would consider using it. But given the number of people who already know how to use “halo controls,” I doubt I would use it.
Side note: my team is prototyping a swerve drive this fall and we are using halo controls for the robot.
I’m a big fan of segregating different degrees of freedom to different joysticks. We currently use arcade drive on a skid steer, with on stick for throttle, and the other stick for turning. A human being is not very good at moving a stick perfectly in one axis.
I feel the same way for using the twist of a stick as the Z, that’s just way too much for a driver to do with one hand, after all, he has two.
I believe, as chris described, that translation on one stick, rotation on another, is the way to go. This is the most intuitive, and worked great for us on our prototype crab.
The suspended chassis is not a bad idea for mecanum wheels, but unless you need a lot of suspension travel I would just use it with a flexible chassis.
Completely agreed. We do the same, and it has worked very nicely.
mechanum don’t really need any special considerations when mounting, almost any configuration will work, the main difference from tank is in the programming