Swerve Gear Box

[davidthefat]

Originally Posted by Joe G.

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. See Wildstang.

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

[Andrew Schreiber]

Originally Posted by davidthefat

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

Tell that to 111 and 71.

[Joe G.]

Originally Posted by davidthefat

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

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.

[davidthefat]

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?

[Joe G.]

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.

[davidthefat]

Originally Posted by Joe G.

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.

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.

[Joe G.]

Originally Posted by davidthefat

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.

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.

[Ether]

Originally Posted by davidthefat

Programming an intuitive [swerve] system is no problem.

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

[ratdude747]

Originally Posted by Ether

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

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.

[davidthefat]

Originally Posted by ratdude747

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.

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.

[lemiant]

Originally Posted by davidthefat

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.

You sound like all the people who say:

We will make our robot auto target stuff with the camera, its not that hard.

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.

[Ether]

Originally Posted by davidthefat

I see no problem with it ...

I still don't see how hard it can be...

Just check each wheel...

PID loops are not hard...

It is just all ratios...

it just sounds hard...

that is not all that difficult...

You talk a good game, David.

[Joe G.]

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.

[davidthefat]

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

[Andrew Schreiber]

Originally Posted by davidthefat

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

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.