Swerve with a twist

[Ether]

Originally Posted by Harshizzle

Repeatable holonomic actions could be performed

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:

Originally Posted by Harshizzle

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.

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

[/EDIT]

[Ether]

Originally Posted by TheHolyHades1

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.

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

[GeeTwo]

Originally Posted by TheHolyHades1

Are you suggesting something like what I've attached?

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.

[Ether]

Originally Posted by GeeTwo

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

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

[GeeTwo]

Originally Posted by Ether

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)

[TheHolyHades1]

Originally Posted by Ether

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

The black boxes are steering motors, whose outputs are directly attached to the swerve modules beneath them. There is no clutch / braking system of any sort.

[TheHolyHades1]

Originally Posted by GeeTwo

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.

This reminds me of one of 1640's robot drives, called a "twitch" drive. They credit 1565 for the original idea. You may want to check it out here: http://wiki.team1640.com/index.php?title=Twitch

[Harshizzle]

Originally Posted by Skywalkar

^^^ no image


Also, here's a quick Inkscape job:

Yeah, this is exactly what I was attempting to describe.

There are two states, one where the o axle is allowed to coast, and one where it is not.

I agree, for FRC purposes this would create far more problems than it would solve. But I wanted to bring it up for discussion anyway.

This design cannot do simultaneous steering and moving with any sort of accuracy, but in cases when that is not needed (I'm picturing something like an amazon warehouse robot), this could be an option.

[GeeTwo]

Originally Posted by TheHolyHades1

This reminds me of one of 1640's robot drives, called a "twitch" drive. They credit 1565 for the original idea. You may want to check it out here: http://wiki.team1640.com/index.php?title=Twitch

Yes, that's the same effect I was talking about. Mine had no diagonal linkages; each wheel's rotation was linked to the two adjacent wheels.

[seanthompson]

Rather than using a braking system, it seems simpler to me to have a shifting "swerve" drive, where one gear rotates the module, then shift into the other to drive the wheel. This has the same effect of only using 1 motor, and the robot can not move and rotate its wheels at the same time. It also eliminates the need for a braking system, and gets rid of some nasty math. However, it would be a lot of shifting...

[Chak]

Originally Posted by seanthompson

Rather than using a braking system, it seems simpler to me to have a shifting "swerve" drive, where one gear rotates the module, then shift into the other to drive the wheel. This has the same effect of only using 1 motor, and the robot can not move and rotate its wheels at the same time. It also eliminates the need for a braking system, and gets rid of some nasty math. However, it would be a lot of shifting...

For ball shifting and dog shifting, when you shift, the other gear becomes free spinning right? So when you are turning your wheels the wheels would be free, which is not much of a problem. But when you are driving, won't your wheels be free to turn randomly? Unless you use a brake...

[MoistRobot]

Originally Posted by GeeTwo

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

Or it's becoming even MORE clever and is trying to convince you it's human!

Okay Ether, read the following and respond as quickly as possible-
It's your birthday. Someone gives you a calfskin wallet...

[Ryan_Todd]

Originally Posted by Harshizzle

Yeah, this is exactly what I was attempting to describe.
[...]
This design cannot do simultaneous steering and moving with any sort of accuracy, but in cases when that is not needed (I'm picturing something like an amazon warehouse robot), this could be an option.

Thanks for confirming my interpretation.

Personally, I would be less interested in this concept as a "Plan A" design than as a case study in control systems design. As discussed above, this still has the same total number of outputs as a traditional independently-steered swerve drive, but it nonetheless manages to be an under-actuated system; this would therefore save relatively little in cost and complexity, while giving up a fair amount of controllability in the process. If you're looking to save on cost and complexity, after all, it's hard to beat a good old-fashioned skid-steer setup.

Don't get me wrong, however, because I strongly believe that this project would still be completely worthwhile-- and indeed, quite valuable in the real world! The key is to shift gears a bit, and instead view this as a research project.

As a software engineer in the automotive industry, I always need to be mindful of the fact that the real world isn't perfect; things go wrong all the time, and my work needs to be able to take that in stride. As a result, my job is not simply to get my component to work right, but rather to ensure that even if the rest of the system is compromised to the point where my component cannot work right, it will still never work wrong. If that means slowing down the engine to prevent it from overheating (or stopping the engine altogether to prevent it from exploding), then so be it!
This kind of thinking is essential whenever the end user's safety is at stake, and strongly advisable in many other applications.

With this in mind, can you see a way that it might be helpful to have an understanding of how to control a swerve drive platform, even if one or more axes of control are disabled, modified, or behaving abnormally?

(It may, for example, be advantageous to design a swerve drive specifically to allow for the possibility of falling back to an alternative control scheme like the one described above.)

[lovelj]

What would be better is a powered caster. By offsetting the steering axis but having it rotated 90 deg from your design you can achieve true Holonomic omnidirectionality. The steering axis imparts a velocity that is orthogonal to your rolling axis. No matter what the configuration of the pods, you can instantaneously move in any direction. There is a nice closed form solution for the inverse kinematics. We built a munition loader for the navy using this approach. I've debated about trying it on a FIRST robot with 3824. Good summer project. I've got a publication on it if anyone is interested

[Kevin Leonard]

Originally Posted by Skywalkar

(It may, for example, be advantageous to design a swerve drive specifically to allow for the possibility of falling back to an alternative control scheme like the one described above.)

Dude that would be so cool.
A steering motor burns out, so somehow the robot shifts into using the drive motors for both drive and steering.
I'd love to see that implemented by someone (although probably not on an FRC robot, that sounds far too complex and unnecessary. If a motor burns out in a match, its probably better to just wait two minutes until the match is over and repair it.)