pic: Differential Caster Drive: Does it get more ridiculous?

Yep. I think this is the craziest and most impractical drive idea I’ve ever CADed, but it would probably be a blast to build and test.

Tons of power availible
Truly holonomic motion
Big learning experience

Difficult to control

Questions and comments are always welcome.

Why does the wheel trail like that? Are you concerned with height or expect it to improve handling?

Wouldn’t this have to overcome an unreasonable amount of steering resistance?

That’s what “caster” refers to. A powered caster is billed as “fully holonomic” because it can begin moving in the desired direction no matter what state it is in (that is, what directions the wheels are oriented). This is because if the wheels are pointed perpendicularly to the desired direction of travel (at that point), you can begin moving in the desired direction as a byproduct of rotating about the thrust bearing.

Edit: found the link to the powered caster discussion. It was actually begun on the previous page, but here’s where it gets going.

Can you give us a more detailed explanation of what this is. I (and I’m assuming others too) am having a hard time seeing exactly how this works just from the renders. Maybe even some more screenshots/renders with color coding for a clearer view

I’m going to echo the question about the trailing wheel. What advantage do you see from not having the wheel under the center of rotation? Are you worried about the fact that if you turn all of the wheels in the same direction at once the whole chassis will move and the wheels will stay in the same place?

It looks and sounds similar to Brendan Simons’s recent differential swerve idea. Aside from the trailing wheel, what makes these different?

edit: sniped by Gus. I guess I understand the concept of powered casters, but I personally don’t think the benefit of slightly increased agility is worth the drawbacks of increased complexity and decreased fine positioning accuracy. A good driver shouldn’t need to make many sharp turns that would require waiting for wheels to align anyway (curves are your friend), but they probably will need to quickly make fine adjustments to align accurately with loading stations and/or shooting targets.

I agree that I don’t see enough benefit for the complexity. However, it occurs to me that this could be made simpler by taking Brendan Simon’s design and adding a couple of universal joints on the parallel shafts within the rotating part of the module. Of course, you would need to add some (probably static) elements to bear the vertical and transverse load from the wheel axle onto the rotating bearing plate. Adding such elements to Brandan’s would also be simpler and more robust than shaft constraints, for that matter.

What encoders are you using? VP integrated encoder?

The wheel is trailing to improve handeling ideally.

Wouldn’t this have to overcome an unreasonable amount of steering resistance?

There will definitely be extra resistance to the turning of the module compared to a standard swerve. However, this should not impede the motion of the drive because the wheel will not have to point in the desired direction in order to move in that direction.

That is the idea. To my knowledge, no one has built a powered caster drive for an FRC class robot yet, but I’ve been curious about how they would perform since sophomore year of high school.

This is a feature of the design and not a byproduct. However, its helpfulness has yet to be seen.

It looks and sounds similar to Brendan Simons’s recent differential swerve idea. Aside from the trailing wheel, what makes these different?

The primary differences are the caster of the module and the different gear ratios. This has a 50:1 gear ratio for turning the module that acts on a 3" radius, and a 25:1 gear ratio for driving the wheel that acts on a 1.5" radius. Both produce a roughly 10fps free speed that could easily be adjusted in the versa planetary gearboxes.

… I guess I understand the concept of powered casters, but I personally don’t think the benefit of slightly increased agility is worth the drawbacks of increased complexity and decreased fine positioning accuracy. A good driver shouldn’t need to make many sharp turns that would require waiting for wheels to align anyway (curves are your friend), but they probably will need to quickly make fine adjustments to align accurately with loading stations and/or shooting targets.
I think the advantages if a caster drive will shine brightest while making fine adjustments. Traditional swerve can have a hard time moving small distances quickly because when the driver first presses on the sticks, the response is both delayed and non linear depending on where the wheels were resting. When you first press the sticks in a caster drive, it should start moving in the desired direct much more immediately and have a more predictable response, even at low speeds.

I also agree that this drive train would not make sense in a build season setting. I’m not sure I follow your ideas involving a universal joints though.

Currently, the design has a single magnetic encoder measuring the angle of the module. VP encoders could easily be added though.

If you wanted to drive a module with force F (a fraction of 1.0) at angle theta from the direction the wheel is facing, the steering and power would be as follows.
Power = F * cos (theta)
Steering = F * sin (theta)
The math is relatively simple because the steering and dive apply force vectors that are orthogonal.

Not sure whether trailing the drive wheel is a good idea. It’s certainly going to increase the power you need to hold a heading under perturbations from other robots and the field.

I love the bevel gear arrangement though, it improves the steering ratio, and you’ve beat my record with four concentric shafts! :grinning:

The universal joints were on Brendan’s (nuclearnerd’s) design, so that his vertical shafts would be turned to an angle to meet the offset wheel. As I think even farther on it, if the caster offset were only about half the wheel radius, use of hypoid gears rather than conical would allow Brendan’s design to become a caster rather than a straight swerve.

At any given point for a single module, the problem does not look that difficult. However, when you realize that the contact patch of the wheel on carpet moves relative to the robot chassis, this makes the kinematics of caster drive significantly more complex than swerve. Also, because your wheels will be trailing the swivel if you start moving holonomically, you will usually be pushing in an unstable orientation.

Of course the steering resistance I’m referring to would be at a stand still. How do you get going in any direction other than the one the wheels are facing without first moving in that unwanted direction? And how do you do anything requiring the modules to point in different directions, or get out of such a situation?

