Swerve Gear Box

[davidthefat]

Originally Posted by apalrd

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.

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

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

[Cuog]

Originally Posted by davidthefat

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

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?

[Ether]

Originally Posted by davidthefat

I thought that was obvious.

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

error = (desired input- current input)/desired input

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.

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

[davidthefat]

Originally Posted by Ether

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.

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.

[Andrew Schreiber]

Originally Posted by davidthefat

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.

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

[davidthefat]

Originally Posted by Andrew Schreiber

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

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

[Hawiian Cadder]

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.

[Aren Siekmeier]

Originally Posted by Hawiian Cadder

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.

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.

[Jared Russell]

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.