Swerve Gear Box

[DavidGitz]

Originally Posted by Jared341

Slip rings that are rated for the sort of current that an FRC drive module draws are not commercially available within FRC cost limits, and I shudder to think of a home-made slip ring drawing 100+ amps.

This is a legitimate concern, although someome may find a solution. However, is it possible to design a module using a slip-ring that has the steering motor as the part that is rotating inside the module instead of the drive motor? I.e., if it is possible and assuming the steering motor requires a much lower current draw (I've seen 12V 20A slip-rings before in our price range and I'm sure the vendor had higher current ratings) this would work fine.

Probably not physically possible, but I can't say it isn't.

[Hawiian Cadder]

Originally Posted by DavidGitz

This is a legitimate concern, although someome may find a solution. However, is it possible to design a module using a slip-ring that has the steering motor as the part that is rotating inside the module instead of the drive motor? I.e., if it is possible and assuming the steering motor requires a much lower current draw (I've seen 12V 20A slip-rings before in our price range and I'm sure the vendor had higher current ratings) this would work fine.

Probably not physically possible, but I can't say it isn't.

AndyMark or IFI should make one, it would sure simplify the task of making a swerve drive.

[Cuog]

A less sophisticated version would be to use two attached wires similar to speaker wire in the appropriate gauge. Run it down through the center of rotation, you could then experimentally determine how much slack you'd need in the wire and how many twists you could handle before damaging the wire.

I know when I build tube amps I do something like this with the AC heaters and I'm able to get a good 10-20 tight twists in a 6 inch length. Using a little bit of clever coding you can ensure that your robot wont exceed so many twists in one direction.

Certainly not as elegant as a slip ring, but quite effective within the rules as I understand them.

[Ether]

Originally Posted by Cuog

Using a little bit of clever coding you can ensure that your robot wont exceed so many twists in one direction.

It would be interesting to hear some detail from those who have either done this successfully or have studied the problem in some depth and have developed what they consider to be robust effective solutions, to see how many different approaches have been considered.

Same comment for limited-range steering (ie less than 360 degrees).

[Andrew Schreiber]

Originally Posted by Hawiian Cadder

AndyMark or IFI should make one, it would sure simplify the task of making a swerve drive.

I'm just gonna leave http://www.andymark.com/product-p/am-0760.htm here.

[Cuog]

Originally Posted by Ether

It would be interesting to hear some detail from those who have either done this successfully or have studied the problem in some depth and have developed what they consider to be robust effective solutions, to see how many different approaches have been considered.

Same comment for limited-range steering (ie less than 360 degrees).

I'd also be interested to hear if any teams know how many revolutions they make in an average match. I'm thinking it can't be more than a dozen in one direction, but having never used a swerve I can't say for sure. It works perfect in my mind, but reality has a way of making fools of us all.

[PAR_WIG1350]

Originally Posted by AdamHeard

The code just takes three inputs, X translation, Y translation, and rotation rate. The code outputs the proper wheel angles and speeds for all cases with <20 lines of calculations, very simple ones at that. The cRIO handles it with no problem.

This is very intuitive to control, one stick translates (move that way, it goes that way), and another is your rotation (move this and it rotates (in addition to the translation)).

Check Ether's uploads for his equations, you'll see it's almost a trivial problem at that point.

That would not be unicorn drive. You can also control center of rotation in a unicorn drive which adds 2 more variables. These would be the two that you would preset to make driving easier, otherwise, in the most intuitive drive interfaces, center of rotation would be controlled by a second joystick, alternatively, you could use polar coordinates and one joystick. In this setup the x and y axes give you translation angle and velocity while the z-rotational (twist) axis controls turning radius and the z-axis (throttle) controls the front to back variation of the center of rotation.

[AdamHeard]

Originally Posted by PAR_WIG1350

That would not be unicorn drive. You can also control center of rotation in a unicorn drive which adds 2 more variables. These would be the two that you would preset to make driving easier, otherwise, in the most intuitive drive interfaces, center of rotation would be controlled by a second joystick, alternatively, you could use polar coordinates and one joystick. In this setup the x and y axes give you translation angle and velocity while the z-rotational (twist) axis controls turning radius and the z-axis (throttle) controls the front to back variation of the center of rotation.

I think you're a bit off here, the center of rotation is an arbitrary point the robot is instantaneously rotating around based on the combination of translation and rotation inputs. The code takes the translation and rotation inputs and figures out what arbitrary arc the robot is driving upon at that second, and then finds the resultant wheel angles and speeds to travel along that arc. No matter what, the vehicle is driving along some arc instantaneously, and it's defined by three things, not five (it would be overdefined).

this is incredibly intuitive; move that way that fast, and spin this way this fast. I don't understand how this isn't "unicorn drive".

[Cuog]

Originally Posted by AdamHeard

I think you're a bit off here, the center of rotation is an arbitrary point the robot is instantaneously rotating around based on the combination of translation and rotation inputs. The code takes the translation and rotation inputs and figures out what arbitrary arc the robot is driving upon at that second, and then finds the resultant wheel angles and speeds to travel along that arc. No matter what, the vehicle is driving along some arc instantaneously, and it's defined by three things, not five (it would be overdefined).

this is incredibly intuitive; move that way that fast, and spin this way this fast. I don't understand how this isn't "unicorn drive".

Perhaps I'm just silly, but I think this debate could use some citations. I'm now thoroughly confused on the subject.

[AdamHeard]

Originally Posted by Cuog

Perhaps I'm just silly, but I think this debate could use some citations. I'm now thoroughly confused on the subject.

I really wouldn't be a great person to cite citations, as I just did the derivation and calculations from what I've learned in my dynamics classes. For the result of the derivation what Ether posted in his uploads matches mine exactly (or mine matches his, his was posted far before I ever did mine), which was a relief).

