Swerve vs. Mecanum Programming

[kgzak]

Originally Posted by Ether

Here are two simple algorithms:

2 JOYSTICK TANK DRIVE MECANUM SEPARATION OF VARIABLES
http://www.chiefdelphi.com/forums/sh...94&postcount=1

3-AXIS JOYSTICK MECANUM ALGORITHM
http://www.chiefdelphi.com/forums/sh...383#post916383

The above algorithms are not optimum, but they work.

~

I want to be able to go any direction with mecanum wheels not just forward backward and strafe. I have seen it done before and want to use that to create a field oriented drive so I press the joystick in any direction and it moves in that direction.

[Ether]

Originally Posted by kgzak

I want to be able to go any direction with mecanum wheels not just forward backward and strafe.

The algorithms in both links allow all 3 degrees of freedom: forward/reverse, stafe left/right, and rotate clockwise/counterclockwise.

Originally Posted by kgzak

I want to use that to create a field oriented drive so I press the joystick in any direction and it moves in that direction.

The 3-axis joystick algorithm can be made field-oriented simply by doing a coordinate axis rotation of the X,Y joystick values before feeding them to the algorithm.

x' = xcos(theta) - ysin(theta)

y' = xsin(theta) + ycos(theta)

... but Buchanan's approach is technically more correct and will yield more optimal control (more accurate directional control, smoother operation, and less scrubbing of the wheels)


~

[kgzak]

Originally Posted by Ether

The algorithms in both links allow all 3 degrees of freedom: forward/reverse, stafe left/right, and rotate clockwise/counterclockwise.



The 3-axis joystick algorithm can be made field-oriented simply by doing a coordinate axis rotation of the X,Y joystick values before feeding them to the algorithm.

x' = xcos(theta) - ysin(theta)

y' = xsin(theta) + ycos(theta)

... but Buchanan's approach is technically more correct and will yield more optimal control (more accurate directional control, smoother operation, and less scrubbing of the wheels)


~

Thanks. That'll help. I think I have it figured out. Now if only our coach will do off season stuff

[buildmaster5000]

AM has a great powerpoint about omnidirectional drive, which has several diagrams that may make seeing the vectors talked about above easier to see.

http://www.andymark.biz/presentations.html

Also, if you use a gamepad or similar control device, using the left joystick to control the movement of the actual robot and using the right joystick x axis to rotate the robot, it makes it very easy for someone who has played Halo to figure out how to drive your robot.

[kgzak]

Originally Posted by buildmaster5000

Also, if you use a gamepad or similar control device, using the left joystick to control the movement of the actual robot and using the right joystick x axis to rotate the robot, it makes it very easy for someone who has played Halo to figure out how to drive your robot.

I was thinking that and since I am not only the programer, I am the driver I can basically make any driver station I want.

[buildmaster5000]

Originally Posted by kgzak

I was thinking that and since I am not only the programer, I am the driver I can basically make any driver station I want.

Then use whatever works for you. We need to get a gamepad to work with Java before we start to tackle programming a swerve...

[tanguma26]

Hey we are team 647 and we are trying to develop our own swerve drive and I was wondering if you can post some examples of your program we are having some troble with our program and we are using Lab View.

Thank You

[kgzak]

Originally Posted by tanguma26

Hey we are team 647 and we are trying to develop our own swerve drive and I was wondering if you can post some examples of your program we are having some troble with our program and we are using Lab View.

Thank You

I can post some examples. I will post them later right now I am at my friends house and don't have the ability to do so.

Baisically what my code does is it compares two numbers and if the pos_in(position the feedback tells you you are in) is greater than pos_to(Position to go to) then it sets the speed to -1 and 1 if it is the other way around. I also have a lot of safeties built in such as: If the feedback isn't counting, if it is turning the wrong way, etc. You may have a few questions because I really haven't commented any of it and it even confused my dad at first, so I will be willing to answer any other questions you have.

[apalrd]

Originally Posted by kgzak

I can post some examples. I will post them later right now I am at my friends house and don't have the ability to do so.

