Swerve Gear Box
 

If your team has made a swerve drive system in the past, did you use helical, bevel or worm gears to drive the wheel? Why did you come to that decision and how has it worked out for you?

Re: Swerve Gear Box
 

I haven't made a swerve drive, but you missed a pretty big option. Containing the motor within the swerve module drastically simplifies the gearing. Definitely something to consider. See Wildstang.

Of teams who do go with a coaxial approach, the vast majority use bevel gears. I'll let people with more experience than me post reasons.

Re: Swerve Gear Box
 

Wouldn't that require more torque to rotate the gearbox because adding a motor onto the gearbox makes it much more massive.

Re: Swerve Gear Box
 

Tell that to 111 and 71.

Re: Swerve Gear Box
 

Module rotational inertia is pretty trivial compared to frictional resistance to rotation. The larger disadvantages of the self-contained approach include physical size, difficulty in adding shifting capabilities if they are desired, and limits to the module's rotation generated by the motor's wires. But none of these come close to making this design unworkable, and they've been used on many fantastic swerve designs, as Andrew mentioned.

Re: Swerve Gear Box
 

Well, it seems like from looking through CD Media that most of the teams used bevel gears as opposed to helical or worm gears. Mechanically, it seems simple to produce. Is it harder than it looks to physically make? Programming an intuitive system is no problem. What was the biggest issues in controlling swerve for teams?

Re: Swerve Gear Box
 

Bevel gears require extreme precision in three dimensions. Both the top and side must be precisely machined, and you must have some way to precisely locate the bevel gears on the shaft. Definitely a job for machine tools. As a mental exercise, picture the number of ways a bevel gear's alignment can be "off," versus spur gear alignment.

Selection of bevel gears is another hurdle. Choosing an appropriate pitch, pressure angle, size, etc. is critical for good performance. Again, I'll let those with experience with these things elaborate further.

And even if you get it all right, bevel gears still create a noticeable drop in efficiency when compared to spur gears. Another argument for the self-contained approach.

Re: Swerve Gear Box
 

From what I have read, helical gears are more efficient than bevel gears, that is why they are using in car transmissions. But they do cost more than bevel gears.

Re: Swerve Gear Box
 

It's really really simple, unless you actually do it.

Re: Swerve Gear Box
 

Helical gears are very efficient when used in a "straight" configuration, as spur gear substitutes. But when used as a crossed set, their efficiency drops dramatically, as low as 50%

Additionally, the primary reason for using helical gears in a car is their noise level. Helical gears have quite similar efficiencies to spur gears, but run much quieter, due to the more gradual engagement of the teeth.

Re: Swerve Gear Box
 

especially if it is "unicorn drive". it can be made to work but trust me, it involves a LOT of code. (you would know...)

perhaps the worst part for ANY swerve is deciding how you want it to drive...

hence why I am more of a fan of mecanum than swerve for competition bots that strafe... if I am going to write a lot of code, I'd rather it be on my manipulator/camera tracking than on my drive code. that is, unless you pull a 148 and have crab and no manipulator (tumbleweed, 2008), which in that situation was nothing but epic...

for off season/fun, any swerve can be fun... or not fun... it depends on how you go about it.

Re: Swerve Gear Box
 

Well, I see no problem with it because it's the off season. I am not constraint for time. Also, I still don't see how hard it can be. Just check each wheel if their velocity is within tolerance, if all the wheels are rotated with in the right tolerance and if they are not, make them.

PID loops are not hard. It is just all ratios, it just sounds hard. Sure, it is a lot of code, but it does not make it any harder. The hardest thing might just be incorporating a gyro scope, but that is not all that difficult unless there is a lot of inaccuracies in the readings.

Re: Swerve Gear Box
 

You sound like all the people who say:
It doesn't seem hard, but it is. You can do it with enough time dedication and skill, but that doesn't stop it from being hard.

Re: Swerve Gear Box
 

You talk a good game, David.

Re: Swerve Gear Box
 

When designing something complex, it is very important to have faith that you can do it.

However, do not confuse faith in your ability to overcome challenging obstacles, with the difficulty of the obstacles themselves.

Believe that you can do it, but believe that it will be hard, take a while, and throw unexpected challenges at you every step of the way.

Re: Swerve Gear Box
 

P= Error*Pconstant
I=((Previous Error*change in time + Error*change in time)/2)* Iconstant
D=((Error-PreviousError)/change in time)* Dconstant

output = P+I+D + 127

60 < Pconstant < 95
5 < Iconstant < 25
0 < Dconstant < 5

