Drive Systems

[jfitz0807]

We have a WCD with 6" (well, really 6.25") grippy wheels in the middle and 6"omnis at the front and back. The center axis is a little higher than the others so all six wheels touch the ground. It's working very well for us with no trouble getting over the scoring platform, even though the center wheels come off the ground. All three wheels are belted together on each side.

Our driver came up with a unique set of controls. We use an xbox controller. The left stick is solely for forward/backward and the right stick is solely for turns. We read both sticks and feed them into an ArcadeDrive method. Driving straight is very easy because if he lets go of the right stick and pushes the left stick forward, even if the stick is off a little to one side, we read the "y" value only from the y axis of the left stick and the x axis is 0 since there's no force on the right stick.

We developed an algorithm to "slide" the robot left or right. Basically, you use the TankDrive method to move only one side of the drive train back a bit then move only the other side the same amount. Then move forward a small amount and your are exactly one inch left or right from where you started. We attached this to two buttons (one left and one right). It interrupts the Drive command, but give control back when the slide is complete.

We worked out the trigonometry based on wheel diameter, robot width and distance you want to "slide". We had hoped to compute the required distance using vision processing but we didn't get that far. For now we just go one inch at a time.

[WeJohnFriedIt]

Originally Posted by jfitz0807

The left stick is solely for forward/backward and the right stick is solely for turns. We read both sticks and feed them into an ArcadeDrive method. Driving straight is very easy because if he lets go of the right stick and pushes the left stick forward, even if the stick is off a little to one side, we read the "y" value only from the y axis of the left stick and the x axis is 0 since there's no force on the right stick.

Just FYI, this is known as a split arcade drive. Our team is also using it this year, and I can attest that it works well.

[KCruz]

Originally Posted by jfitz0807

We developed an algorithm to "slide" the robot left or right. Basically, you use the TankDrive method to move only one side of the drive train back a bit then move only the other side the same amount. Then move forward a small amount and your are exactly one inch left or right from where you started. We attached this to two buttons (one left and one right). It interrupts the Drive command, but give control back when the slide is complete.

That tank drive "slide" concept is intriguing, especially in more of a precision-driven game. What level of effectiveness have you seen with it, and how far back and forward does your robot have to move in order to achieve this slide?

[Ginger Power]

My college club, Bison Robotics, at NDSU is looking to build a drive system for demonstration purposes. The idea would be to build the drivetrain, film and document our process, and put everything out on social media for others to use as a resource. We also plan on create a highly detailed Bill of Materials and assembly instructions for this drivetrain in order to make it more accessible to lower resource teams.

The idea is to build a unique/original system that can compete with swerve in terms of maneuverability and power. We are not trying to cater to low resource teams in a sense that the drive is simple: there can be a high degree complexity. Basically I'm looking for links or pictures of some of the more obscure drivetrain ideas out there.

Here is a list of drive systems which I am already familiar with:

• tank
• mecanum
• slide
• kiwi
• swerve
• butterfly
• grasshopper

Edit: I forgot octocanum and nonadrive

Are there any other systems I am missing? Thanks in advance for the help!

[EricH]

6WD Mecanum. (4 mecanums, 2 omnis, arranged like a 6WD). 1322 did that about 4 years ago I think (might have been more or less).

[dougwilliams]

My team typically uses mecanum, and we are starting an off-season drivetrain. We understand most but can't see / make sense of some of the omni based drivetrains.

http://www.vexrobotics.com/vexpro/examples-guides

What are the pros and cons of this 2+2 drivetrain? Why only go two omnis vs 4? I could imagine some scrub reduction, but why not all 4 wheels? And if you are using 4 independent gearboxes, why couple each side with belts/chains? Are they trying to mechanically couple and equalize wheel speed per side?

Then we were looking at 1114's 2014 robot, and it looks like 4 wheel traction, but two wheels have butterfly like modules where you can drop omnis on one side (not sure if it was the front or back). Similar to the above, is temporarily reducing scrub important enough to add that weight?

Are we missing some understanding from these designs?

[EricH]

Originally Posted by dougwilliams

What are the pros and cons of this 2+2 drivetrain? Why only go two omnis vs 4? I could imagine some scrub reduction, but why not all 4 wheels? And if you are using 4 independent gearboxes, why couple each side with belts/chains? Are they trying to mechanically couple and equalize wheel speed per side?

