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.

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

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

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

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

[Andrew Schreiber]

Originally Posted by davidthefat

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.

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?

[apalrd]

Originally Posted by davidthefat

Yes it is, you are correct. It has to be between 1 and -1 or else the output would be too big.

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

[davidthefat]

Originally Posted by Andrew Schreiber

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?

It makes sense in my head, so did not think of it like that.

Originally Posted by apalrd

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

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.

[apalrd]

Originally Posted by davidthefat

It would not make much of a difference.

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.