Swerve with a twist

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.

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: Twitch - DEW Robotics

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.

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.

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…:rolleyes:

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…

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.)

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

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.)

If you want holonomic omnidirectionality (swerve is by definition non holonomic, the system discussed here is likewise non holonomic), here is a link to a fact sheet on a system we developed that uses powered casters which provided holonomic omnidirectionality using conventional tires.


Its a slight twist on the swerve (e.g. in-line orientable wheels) and the conventional car steering topology discussed here. It’s the third option for a powered steering/rolling system. OCILOW - Off-Center In-Line Orientable wheels (e.g. a fancy way of saying powered caster). By having the steering axis offset from the rolling axis and behind the wheel rather than next to it, the steering axis causes a velocity vector that is orthogonal to the rolling axis. Coordinated control of the steering and rolling enable instantaneous velocity vectors in any direction (e.g. holonomic) using conventional tires. You get very cool catenary type coordinated motions of the wheels, no skid while transitioning instantaneously from forward to sideway motion. The system is very robust and is highly redundant. You can still have full holonomic control with only two wheel pods active, the one or two being passive casters. It had a very cool double enveloping worm gear to drive the rolling axis. The challenge is the controls. If you have 4 active pods, you have 8 motors to control 3 degrees of freedom (x, y, theta). However, there is a closed for solution for the inverse kinematics, solving for the instantaneous velocities for all rolling and steering motors giving a desired Cartesian velocity vector (x_dot, y_dot, theta_dot). The cool part is that, no matter what the wheel pod configuration (if you look at the picture, we intentionally got the steering axes all different), it can still instantaneously move in any direction.

My group actually developed the split hub spherical wheel in the mid 1990s which was similar to the mecanum. We built a weapon loading system for the Air Force but the tires would wear out fast. It had a 7 DOF force reflecting arm on a holonomic omnidirectional platform. One person could load a 2000 lb weapon on the wing of an aircraft feeling the wedging and jamming when loading the weapon on the wing pylon. The holonomic motion was necessary for navigating under the wing. Unfortunately, like the mecanum, you have point, rather than surface, contact with the ground so your traction is low and tire stresses are high (not good when handling a bomb). If you really want/need holonomic omnidirectionality and you want to use conventional tires, it’s the only way.

Please post a link to the definition referred to above.

Please provide a link to your paper, or post it here.

The best paper I’ve seen was by Wada and Morit, “Holonomic and Omnidirectional Vehicle with Conventional Tires” in 1996 IEEE Int. Conf on Robotics and Automation. Unfortunately, they didn’t provide the closed for solution for the inverse kinemtatics . However, figure 1 in the paper says it all. Just take a minute and look at it and it will explain why you will never, by definition, get holonomic omnidirectionality with a swerve.

I’ll dig up our work on OCILOW.

The word “swerve” appears nowhere in that paper. Please define what you mean by swerve in the context of your previous post (“swerve is by definition non holonomic”).

Swerve is what everyone is FIRST is calling the in-line orientable wheel, figure 1 a) in the paper.

“Swerve module” is the phrase most CD folks use to refer to an in-line orientable wheel like figure 1 a) in the paper.

“Swerve” usually refers to a vehicle using swerve modules in a particular way.

This is from page 3671 of the paper you linked:

In the past, four wheel steering vehicle[7] has been developed. The vehicle has steering wheels with conventional tires and can move in the omnidirection by orienting all wheels in the same direction

Is the above-quoted description your intended meaning of swerve in your earlier statement “swerve is by definition non holonomic”?

Or are you claiming that a swerve vehicle with four swerve modules – each of which can be steered and driven independently of the others – is “non holonomic” ?

Or did you mean something else entirely ?

My son Bryce, has dreamed of trying to implement what he refers to as “caster drive” for FRC for a couple of years now. It took me a bit of pondering to understand the differences.

It’s not that swerves can’t move in the same directions, but if you don’t want wiggling or squirming in unintentional directions at first, you really need to wait until the steering motors find their correct directions before powering the drive motors. In real use, the steering motors can get oriented up to the maximum required 90 degrees in less than 0.25 seconds, so we don’t actually wait. For an FRC weight robot running on carpet, it’s just not necessary.

The magic of the caster, is that by gradually mixing the steering rotation and the driving rotation into a cross blended function, you can achieve any motion direction instantly and with zero slip other than that due to the width of the tire. The tire will scrub only slightly due to differing path lengths for the inside and outside of the tire. Think of pushing a cart with 4 casters, not 2 like a shopping cart, you can make it move in precisely any direction with no wheel slippage, regardless of wheel direction. A powered robot is the same mechanically, except that the forces come from the wheels to move the cart, instead of the cart moving the wheels. The key is that any desired vector of motion can be expressed as the weighted sum of the two perpendicular directions created by the steering and drive wheel motors. The downside is that it takes a lot of simultaneous accurate control of both steering and driving motors. Is it worth it for FRC? I kind of doubt it, but I hope someone tries it in the off season some year, and decides to unveil it during build season anyway.

The 1996 paper referred to above has some nice drawings and graphs of the kinematic problem, which I’ve never seen before. Thanks for sharing.

“gradually mixing” and “instantly” seem like odd bedfellows in the same sentence.

Suppose I am driving your caster vehicle directly forward and I want to “instantly” go sideways? How is your caster vehicle superior to a properly designed and coded swerve?

Good summary Bob and you’re son is extremely bright. The controls actually are fairly easy. Tracking errors are stabilizing instead of destabilizing. e.g. if one of the casters is off, the reaction forces due to the other casters push it in the right direction. We implemented this on a large system for the Navy. It had a 10,000 lb payload capacity and could position loads with sub mm accuracy. When we first powered it up, we didn’t have the gains right on two of the drives. We drove it around for days and didn’t notice.

One of the items I loved about our drive train was the double enveloping worm gear. We do a lot of printing and I’ve debated about trying to print the OCILOW drive with a complex worm drive. We had some kids design and print an OCILOW out last year but they used chains for the drive.

The motion in the desired direction can begin instantly. However, after the steering has rotated a bit, the lateral motion of rotation changes and “gradual mixing” of driving motion with the steering motion is required.

Apparently less than 1/4 second. A swerve drive with no trail must first be steered to the proper direction before applying drive to achieve motion only in the desired direction. With trail (offset between the two axes), the steering motion itself begins the motion in the desired direction (along the drive wheel axis).

This is not a meaning of holonomic I have seen before - I suppose it would have to be “having the ability to immediately move in an arbitrary direction while in any arbitrary state”