Baisically what my code does is it compares two numbers and if the pos_in(position the feedback tells you you are in) is greater than pos_to(Position to go to) then it sets the speed to -1 and 1 if it is the other way around. I also have a lot of safeties built in such as: If the feedback isn't counting, if it is turning the wrong way, etc. You may have a few questions because I really haven't commented any of it and it even confused my dad at first, so I will be willing to answer any other questions you have.

a simpler way to do this exists.
it's called proportional control. p from pid.

Basically, you say;

error = setpoint - process_variable
output = error * Kp

And Kp (gain) is constant. Nice and easy. You should only need a safety at the left/right boundaries to cut off the output when it gets out of range, and possibly some functions to invert motor and rotate inverse. You tune the gain so that it goes as fast as it can without oscillating.

Edit: Forgot to talk about I and D:
Integral (I):
Basically you integrate the error and add it to the output:

integral += error
output += integral * kI

Ki is Integral Gain. You also need to reset integral to prevent integral windup. Generally you do not need to implement I unless you cannot get enough accuracy with P alone.

Derivative (D):
You calculate the derivative of the previous action to determine how momentum will affect the stopping ability. Basically, it works against P and I to slow it down when it nears the end, allowing a higher P gain. You will almost certainly not need this with crab steering, as the friction of turning the pods will probably slow their rotation very quickly (D would be useful for, say, a 6' arm that has a lot of mass at the end).

[kgzak]

Originally Posted by apalrd

a simpler way to do this exists.
it's called proportional control. p from pid.

Basically, you say;

error = setpoint - process_variable
output = error * Kp

And Kp (gain) is constant. Nice and easy. You should only need a safety at the left/right boundaries to cut off the output when it gets out of range, and possibly some functions to invert motor and rotate inverse. You tune the gain so that it goes as fast as it can without oscillating.

Edit: Forgot to talk about I and D:
Integral (I):
Basically you integrate the error and add it to the output:

integral += error
output += integral * kI

Ki is Integral Gain. You also need to reset integral to prevent integral windup. Generally you do not need to implement I unless you cannot get enough accuracy with P alone.

Derivative (D):
You calculate the derivative of the previous action to determine how momentum will affect the stopping ability. Basically, it works against P and I to slow it down when it nears the end, allowing a higher P gain. You will almost certainly not need this with crab steering, as the friction of turning the pods will probably slow their rotation very quickly (D would be useful for, say, a 6' arm that has a lot of mass at the end).

I do know there are other ways of doing this but I like the challenge of completely writing code from scratch. The safeties are in there because one of our mentors was afraid we were going to break his swerve drive. He was afraid that the encoder/pot was going to fall off and since our drive could not continually rotate without breaking the frame, he was always afraid when we made changes to the code. My code is actually based off the code my dad uses for his drives at his work, minus he torque controllers. I have speed and position/distance controllers.

[kgzak]

Ok I have attached my code for the swerve drive. I will answer any questions.

[apalrd]

While I can't look at your code since I don't have LV on this computer, I can say a few things in general:

1. P should be good for steering, unless you have a lot of friction.
2. You should rely on the sensor. Not too much, but don't program all kinds of safeties like it going in the wrong direction. good limits are out of bounds, lost sensor (0 volts), and not moving if you are really worried about it. We have no mechanical limits on our swerve, except the wiring, and we leave a lot of extra wire. Using window and globe motors (especially the window motors), it doesn't have enough power to damage much in our application.
3. Use the same code in auto as teleop - best to put it in a new thread.
4. Make kP (gain) a front-panel control or global to tune it. If you are using four identical motors (e.g. window motors), you would probably be fine with one gain and volts/deg, and x centerpoints (where x is the number of controllers), if you mix motors (e.g. window+555 or window+globe), then you would need a different gain for each motor and volts/deg for each different sensor (e.g. when sensor gearing or # of turns is different).
5. Pots never completely fall off. We have had many problems with set screws coming loose and pots loosing connection, but never completely fall off.
6. Don't be scared of code changes. We change our code quite frequently, and generally try to test it before playing, depending on how major the change was (we don't generally test autonomous kick distance changes, for instance).