That doesn't have any proof in it really, it's just working code that takes the translation and rotation inputs and generates the 8 outputs (angles/speeds). Working code is a darn good argument in my opinion though (and in our case, working code on a robot).

[artdutra04]

Originally Posted by PAR_WIG1350

That would not be unicorn drive. You can also control center of rotation in a unicorn drive which adds 2 more variables. These would be the two that you would preset to make driving easier, otherwise, in the most intuitive drive interfaces, center of rotation would be controlled by a second joystick, alternatively, you could use polar coordinates and one joystick. In this setup the x and y axes give you translation angle and velocity while the z-rotational (twist) axis controls turning radius and the z-axis (throttle) controls the front to back variation of the center of rotation.

Originally Posted by AdamHeard

I think you're a bit off here, the center of rotation is an arbitrary point the robot is instantaneously rotating around based on the combination of translation and rotation inputs. The code takes the translation and rotation inputs and figures out what arbitrary arc the robot is driving upon at that second, and then finds the resultant wheel angles and speeds to travel along that arc. No matter what, the vehicle is driving along some arc instantaneously, and it's defined by three things, not five (it would be overdefined).

this is incredibly intuitive; move that way that fast, and spin this way this fast. I don't understand how this isn't "unicorn drive".

These are both different methods for controlling a "unicorn" drive, with the prior being better for autonomous path planning and the latter being easier for human control. For the prior, there are simply too many inputs for a person to feasibly and intuitively control, but this method (rotation around any arbitrary instantaneous center) is best suited for advanced path planning/navigation. For example, if you wanted to autonomously drive a robot along lines, arcs, or splines while rotating the drive base, the first one would be the chosen control scheme. For this drive mode, everything is broken down into driving straight, driving in arcs, driving along splines, etc and the control inputs are based upon the desired states of these actions.

The latter scheme, as Adam pointed out, is similar the prior, but much simpler (less inputs, less inverse kinematics). This makes it easier for someone to control it, but with has "less control" over the outputs of the system. However, this can be overcome by "transferring" some of the complicated "inverse kinematics" back to the human driver: by training, the human driver could learn to control the three inputs they are given in this scheme to produce very similar results to the above control scheme (e.g. the driver could drive in an arc/spline while rotating by learning how to perfectly alter and coordinate the X-Y vector and Z-rotation joysticks).

[AdamHeard]

Originally Posted by artdutra04

These are both different methods for controlling a "unicorn" drive, with the prior being better for autonomous path planning and the latter being easier for human control. For the prior, there are simply too many inputs for a person to feasibly and intuitively control, but this method (rotation around any arbitrary instantaneous center) is best suited for advanced path planning/navigation. For example, if you wanted to autonomously drive a robot along lines, arcs, or splines while rotating the drive base, the first one would be the chosen control scheme. For this drive mode, everything is broken down into driving straight, driving in arcs, driving along splines, etc and the control inputs are based upon the desired states of these actions.

The latter scheme, as Adam pointed out, is similar the prior, but much simpler (less inputs, less inverse kinematics). This makes it easier for someone to control it, but with has "less control" over the outputs of the system. However, this can be overcome by "transferring" some of the complicated "inverse kinematics" back to the human driver: by training, the human driver could learn to control the three inputs they are given in this scheme to produce very similar results to the above control scheme (e.g. the driver could drive in an arc/spline while rotating by learning how to perfectly alter and coordinate the X-Y vector and Z-rotation joysticks).

I really don't view the method with three inputs as being too difficult to control, for the general case of FRC driving (all situations covered by one set of controls) it's a better match. It also is a 1:1 match to the style of controls students are all familiar with from exposure to video games.

I guess what is better for human control is more a matter of opinion than anything.

[artdutra04]

Originally Posted by AdamHeard

I really don't view the method with three inputs as being too difficult to control, for the general case of FRC driving (all situations covered by one set of controls) it's a better match.

Neither do I, it's what we used on our 2010 robot. It was great.

In hindsight the wording I used in my last post might have been confusing, but by "prior" I meant what PAR_WIG1350 posted and by "latter" what you posted.

[Ether]

Originally Posted by PAR_WIG1350

That would not be unicorn drive.

Yes, it would. A Unicorn drive has exactly 3 degrees of freedom: two translational and one rotational. Typically, these 3 motions are all specified with respect to the same reference point on the vehicle, usually the center of geometry of the wheel pattern.

Any desired motion of the vehicle, including making the vehicle revolve around an arbitrary external point while simultaneously rotating about its own center of geometry, can be commanded by specifying the (time varying) values of the above mentioned 3 degrees of freedom.

One example is given here, which shows how to convert an Ackermann steering command into the 3 degrees of freedom.

You can also control center of rotation in a unicorn drive which adds 2 more variables.

The phrase "adds 2 more variables" should not be interpreted to mean "adds 2 more degrees of freedom". There are only 3 degrees of freedom.

Specifying an external point around which you want the vehicle center-of-geometry to instantaneously be revolving is simply a different way to specify the vehicle's instantaneous 2D translational motion. The interface presented to the driver should be as intuitive as possible for the types of vehicle motions the driver wants the vehicle to perform.

[Ether]

Originally Posted by Ether

Any desired motion of the vehicle, including making the vehicle revolve around an arbitrary external point while simultaneously rotating about its own center of geometry, can be commanded by specifying the (time varying) values of the above mentioned 3 degrees of freedom.

One example is given here, which shows how to convert an Ackermann steering command into the 3 degrees of freedom

Just posted 3 more examples here (scroll to the bottom of the list of attachments).