Chainless Mecanum Drive

[Chris is me]

With the Nonadrive, I would say the mechanical complexity in design would be in making the pivot modules rigid enough for FRC applications. In particular, when resisting pushing a moment is applied through the modules (I think?) since the traction wheel is on a module, so the forces are transferred through the chassis via the pivot axle. It seems a lot esaier to make a standard 6wd than to make a Nonadrive. The extra weight assumes a lack of sheet metal capability and having to use thicker sideplates due to a lack of ability to add flanges among other things like that.

I would argue that Nonadrive is simpler to code because it basically takes zero programming, but basic robot centric mecanum code is not a tough challenge either.

@JesseK: I was suggesting 1 CIM + 1 FP in each of the forward wheels and then just a CIM on the side wheel since strafing is secondary to forward motion for a slide drive (if it isn't secondary, you should probably be using a holonomic chassis). With a crab module in the center I would probably suggest 2 CIMs on that and 1 CIM + FP on the outsides (off the top of my head here, not based on math or anything)

[Ether]

Originally Posted by apalrd

Nonadrive:
...
Here is how it works:

There are four omni wheels on the perimeter of the robot, driven in standard tank drive. Each wheel is on a "pod" with a high-traction wheel, and the pods are pneumatically moved so the traction wheels can either provide traction or float above the ground.

In the middle there is a single omni wheel, driven by a single CIM, which is sideways (to cross the bumps, 148 and 217 pneumatically lifted this wheel a few inches to give them the center clearance necessary to cross the bumps).

This provides the "standard" amount of power (4 CIM's, or around 1.2 kw) in the forward/backward direction, while allowing non-pushing motion sideways. Since omni wheels are push-able, they can lower the perimeter wheels to push or avoid being pushed.

Originally Posted by Chris is me

I would argue that Nonadrive is simpler to code because it basically takes zero programming

so robot-centric nonadrive in tank mode looks something like this:

Left-side motor(s) = Y1

Right-side motor(s) = Y2

Center_motor = X or zero, 
depending on whether traction wheels 
are raised or lowered

... plus code to respond to commands 
and decide when to raise and lower the traction wheels,
and set flags to let the center motor code know 
what state the traction wheels are in

and robot-centric mecanum in tank mode looks something like this:

motor1 = Y1 + X

motor2 = Y2 - X

motor3 = Y1 - X

motor4 = Y2 + X

... plus code to normalize the motor commands to the range -1 to +1

Frankly, I don't see where nonadrive is simpler.

[Alan Anderson]

Originally Posted by Ether

Frankly, I don't see where nonadrive is simpler.

That's because you're adding things that aren't required. For a basic nonadrive, three joystick axes directly control three motor outputs, and one joystick switch directly controls one solenoid output. Sure, you can make it fancy with toggle functions and motor limiting, but you don't need to.

A basic mecanum drivebase is certainly easy, but the connection between inputs and outputs is not one-to-one, and you have to do some post-processing to scale motor values if you don't want unexpected behavior at high speed.

[Ether]

Originally Posted by Ether

Frankly, I don't see where nonadrive is simpler

Just to be clear: For a fair comparison of the code required, you have to compare apples to apples. Mecanum requires no special operator intervention or programming to actuate raising or lowering of wheels. To be functionally similar to this for comparison, nonadrive requires extra operator input(s) and extra code to respond to those extra operator input(s) to raise and lower the traction wheels and control whether or not to power the center wheel. To be functionally equivalent (same driver interface and same robot behavior), nonadrive requires extra logic to react to the normal joystick axis driver commands and decide automatically when to raise or lower the traction wheels (for example, when strafing or tight turning is commanded).

This is not an argument that mecanum is "better". Just a comparison of the code involved. The code for either is fairly straightforward.

It would be interesting to hear from teams that have fielded successful nonadrive robots. Did you add extra input(s) and associated code for the driver to manually raise and lower the traction wheels, or did you add logic to process the "normal" driver commands and let the robot automatically handle this decision in order to keep the driver interface simpler, or did you design a "hybrid" compromise with manual operator input(s) plus some automatic behavior?

[Tom Line]

Originally Posted by Andrew Schreiber

Actually, I would make the opposite argument. Mechanically a Nonadrive (one that does not need to cross bumps) is only slightly more complicated than a standard 6wd robot. Remember, the perpendicular wheel does not need to raise or lower if it is a flat field. From a programming standpoint it is much much simpler. The hardest part about mechanum drive machines is controlling them. It involves either lookup tables and interpolating results or using lots of sins and cosines or matrices (Thank you Ether). A nonadrive is simple in that for translation all you need to do put the Y component of your translation stick to the left and right drive motors and the X component to the cross drive motor(s) Rotation is a little trickier but you could just scale the left and right based on your rotation input. Either way, much simpler than mechanum.

It should also come out near the weight of a mechanum drive train. Remember mechanum needs 4 gearboxes, Nonadrive needs 3. Yes Nonadrive requires 4 cylinders but if you were planning on using air anyway that is not a ton of weight.

I will admit that the Nonadrive has, at least after a cursory glance, more failure points.

TLDR, there are benefits and drawbacks to both systems (like any systems) but neither one is inherently more complicated.

EDIT: Appended note about Ether's solution.

One item to consider with the nonadrive is that even on flat ground you will VERY likely want your center wheel to still be actuated by a pneumatic cylinder.

There is a reason stools usually have 3 legs. Having a 4 legged stool is more difficult. From experience (we attempted a solid 6 wheel rectangular drivetrain in '08 with all omnis), having your corner wheels and the middle wheel all touch if they are fixed is nearly impossible. This is why you must have pneumatics - if you rock on the center sideways drive wheel you will end up going in circles. It needs to push against the floor, but not with enough force to actually support the robot. That means some sort of suspension is required.

We used a laser to get our frame and 6 wheels straight, then realized that the floor many of the arenas was imperfect as well. We didn't much want to go back and engineer suspension, so we dropped the system and went standard 6 wheel.

It looked like this:

.......Wheel.........
........................
W....................W
h.....................h
e.....................e
e.....................e
l......................l
........................
W....................W
h.....................h
e.....................e
e.....................e
l......................l
........................
.......Wheel.........

We saw several teams using this same drive train this year, and they all seemed to experience the same problems we did during our prototyping before we threw it out - with no suspension the robot reacts differently depending on which wheels are touching the ground (Obvious when looking at it, perhaps not so obvious when designing it).

[Siri]

Originally Posted by Tom Line

One item to consider with the nonadrive is that even on flat ground you will VERY likely want your center wheel to still be actuated by a pneumatic cylinder.

There is a reason stools usually have 3 legs. Having a 4 legged stool is more difficult. From experience (we attempted a solid 6 wheel rectangular drivetrain in '08 with all omnis), having your corner wheels and the middle wheel all touch if they are fixed is nearly impossible. This is why you must have pneumatics - if you rock on the center sideways drive wheel you will end up going in circles. It needs to push against the floor, but not with enough force to actually support the robot. That means some sort of suspension is required...

This gave us major steering problems back in Overdrive as well. (In Lunacy we went with it.) That whole "3 [noncollinear] points define a plane" thing means extra contact points need to be somewhat forgiving. As pointed out, life isn't perfect even if your chassis somehow is. How you address that is up to you, whether suspension or actuation (or even somehow in driving), etc, but I would recommend addressing it. Not that this would necessarily add an unacceptable (or even particularly significant) level of complexity.

[apalrd]

Chain-less Mecanum:

Use AndyMark Toughboxes or Toughbox Nano's and mount the mecanum wheels on a hub, directly on the axle. Works well. Many teams that I saw did this (most mecanums I saw were direct drive), although I have no specifics. If you look at AndyMark's website, they have a drivetrain kit for 4-wheel direct-drive mecanum with toughboxes.


Nonadrive:
The creation of teams 148 and 217 (Robowranglers and Thunderchickens, respectively), it is a 9-wheel drive system essentially a convertible slide drive. Here is how it works:

There are four omni wheels on the perimeter of the robot, driven in standard tank drive. Each wheel is on a "pod" with a high-traction wheel, and the pods are pneumatically moved so the traction wheels can either provide traction or float above the ground.

In the middle there is a single omni wheel, driven by a single CIM, which is sideways (to cross the bumps, 148 and 217 pneumatically lifted this wheel a few inches to give them the center clearance necessary to cross the bumps).

This provides the "standard" amount of power (4 CIM's, or around 1.2 kw) in the forward/backward direction, while allowing non-pushing motion sideways. Since omni wheels are push-able, they can lower the perimeter wheels to push or avoid being pushed.