Swerve with a twist

So after a discussion with my mentor about swerve drive, we thought of a potentially new drive system that is swerve like but a bit different.

What we pictured was a swerve module where the wheel was extended out from the center of rotation.

(top view- The o represents an axle going through the computer screen).
_
| |
| |—o
|_|

When the wheel is powered, and the o axle is prevented from spinning (perhaps using a brake system), the robot would move in the direction the wheel is spinning.

When the wheel is powered and the o axle is allowed to freely rotate, the wheel would turn in a circle, and could end up pointing in a direction you want it to.

With both those combined, the robot could have holonomic drive capabilities.

The biggest problem I see with this is the weight distribution, as the force would be on the o axle, which would not be touching the ground (or maybe it could hmm…). I also dont see this as very practical for an FRC game, because swerve would probably be much faster at orienting itself.

But this drive system would make every swerve module require only one motor and one braking system, which in some industrial applications, could be better.

Anyway, does this already exist somewhere? If not, thoughts?

Could you please post a hand sketch showing top, front, and side views? I cannot form a confident mental image from that ASCII art.

Do you have a way of making sure the robot won’t move forward while the wheel turns in a circle? After all the forward force is still there. Maybe you can turn 2 modules at a time, letting the other two modules brake the robot, but that’s much slower than a traditional swerve.

How about the load on the cantilevered wheel axle?

Yeah, this is a cool idea.
If you’re looking to use less motors though, there’s always crab drive

If you are confident you have a proper understanding of what the OP is describing, would you be willing to draw and post the requested hand sketch?

I don’t see how this is better than swerve drive. Is just sounds more complex.

https://gm1.ggpht.com/Vu9RquG_V3mx0Cyqyx9A9iCgM6N0QNP8EKf0PugA0mmndl_zRxzO9N8oWCak7UQqUlkCJ_TPkVhXwLPlF3AHGNz-Fz-J9V-huZuxuAl7ISzapFxhGito4qkyedziBvQk6SCmYe-YsbWwtCSCaF5U3INf31cCGWyJkIG1sx1XDGQO-1FzzUBt6LH2Nhoev-Ea9qbERttmfocRgIpQp-fnRZdb70wtuY78j6UtWuFhD_SbyChXKZx8SxDb3iVkbwmQMRIzyaCuzga6inXMKWyBhDQNVpDYwFC5jnJdoMyYd2OsvQwwOVRyGbN8wYVvpTD2chK5TiO3UTSpVPsTiXJs27fBAqkcqKtK9f4zQHmNlOgjNl_dHMuG2aT138yCunXT43R8VEqRHSxUFjmcbEb-gtkoiF45AQY37EG6TysEHSLxwX3a9xxwql6jiTBDUViDVuFUojlXHa7jHsbpREsA6vZ0j_4zM6brBsxT_UJezVGCXMPskJvSPmxw8tiW5hEHTjPh0ILhdLO-ECDQd2vWwP6sp6YC44cr-480DVIAIiz3UNXKnTbQyFifKFSQDWOqPJWpEBqsGFN5RxJDql3HHLus-e4J4A-9ZqQ=w1345-h568-l75-ft

Apologies for the darkness, but this is what I had in mind

