Our team is trying to build a mecanum drive so we can add it to arsenal of drives. We have never made a successful mecanum drive yet. My freshman year (overdrive) we tried but our gear ratio was miscalculated and we could barely move. So now I want to make one that we can play with and possibly use (rebuilding/coding for the season of course). My questions are:
What’s “best?”
-Wide, Long, or Square Frame (wide=wheels parallel to each other are farther apart than the wheels behind/in front of it, long=wheels are closer to the ones in front of/behind it than the ones parallel to it.
-Chain Driven or Direct Driven
-Field Oriented or Robot Oriented
*by best I mean in your experience what have you done and what where the upsides and downsides. what has worked well for you and what has been bad.
I have done a quick search and found how to build mecanums but nothing that shows why one might be better than another. If I missed something Please point me to it.
You’ve heard the saying in real estate: “Location, location, location”.
Well, with a mecanum vehicle it’s “Wheels, wheels, wheels”.
If you don’t have well-designed wheels nothing else matters. Well-designed wheels are very expensive. The rollers are crucial: they must have the proper contour, overlap, alignment, and mounting (bearings).
Secondary considerations are wheel mounting (high lateral stiffness) and closed-loop speed control.
that thread sounds more like the code side of the drivetrain. i think the OP was looking for the physical design of the drivetrain.
i have never built one but i have seen many others. generally, you want to run them with the wheels parallel to the main direction of travel. wide will turn better but if your manipulation design does not allow for it, don’t sweat it (true for all drivetrains other than crab).
as for direct vs chain, there are pros and cons:
chain- less foolproof (thown chain= not good), but has greater flexibility of tranny and motor placement. this year chain was a good choice for mecanum (and any other wheel drives). also allows far addition gear reduction via sprocket sizes
direct- very reliable (spur gears are strong and very few teams if any use multi-speed trannies for mecanum). tranny and motor location limited to next to the wheels. depending on wheel size, stock gearing may need to be reduced to give a proper amount of torque (keep in ming mecanums have less traction so torque is less of weapon).
speaking of traction, that is another issue mecanums always seem to have- they do not have much traction compared to traction wheels. this is why teams will still use crab drive even though mecanum is just as mobile and much simpler. this is a good point to keep in mind when 2011 design time come along.
Not necessarily. For a crab-drive to turn better, it requires 4-wheel independent steering and driving, with complex software and driver interfaces (the second is harder) to align each wheel with it’s arc, and drive it at the correct speed.
Most teams that I have seen have independent drive motors (If they have 111-style pods, with integrated motors), and 2 steering motors. If the sides are slaved together (both lefts with 1 steering motor, both rights with 1 steering motor) you can’t turn better than a skid-steer. With the front/backs slaved together, you can rotate them in either “car” (front-steer ackerman), “forklift” (rear-steer ackerman), or both, which will help but not be as optimal as 4-wheel independents steering.
exactly. what i was trying to saw was that wide drive tends to work better on all drives other than crap, since crab can be either depending on what directions the wheels are rotated at any given time. crab tends to throw a good amount of general rules out the window when it come to drivetrains.
crab is one of those things that is awesome if done right but disaster if done wrong… there was a team that shall remain anonymous that tried crab in 2006 and were forced to run it tank-style due to the programmers not having the members and time to program crab. the robot worked, but it could have been better had they opted not to try crab that year.
bottom line: crab takes a lot of effort to do right… if you are not sure if you can do it, it might be best not to.
You can also turn a crab drive well by connecting diagonal pairs of wheels together (like 1717 did last year). This lets you both strafe and orient your wheels in a “diamond” pattern for turning on a dime.
This configuration lets you crab and turn in place, but turning while translating is difficult.
I actually took some time last year to analyze 25 different possible steering/driving configurations for crab drives. Basically, it combined all of the typical driving and steering configurations in a giant matrix, and figured out what drive modes (crab, tank steer in both long and wide, snake/car steering) would be possible (both with and without skidding the wheels) in each. I should probably wrap it all up into a white paper when I get a chance. I looked at:
4 drive transmissions (one per wheel)
-Steered all together
-Steered in pairs (F and B, L and R, diagonal)
-Steered individually
2 drive transmissions (F and B)
-Steered all together
-Steered in pairs (F and B, L and R, diagonal)
-Steered individually
2 drive transmissions (L and R)
-Steered all together
-Steered in pairs (F and B, L and R, diagonal)
-Steered individually
2 drive transmissions (diagonal)
-Steered all together
-Steered in pairs (F and B, L and R, diagonal)
-Steered individually
1 drive transmission driving all wheels
-Steered all together
-Steered in pairs (F and B, L and R, diagonal)
-Steered individually
The only configuration that gives you perfect (no skidding necessary) crab and turning under all possible circumstances is the 4 drive transmissions/4 steering transmissions case.
For the mathematically inclined, the above result is equivalent to Equation 3 which is derived in this white paper. It shows the necessary X and Y components of velocity at each wheel to achieve any desired vehicle simultaneous translational and rotational motion.
Using the results from Equation 3, the wheel angle for the nth wheel is -ATAN2(Vyn,Vxn), and the wheel rotational speed for the nth wheel is sqrt(Vxn^2+Vyn^2)/r.
Ok so from what I got it does not necessarily matter your ratio wide-long and the wheels have to be in an X. Thank you so much. Now does the COG have to be in the center of the wheels?
CoG doesn’t need to be in the center, but it helps (when some wheels start slipping before others, control gets difficult - a roughly central CoG will help to evenly distribute your normal force among the wheels).
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.
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.
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.