The time can be obtained from the FPGA

Re: Swerve Gear Box
 

Properly set up bevel gears shouldn't be behind spur gears at all in terms of efficiency.

Re: Swerve Gear Box
 

Believe me when I say that this is the easy part of a PID. I'm sure Ether knows better than I but my experience has always been contrary to GI Joe's claim that knowing is half the battle. Knowing is maybe 10% of the battle. 10% is actually writing the code. and 80% is a mix of debugging and ripping your hair out. There may be some crying/cursing mixed into the last section depending on how you react.

Re: Swerve Gear Box
 

I will disagree with you on this one.

Our 2011 robot has about as much code running the drivetrain as it does running the elevator/claw system as a whole (minibot is separate, and much smaller).

Why?

Closed-loop drive control has a few blocks to it, logic to coast out stops, logic to hold position, gain scheduling based on shift state, etc.

Autoshifting has a block to it, its a lot of tuned logic operations.

Lift piston management has a few blocks, to lift the rear wheels when turning, and another one to lift the inner one in an arc.

HMI has a bunch of blocks, for arc management, speed derating at high elevator positions, drive line inversion, and such.

The elevator and wrist, on the other hand, has:

A really big state machine that actually runs the elevator
A reality check that prevents driving through the elevator with the wrist (or the wrist with the elevator), some of the going backwards logic.
A P controller with gain scheduling
An anti-stall-death algorithm

What I'm saying is that the little code things you write to optimize performance in the drivetrain add up to the one really big state machine plus a few other blocks you write for the mechanism. For us, the optimization effort is worth it, I guess that depends on your teams coding resources.

Re: Swerve Gear Box
 

My first question to you is what machining capabilities do you and your team have? You'll need someone experienced in machining to thousandths of an inch accuracy. And preferably someone who has experience working with gears. I can tell you it will take an incredible amount of talent to make a working swerve module with a drill press and a hacksaw.

Second PID loops are great and all, but there's a lot more to it than that. To make an intuitive setup you'll need to figure out exactly what way you want to map user input to outputs. There are about 10 ways to do it that will work, but a lot fewer that are considered good. Again you'll need to scale these inputs usefully.

My first time programming a omni directional drive it was very easy. It took only 3 lines of code(4 omni wheels at 90 degrees from one another). And yeah it worked first go kudos to me. Then one of the drivers said what happens when we turn, tapped the joystick full left for a second and the robot spun in place at 14 feet per second with its arm sticking out 4 feet almost hitting several people. Ok that's easy to fix, just tone down the spin modifier. That worked to keep it from being a death trap, but then thanks to slowing its turn, getting a smooth strafe/twist couldn't happen over a certain speed because the twist modifier couldn't twist enough.

In the end my pretty little 3 lines of code which worked turned into a pretty large function to control the omni bot properly. And I didn't even use PID, not to mention there's a little bit more to keep track of in a swerve drive.

I'm sure you're thinking pfft that's nothing, I got this. You probably will get it eventually, but keep in mind the sheer number of stumbling points waiting for you, and if you attack it with the same arrogance I read in your posts, you'll lose a lot of the people whose help you will need to complete the project.

Re: Swerve Gear Box
 

I'll say this: 90% of all our code was probably put into the drive; my mentor said that this year's robot was probably the smoothest driving robot our team has made. That says something about really putting effort into it. I admit, the code for rest of the robot was pretty much chopped together in an hour. The drive took weeks of optimization and yet I was still not able to optimize it to the best I can because a lot of my time went into testing sensors and stuff like that.


I have everything in my head. Yes I am arrogant, but from years of just living, I noticed that people tend to talk things up. Like how calculus is "so hard" or how physics was such a hard class. It usually ends up not as hard as they say it is. Like what you went through omni. I went through the same thing (it was the first system I was assigned to code), but I find those as minor discomforts. I do see what you are saying, but those are expected.

Well, I am saying that I am not scared of 30 file projects with thousands of lines of code. I actually like doing that; that is the whole fun of coding. It is those times that I feel like quitting and bashing my head on the wall that really satisfies me. It's because you really have to experience suffering before you know what joy really is like. I like tackling big projects head on.

As far as machining capabilities go, I can probably call somebody up to help make it and teach the team.

Re: Swerve Gear Box
 

I got a chuckle out of that. Thanks :-)

Re: Swerve Gear Box
 

Not sure what point you were trying to make with the above.

But I did notice you left out how you plan to calculate "error".