I admit I haven’t read much of the caster drive discussion, but I don’t understand the advantage when the motive force is applied at the wheel, rather than at some point away from the caster (or just the caster pivot, i.e. external to the module).

The idea of a caster drive is that you never need to reorient the module in place before you start moving. If you coordinate the traction and pivot motors carefully, you can always apply instantaneous torque in any direction for each caster (in the local X direction with the traction wheel, and in the local Y direction by rotating the caster). A swerve can only apply torque in the current direction of the traction wheel.

If the modules are oriented forward and you want to translate to the left, a normal swerve needs to rotate the modules 90 degrees before it can apply torque in the desired direction (or you just accept a little bit of drift forward while the modules are reorienting). With a caster drive, the act of rotating the module itself applies a torque against the ground that moves the entire robot left.

The tricky part with a caster drive robot is that when doing a reversal (ex. forward to backwards), the wheel is now leading the caster instead of trailing it. This is inherently less stable (think of pushing a shopping cart) so you will want an algorithm to opportunistically do a 180 at appropriate times (as long as your pivot velocity is high enough, you can do this without affecting overall robot motion).

:bulb: Aha, the lights are on now. Thanks for the description. (And sorry that it was basically the first post that GeeTwo linked to, I’ve read the other thread and glanced through the papers now.)

Key here is the distinction between omni-directional and holonomic systems.

My one hang up is how the system doesn’t bind or require wheels to slide when modules are pointed different ways, but I’m beginning to see that there could be enough freedom for the wheels to track nicely out of that.

As for module reversal, it seems as long as the module orientation measurably deviates from 180 off of the desired heading (enough to result in a transverse wheel component to be supplied by module rotation), the reversal would be corrected in short order once you are traveling in the new direction. The module rotation component pushes the module back around to face the right way, while the wheel velocity starts in reverse, passes through zero while the module is perpendicular to the heading, and is running forward when steering stabilises. That is assuming (based on my previous point) that the modules have the freedom to steer through that way while the other modules are doing whatever they are doing. There are also constraints on vehicle speed while doing this, to make sure wheel speed can keep up with the steering component, at such extreme angles.

Imagine a cart with four unpowered casters. Manhandle the cart to go where you want it to go, and see how the wheels follow. Reverse.

Reversal of the casters once moving would require significant rotational speed and fair torque about the vertical axis. This increases the appeal of the differential caster drive over a more traditional caster drive - you don’t have to have that rotational power you need 5% of the time sitting (mostly) idle the other 95% of the time.

Thanks for the post. This is a great description of what’s supposed to be happening. I think that flipping around shouldn’t be a major issue if turning the module and driving the wheel have the same effective surface speed.

I think you can picture what would happen when the wheels are all facing random directions by imagining (or actually using) a cart with four unpowered casters. If you manually turn all the casters to random angles and then pushed the cart in any chosen direction. Would the wheels have to slip? As long as the caster can roll or rotate with a roughly equivent friction, then it should be able to move in any direction without considerably different resistance.

Yes, this is an important design consideration. Speed and torque should be roughly equal in both axes, which is why a (carefully geared) differential module is a great fit for a caster drive. In practice what this means is that you will almost never run the wheel in reverse. If you ignore acceleration limits, it only happens in theory in the perfect reversal case; if there is even a little bit of a horizontal component to the motion, the correct solution involves rotating the module such that the wheel trails. In practice, you will want to introduce an infinitesimal disturbance even in the perfect reversal case just to get your modules rotating (assuming you are translating more than a trivial amount).

Another benefit of this design is that the transmission to the offset wheel provides a natural axis about which to implement a spring-loaded suspension (as 2767 showed with their positraction, it is crucial that all wheels remain in static friction at all times for ideal control). If you can guarantee that your wheel is always sufficiently loaded, controlling this module is actually substantially simpler than controlling a swerve - you never need to scrub the wheel in place, so you are less sensitive to loading and wheel/field friction interactions. This setup is pretty straightforward to control using plain old PID (all the smarts go into the kinematics and setpoint generator to ensure none of your actuators get saturated).

Whenever the wheel direction reverses, there will be some reverse motion of the wheel in order to achieve the correct motion until the wheel again trails the pivot point. (Though perhaps Dave can ignore this short term issue and get away with a ratchet on the differential caster drive.)

Never say never. Drive due north. Stop. Drive due east. At least for a moment, you’re scrubbing all wheels in place. Less, but not never.

you appear to be using some definition of pretty straightforward I wasn’t previously familiar with. :]

Yes - sorry, I was referring to the steady state. You don’t want to drive the wheel in reverse except to cancel out the undesired components of motion when rotating the module. Unlike swerve where sometimes the common “shortest path” module rotation algorithm means driving your wheel in reverse indefinitely until you change direction.

Technically all wheels that aren’t point contacts scrub a bit whenever there is any curvature to their path, but in this case “scrub in place” only occurs in one instant when the module is exactly normal to the desired orientation, as opposed to continuously in the standard swerve case.

Armed with a couple of Talons, the control part of this is not hard to tune - especially if the robot is a tripod or the module has a little bit of a suspension. The inner PID loops are pretty well behaved because both axes of motion present similar loads to the motors during operation. It is no different than controlling a 2 wheel drive robot simultaneously in both linear and angular velocity, and in the case of a carefully-geared caster drive that never loses traction, the inertia presented to the motors by each axis is roughly equal.

Coming up with the right setpoints so as not to saturate any actuators and handle well is a separate issue :slight_smile:

get rekt.