Error 403](http://www.chiefdelphi.com/forums/attachment.php?attachmentid=19057&stc=1&d=1432850604)

You can attach the sketch to your post. No need to upload it elsewhere.

Error 403.png


Error 403.png

^^^ no image

Also, here’s a quick Inkscape job:





I guess I still don’t understand how this works.

Somebody already posted a pic, so this would be a repeat post.

I feel like this would introduce a lot of variables which hamper reliability, which are not seen in a normal swerve. Your module pivot becomes a lot more sensitive to variations in terrain, weight distribution, and small variations between the modules, for example. The steering code would be no simpler, and in fact may take on new layers of complexity since your motors are performing double-duty. Some maneuvers, such as spinning while translating, would likely become more difficult to control.

It may seem simpler on paper, but I worry that you’re in fact introducing things that will generate a whole lot more trouble for you. In my never-ending quest to learn how to effectively and quantitatively assess design simplicity (ironically, a very complex problem), I’ve become increasingly convinced that “minimize actuator count at all costs” is a crude and shortsighted way of approaching the problem.

Preventing the forward movement could have a lot to do with the load distribution on the modules. Braking does seem like a viable option however.

The load on the cantilever would be something to eliminate from this design, that’s true.

Crab drive sacrifices individual module control for the loss in motors though.

Absolutely, this design solves little simplicity wise.

I primarily see its merits in an industrial setting. Repeatable holonomic actions could be performed, especially when engines are large and hard to fit into a compact design.

Are you suggesting something like what I’ve attached?

I developed this with a former team member for a project earlier, but haven’t around to actually programming for it. Below is a photo of the completed system. Admittedly the wiring is a bit messy - we got around to cleaning that up and it looks a lot more functional now, but I don’t have any photos of that at the moment. It’s sitting in a box, unfortunately.

EDIT: I read through your post again and realize that this isn’t quite what you’re suggesting. Something like what GeeTwo is suggesting below me seems a lot closer to what you’re suggesting.







If I understand correctly, you would essentially be making a gearbox which shifts between two outputs: One would power the wheel rotating against the floor, and the other output would control the orientation of the wheel. To make this work, you would still need a separate shifter control for each wheel to toggle between the states, so you would still need 2N controls where N is the number of wheels. You would also have an interesting time driving and steering simultaneously; you would have to switch back and forth for each steering maneuver. If you’re simply after reducing the number of motors, it might make more sense to provide a (reversible) clutch from the drive shaft that can borrow a small fraction of the drive torque in order to steer. I still suspect that the extra complexity of the system would outweigh the reduction in motor count for most FRC purposes.

Highly doubtful.

The steering is not independent of the direction of wheel speed. You can’t make bi-directional steering corrections while maintaining wheel speed. Such actions are required for simultaneous 3DoF maneuvers.

Edit:

I see GeeTwo said much the same thing in the preceding post.

But I also see there is still much confusion about exactly what the OP has proposed:

… so a clarification by the OP would be much appreciated.

Your original interpretation (and sketch) seems to comport more closely with the OPs original post*:

When the wheel is powered, and the o axle is prevented from spinning (perhaps using a brake system), the robot would move in the direction the wheel is spinning.

When the wheel is powered and the o axle is allowed to freely rotate, the wheel would turn in a circle, and could end up pointing in a direction you want it to.

*assuming there are no steering motors

If the boxes at the top of the steering modules are motors or servos, I don’t think so.

A bit off topic, but your robot reminds me of a linkage drive I played with a few years ago that “shifted” from forward to transverse driving through the regular drive motors. The idea was that the steering of the wheels were coupled so that the left front and right rear pointed the same direction at all times, as did the right front and left rear. Adjacent wheels steered in opposite directions. At one end of the 90 degree range of steering, all pointed “forward” and at the other, all pointed “transverse”. When driving forward, the two left wheels were controlled to have the same speed, and the two rights. When driving transverse, the two forwards would match, and the two rear wheels would match. In each of these states, there was theoretically no net torque seeking to shift from one state to the other (practice wasn’t so kind). To “shift” from forward to transverse or back, one diagonal pair was driven clockwise, and the other counterclockwise for a second or so. Eventually I realized that it was really just a lobster drive that required four proportional controls. Originally, I had ideas that it could also settle in a “rotate” state halfway in between the other two, but I could never find or hold that state without even more complexity and possible points of failure.

Addendum: also, due to more to lack of fabrication skills and tools than the design, it was probably the ugliest machine I’ve ever built.

Good point. I only looked at the first link and didn’t see any motors there and so inferred there weren’t any.

Ether passes the Turing test! (sometimes he seems too perfect to be human)