Let's start with "why not 4 omnis?". Answer: Sideways motion. You are trying to line up to do X, I hit you from the side. Chances are, you're nowhere near lined up now. So by retaining 2 tractions, you get less sideways motion (you're more likely to rotate than slide) and easier realignment. That being said, 4 omnis is a valid drivetrain, IFF you know what you're doing.

Next up, why couple? The Department of Redundancy Department just called, and said they give this design their approving seal of approval. In case of loss of power in one gearbox, you still get power on all 4 wheels, in addition to speed match.

And the last part, er, first part: The rotation center is different. Scrub reduction is a major item, too--4 high-traction wheels in a long configuration, all driven, will bounce 130 lbs of robot around when the robot tries to turn, in most cases. So by using omnis on one end, you get smoother turning, but you also get a very predictable center of rotation...which, as it turns out, can be quite useful in a "precision" game like Recycle Rush.

[dougwilliams]

Originally Posted by EricH

...

Thanks!

Has anyone seen any before/after video of 4W or WCD with and without omnis to show those differences?

[Chris is me]

Originally Posted by dougwilliams

My team typically uses mecanum, and we are starting an off-season drivetrain. We understand most but can't see / make sense of some of the omni based drivetrains.

http://www.vexrobotics.com/vexpro/examples-guides

What are the pros and cons of this 2+2 drivetrain? Why only go two omnis vs 4? I could imagine some scrub reduction, but why not all 4 wheels? And if you are using 4 independent gearboxes, why couple each side with belts/chains? Are they trying to mechanically couple and equalize wheel speed per side?

There are a few pros to having two traction wheels in a setup like this. The biggest thing is that you retain some amount of tractive force for pushing matches - while omni wheels have some forward traction, most traction wheels have more, so you'll still be able to push with a 2+2 setup. The second is that your turning center is usually directly between the two traction wheels. There is, theoretically, *no* scrub in a 2+2 wheel drivetrain, because the omni wheels are the only wheels sliding laterally at all. The traction wheels become the point of rotation for the system.

The pros to belting the two gearboxes together on each side have less to do with speed and more to do with motor load. It's most obviously useful in a pushing match, but any time that your CG isn't perfectly centered it provides some benefit. Consider the extreme case where you're trying to push a robot, but your omni wheels leave the ground. This means your traction wheels can only push with 2 CIMs of mechanical power. If the wheels are belted together, you get the force of all 4 CIMs on those wheels. This same principle applies when all four wheels are touching the ground, but the force on each wheel is not even, such as when the CG of the robot is closer to one set of wheels than the other set. Essentially it lets the mechanical power of each motor go to where its most needed. It also gives the drivetrain a little redundancy, but that's not really why it's done in most cases.

Then we were looking at 1114's 2014 robot, and it looks like 4 wheel traction, but two wheels have butterfly like modules where you can drop omnis on one side (not sure if it was the front or back). Similar to the above, is temporarily reducing scrub important enough to add that weight?

It's a six wheel traction drive, with dropped center wheels. The drive behaves as a 4WD effectively, as the dropped center wheel raises one end of the robot slightly, but with a short enough wheelbase that the robot can still turn on a dime.

The reason for the drop down omni wheels (which I believe are unpowered) is not quite obvious, but it has to do with the mechanics of a high traction drive in a pushing match between two robots with compressible bumpers and rough fabric. This may sound like an extremely specific edge case, and it is very specific to FRC, but it's a real issue. You can T-bone pin a 6WD robot by pushing it hard on the center of its long side. The combination of the direction of pushing force, the two robot bumpers compressing into each other, and the friction caused by the compressed bumpers will result in the defended robot being virtually unable to escape. The drop down omni wheels change the center of rotation for the robot from the center to an extreme end, as the robot temporarily becomes 2 traction 2 omni, and the robot is able to spin free without pushing into the compressed bumper. Or, more likely, the T-bone robot continues to push as the module goes down, spinning 1114's robot out of the pin for them.

[Munchskull]

Originally Posted by Andrew Schreiber

It's just a 3 wheel swerve. There've been a lot of them. (67 - 05, 148 - 08, 16 - Many years)

I have been using the term tumbleweed drive for this. I can't remember if I found it online or if it was use by a team member.

[jfitz0807]

Replying to #18:

It's a function of the distance between the drive wheels. For this year, we have 24.5" between the drive wheels. To slide 1" we have to drive each side back a little over 7" and then drive forward a little less than 7".

Details are attached.

[GeeTwo]

Originally Posted by jfitz0807

Replying to #18:

It's a function of the distance between the drive wheels. For this year, we have 24.5" between the drive wheels. To slide 1" we have to drive each side back a little over 7" and then drive forward a little less than 7".

Details are attached.

Of course, we've done this manually, but haven't automated it -- yet.

Thinking about some tweaks to the system:

For small amounts of slide, the amount of forward/reverse motion scales as the square root of the slide distance (and therefore time), so it should be beneficial to work out how far you're going before you start.

Also, you can slide twice as far with a 1/3 increase in time, by doing L- R- L+ R+ to go right, or R- L- R+ L+ to go left. This technique would also allow all of the distances to be equal, simplifying coding.

[EricH]

Originally Posted by Munchskull

I have been using the term tumbleweed drive for this. I can't remember if I found it online or if it was use by a team member.

148, 2008, was officially known as "Tumbleweed", and was a 3-wheel swerve.

[Munchskull]

Originally Posted by EricH

148, 2008, was officially known as "Tumbleweed", and was a 3-wheel swerve.

Ahh. I still like the name.

[Clayton Summerall]

We use 8 wheel all omni arcade drive.