Swerve Gear Box

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

[Cuog]

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.

[davidthefat]

Originally Posted by apalrd

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.

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.

Originally Posted by Cuog

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.

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.

[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 Andrew Schreiber

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.

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

[Ether]

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

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

[davidthefat]

Originally Posted by Ether

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

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

[Andrew Schreiber]

Originally Posted by davidthefat

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

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

[davidthefat]

Originally Posted by Andrew Schreiber

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

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.