Re: Swerve Gear Box
 

I thought that was obvious. error = (desired input- current input)/desired input

Re: Swerve Gear Box
 

That is percent error unless I am having one of my moments...

Re: Swerve Gear Box
 

Yes it is, you are correct. It has to be between 1 and -1 or else the output would be too big. I actually I noticed an error, it's desired-current. not the other way around.

Re: Swerve Gear Box
 

Which... is obviously not so obvious... And are you seeing the point that what looks simple (calculate error) is usually a little more difficult than first glance?

Re: Swerve Gear Box
 

Not true. You could just scale down the P,I,and D gains to make it work.

Re: Swerve Gear Box
 

It makes sense in my head, so did not think of it like that.
Well, I want this to be a versatile as possible. For example, the input can be a rate, for rotation of the wheels, or it can be angle of the arm. Both use motors, but you are right. It would not make much of a difference.

Re: Swerve Gear Box
 

It makes a big difference.

Say I have a mechanism, and want to go to 50 units. I am currently at 30 units. The formula you gave would output error as (50-30)/50 = 20/50 = 0.4

Now say I want to go back to 30 units, from the 50 units I was just at. The formula you gave would now give me (30-50)/30 = -20/30 = -0.6667. Not the inverse of what we just saw, this is very different.


As for versatility, the P, I and D parameters should be expected to be tuned to fit a particular system. Thinking that scaling the input will make these magically work for everything is just wrong.

As for input of rate vs distance, an input of rate requires integrating the output of the PID controller so that the output drives the change in motor power. The alternative is to use the I term as the P term (with other terms changing positions and such) or use a feed-forward plus a PID (with the I term still doing a lot of work). Thus, any sort of interchangeability between inputs of rate and distance goes out the window.

Re: Swerve Gear Box
 

I also did not realize the fact that if the desired output is smaller than current position. I am at 150 and I want 50. 100/50 = 2... Okay, I see...

Re: Swerve Gear Box
 

This is actually pretty false. The code for a "unicorn drive" (darn JVN for coming up with such a silly name) is actually substantially shorter than most other crab codes. The initial derivation is hard, but once it's done the code is very short, and one function works for ALL cases of input (there is no translation mode, steering mode, etc... Just one mode). The error calculation for going over zero is only trivially harder than normal error calculation, and many teams decide to never reverse module drive direction for mechanical reasons so that function is a nonissue.

Also, you could just take the lazy way and copy the functions Ether posted.

We converted our 2008 crab prototype to an independent drive and steer crab, it runs, and the code is short. Most other statements in this thread are pure speculation.

Re: Swerve Gear Box
 

You mean like this statement you just made?

Re: Swerve Gear Box
 

We made one and got it running in both configurations. I don't see how my statement about the length of the code we wrote for our "unicorn" crab is simpler than the code for our "2+2" (drive and steer pairs) crab is speculation...

My statement wasn't meant to be a personal attack, I just think it's invalid to say I prefer x to y when you've only done x. This isn't quite a black and white area though.

EDIT: Gotcha, you mean my speculation about speculation. Most was probably a strong word to choose. Some, is that more accurate? ;)

Re: Swerve Gear Box
 

I was saying that it was speculation that other people's statements were speculation. I can assure that every single statement I have posted is based on my experience or on various studies I have read for my classes or for my job. If you think someone's statement is wrong you should probably ask them for clarification rather than making broad comments that call into question every other post in the thread.

