Swerve Gear Box

[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

[Aren_Hill]

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

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

[apalrd]

Originally Posted by ratdude747

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

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.

[AdamHeard]

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

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.

[Andrew Schreiber]

Originally Posted by AdamHeard

Most other statements in this thread are pure speculation.

You mean like this statement you just made?

[AdamHeard]

Originally Posted by Andrew Schreiber

You mean like this statement you just made?

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?

[Andrew Schreiber]

Originally Posted by AdamHeard

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.

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.

[PAR_WIG1350]

Originally Posted by AdamHeard

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.

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.

[AdamHeard]

Originally Posted by PAR_WIG1350

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.

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.

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