Swerve vs. Mecanum Programming
 

I have seen many people talk about the advantages and disadvantages of Swerve vs. Mecanum. I have seen one argument that a swerve is harder to program than a mecanum but I think it is the other way around. I have built at least 2 VIs (I use LabView) for a swerve drive and my dad has built at least 5. I still have yet to figure out how to program a mecanum drive.

So my two questions
1. What is you opinion on Swerve vs. Mecanum Programing difficulty.
2 Am I missing an equation or formula that can be used in programing a mecanum drive that makes it easier?

Re: Swerve vs. Mecanum Programming
 

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.

~

Re: Swerve vs. Mecanum Programming
 

Without getting into detailed equations, the mathematical principles of fully holonomic omni/mecanum drives are relatively simple and can be approached this way:

Each wheel has a direction vector along which it can transmit force in either direction. For a mecanum this is at 45 degrees to the plane of the wheel, parallel to the axle of the roller contacting the ground. For an omni it's along the flat plane of the wheel. No force is or can be transmitted except along this vector.

To get the wheel speeds necessary for any desired motion, you need to compute the projection of the motion vector onto each wheel's direction vector. For mecanums there's an additional constant to correct for the 45 degree angle. This can be done with dot products and no trigonometry.

For simple directional motion, regardless of direction, that's all there is to it. To handle rotation, the motion vectors are tangent to a circle about the center of rotation, projected on the same wheel vectors, and scaled by relative radius. For rotation about the center of a normally configured robot, these end up the same for each wheel. Rotation about other points or for odd wheel configurations is a bit more complex but conceptually the same. You can rotate and move simultaneously by solving the wheel speeds for each separately, then adding the motion and rotation components for each wheel to get its final drive speed.

This approach lends itself well to a two stick motion/rotation or single stick/twist control setup, and the vector math shouldn't take more than a couple of dozen lines of Java or C. It handles any motion physically possible with the robot. The motor drive functions needed for swerve drives, especially for complex motions, are considerably more complicated.

It should be noted that there are simpler but still useful ways to employ mecanum/omni wheels short of full holonomic, and other ways to program swerves short of the "almost holonomic" of which they're capable.

Re: Swerve vs. Mecanum Programming
 

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.

Re: Swerve vs. Mecanum Programming
 

Thanks, that helped. Between you and Ether I figured it out. I thank both of you.

Re: Swerve vs. Mecanum Programming
 

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)


~

Re: Swerve vs. Mecanum Programming
 

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

Re: Swerve vs. Mecanum Programming
 

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.

Re: Swerve vs. Mecanum Programming
 

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

Re: Swerve vs. Mecanum Programming
 

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

Re: Swerve vs. Mecanum Programming
 

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 :D

Re: Swerve vs. Mecanum Programming
 

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.

Re: Swerve vs. Mecanum Programming
 

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

Basically, you say;
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:
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).

Re: Swerve vs. Mecanum Programming
 

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.

Re: Swerve vs. Mecanum Programming
 

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

Re: Swerve vs. Mecanum Programming
 

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

Re: Swerve vs. Mecanum Programming
 

The safeties were there just as a challenge for me to do. In one of the versions I have I can turn them on and off. Our pot was held on by friction on the shaft and had some sort of way to keep the pot itself from actually turning. (it was a practice robot but some of the parts needed to be used on the final robot). Everything in that VI I posted can be changed through the front panel. It is made to be modular so we can use it for steering, driving a certain distance, and what ever else involves moving from one number to another. I was not afraid of changing our code, our mentor was afraid he would have to re-machine the disks if we went to far. {We had aircraft wire screwed into 5 discs, 4 on the swerve assemblies-1 on the motor. If we turned to far either our wire would snap or the screws would break. The safeties were just to keep people in the room safe while it was running.}

Re: Swerve vs. Mecanum Programming
 

Ok some questions on your example what are you using in your robot to know the position in which the wheel is, are you using limit switches, gyro or any thing else, also on the example it does not show the motors or joystick is that an additional program or how are you runing this program.

Thanks :)

Re: Swerve vs. Mecanum Programming
 

He is using analog potentiometers.

This is a subVI. He calls it from his other code when he needs it. I would highly, highly, highly (I can't say this enough) recommend organizing code this way, especially separating mechanism control code from user interface code in separate threads.

Since he has a potentiometer, he has no need for limit switches. It tells him everything he needs to know. I would generally not use his method of "check greater/equal/lesser and set output based on case" and instead use proportional control, LabVIEW has a nice PID block you can use for PID or you can write your own, its just a subtract, multiply, and check range.

Re: Swerve vs. Mecanum Programming
 

If the system you're controlling does not have appreciable inerta and/or a slow response to changes in the control signal, a simple "full on"/"full stop" scheme can work fine. For example, a window motor usually stops as soon as you remove power, without significant overshoot. That's typical of a worm gear system.

On the other hand, if you're moving a massive mechanism around, you definitely want to slow it down on its way to the target position. Stopping it abruptly can lead to extreme stress on the gears (as demonstrated well by the teeth being stripped off a large sector of a heavy gear on the TechnoKats 2004 robot's arm by the team's programming mentor :o a few minutes before the pre-ship open house was to begin).

Re: Swerve vs. Mecanum Programming
 

You may notice that there is a "slow down range" in my code. I have done multiple ways of programing a swerve as apalrd has described. I used this version because we weren't getting enough power out of our motor at low speeds and the swerve modules weren't turning very fast any way. We did not actually use a swerve drive this year on our robot, we wanted to but we didn't have weight, but we tested a swerve drive with a globe motor. I can post my other simple code for a swerve that subtracts but we also used this VI for actually moving the entire robot (comparing encoder to the position we want to go to) and we didn't want to slow down as we got to the ball instead we wanted to move, at full speed, to right before the ball and then slow down and search for the ball. It worked really well.

Re: Swerve vs. Mecanum Programming
 

This VI can actually use any sensor you put into it as long as you are comparing to something that is in the same "units" as the sensor (encoder counts, gyro degrees, Potentiometer analog feed back) If you were to place this VI in you code there will be many inputs/outputs from the VI, just connect the "speed" (or something along those lines, I don't have it open in front of me I am on my Mac) to the set speed VI. I would recommend right clicking on the VI and clicking "View as Icon" to display all of the inputs/outputs in a vertical line, It keeps it much more organized.

Re: Swerve vs. Mecanum Programming
 

Ok I do undersand what your program does and its a really simple program, but what I am looking for is an even simple example, I am a senor so I am leaving this year and i am trainig some one for next year and I need something that is simple to explain.
Thanks

Re: Swerve vs. Mecanum Programming
 

I can try to write a simpler program. You could do something along the lines of finding the difference between the sensor and the control and set that as your speed.

Re: Swerve vs. Mecanum Programming
 

I have attached a simpler VI that could be used as a swerve drive. This one is commented so all your questions should be answered but I can still answer and other questions you have.