I actually completely agree that Unicorn is simpler than 2+2 to program (I'm not as qualified to comment on building them outside of vex/lego scale so I will defer to those who have experience there).

Edit: I do hate the phrase "speculation that it is speculation" sounds almost xzibit-ish.

Re: Swerve Gear Box
 

So in other words you don't have any. I think that you are attempting to take on a project that is beyond the scope of what you're setup to handle. Based on your other threads I also have to ask is this a personal project or a team project? If its a team project, have you unilaterally decided that this is what the team will be doing, or have you actually discussed the project with the team to decide if its something everyone else wants to work on as well?

Re: Swerve Gear Box
 

Hopefully the several ensuing responses from various posters have given you pause.

So if you're using PID for steering angle, and the process variable is 2 degrees, and you want the setpoint to be 359 degrees, then you would calculate an error of 359-2= 357 degrees and feed that error to your PID?

Think about it.

Re: Swerve Gear Box
 

The initial derivation does indeed give you one equation, but that one equation has a lot of variables. The number of variables is so large it would be difficult to manipulate them all for the entirety of the match without really good (expensive) joysticks, and even then, it is sometimes just easier to have constants that can be used in place of certain variables. this also has the potential advantage of making the robot respond faster for two reasons. By pre-calculating certain parts of the equation, the code can execute faster, and, since certain values plugged in for some variables can result in the angle output for some modules return the same value despite the other inputs changing, by adding modes to set the values so that this is the case, mechanical reaction time improves at the cost of reduced maneuverability.

I hope that makes sense, If unicorn drive were Moby Dick, I fear I would have to be Captain Ahab, I hope I haven't reached the rambling stage yet.

Re: Swerve Gear Box
 

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.

Re: Swerve Gear Box
 

Well, it would still work regardless since I am checking and regulating the output to be a legit one that is not out of range. 359 - 2 = 357; 357/359; 0.994428969; 0.994428969 * 95 = 94.4707521; 0.994428969 *25 = 24.8607242; 0.994428969 *5 = 4.97214484

94.4707521 + 24.8607242 + 4.97214484 = 124.303621 (truncated = 124)

If that was the opposite and we were at 359 and wanted 2 it would be trouble.

-357/2 = -178.5 (that is -178.5 PERCENT, which is a big no no.)
We can deal with it this way: just regulate the error percent to be -1.0 to 1.0 or regulate the output at the end. It would both deal with that problem.
Yes my method does favor the going from a low to high than high to low.
You can say that it is an error on my part, but that is the beauty of engineering; you rarely get it right the first time.

Also I can just do higher # - lower # then divide by the higher # to always give -1 to 1. Then just put the desired input- current input as a variable and just mask out and & the number to get the + or -. I'll clarify in teh morning. I sound like gibberish at night.

Re: Swerve Gear Box
 

Which is why we said that it isn't simple...

Re: Swerve Gear Box
 

Okay, I didn't mean walk in the park easy. It is a hike on a hill easy.

Re: Swerve Gear Box
 

Correct me if I am wrong, but weren't slip rings legal this year? I thought I read something about using them on CD, I don't recall what the GDC decision was.

Re: Swerve Gear Box
 

Yes, one of the early updates allowed slip rings and other similar devices as connections (not just wires) as long as they were rated for the current you were putting through them.

They were legal up until 2010 (mostly because no one ever said anything about them, I think), and then in 2010 the wiring rules were written more specifically and the GDC "accidentally" (is the thought) disallowed them in the wording. In the 2010 Q&A they stuck with the wording, but since then they've obviously decided that they're intent is otherwise.

Re: Swerve Gear Box
 

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.

Re: Swerve Gear Box
 

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.

Re: Swerve Gear Box
 

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

Re: Swerve Gear Box
 

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.

Re: Swerve Gear Box
 

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

Re: Swerve Gear Box
 

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

Re: Swerve Gear Box
 

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.

Re: Swerve Gear Box
 

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.

Re: Swerve Gear Box
 

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

Re: Swerve Gear Box
 

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

Re: Swerve Gear Box
 

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

Re: Swerve Gear Box
 

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

Re: Swerve Gear Box
 

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.

Re: Swerve Gear Box
 

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.

Re: Swerve Gear Box
 

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.

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.

Re: Swerve Gear Box
 

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

Re: Swerve Gear Box
 

That's why I said variables, not degrees of freedom. Also, my original point was that this method works best with different modes that emulate different steering setups so that the driver does only deal with three variables at a time. However my preferred three variables are speed, direction, and radius rather than X, Y, and spin because when I move I am not analyzing my X and Y translation and my rate of rotation. My theory is that by having the code work with the way the human brain does, then the driver can more easily develop his or her skill to the point at which movement of the machine is unconscious and automatic. This is a topic that could be debated ad nauseuam without any thing being agreed upon, as is the case when one starts talking about how the brain works, as such, let's not.

Re: Swerve Gear Box
 

You've hit it right on the nose. Driving needs to be intuitive and natural. For some, this means vx, vy, and omega, for others, what you've described, and even more, which is why it is very useful to be able to handle several different modes so the driver him/herself can explore what works best. It can even be game specific.

I would argue, however, that the control algorithms work best when fed vx, vy, and omega, since these are exactly the time derivatives of the three degrees of freedom of a solid body in two dimensional space, and can therefore describe any and all motion (using very simple kinematics). Then you just need to be able to convert whatever inputs from the driver to these parameters (also using simple kinematics). And vectors make all the math much, much happier.

Re: Swerve Gear Box
 

Exactly.

Exactly!