Arcade mecanum drive

[jhellr13]

I have been looking around at info regarding mecanum driving. I have seen you really need to use tank drive. I also found it can be done with arcade too. Except that rotating doesn't work like in tank drive. I was thinking if we used arcade drive with the logitech attack 3d extreme joystick that has a swivel joystick, would rotation then work if linked up to the swivel axis. Could this work?

Thanks

[Ether]

Originally Posted by jhellr13

I have been looking around at info regarding mecanum driving. I have seen you really need to use tank drive. I also found it can be done with arcade too. Except that rotating doesn't work like in tank drive. I was thinking if we used arcade drive with the logitech attack 3d extreme joystick that has a swivel joystick, would rotation then work if linked up to the swivel axis. Could this work?

Thanks

The WPI Library supports mecanum in all three languages - Java, C++, and LabVIEW.

If you have a 3-axis joystick, it's simple. Use one axis (usually the Y axis) for forward/reverse, one axis (usually the X axis) for strafe right/left (sideways motion), and one axis (usually the twist axis) for rotation clockwise/counterclockwise.

See attached screenshot of the Mecanum Cartesion VI in LabVIEW and the MecanumDrive_Cartesian in C++.

[jhellr13]

Originally Posted by Ether

The WPI Library supports mecanum in all three languages - Java, C++, and LabVIEW.

If you have a 3-axis joystick, it's simple. Use one axis (usually the Y axis) for forward/reverse, one axis (usually the X axis) for strafe right/left (sideways motion), and one axis (usually the twist axis) for rotation clockwise/counterclockwise.

See attached screenshot of the Mecanum Cartesion VI in LabVIEW and the MecanumDrive_Cartesian in C++.

Thanks. So axis y would be forward/back. Axis x strafe left/right. And Axis 4(Swivel) would be rotation. Correct?

[2611.Shooter]

or, connect a gyro, input it to the mechanum vi for field oriented drive, make x strafe, y forward/back, and give your arm controller x axis rotation with y being arm up/down. so, the driver only controls movement, and forward will ALWAYS move the bot away from the driver station, etc. just an alternate method to consider.

[jhellr13]

Originally Posted by 2611.Shooter

or, connect a gyro, input it to the mechanum vi for field oriented drive, make x strafe, y forward/back, and give your arm controller x axis rotation with y being arm up/down. so, the driver only controls movement, and forward will ALWAYS move the bot away from the driver station, etc. just an alternate method to consider.

I would definitely use a gyro. I'm just running ideas of drivetrains through my head for next year. To make it easier for other kids to drive, i would probably just use axis 4(swivel) the rotation. If you could though, send me a picture of code that works the way you described. I can't really visualize in my head

[Kevin Sevcik]

The gyro doesn't solve all problems. You still want to be conscious of the direction your robot is facing when moving because the maximum speed of a mecanum strafing is less than the maximum speed moving forward/backward. So you'd still want to mostly travel forward/backward for getting places quickly.

[Ether]

Originally Posted by Kevin Sevcik

the maximum speed of a mecanum strafing is less than the maximum speed moving forward/backward

This is a practical limitation, not a theoretical one. It is due to the fact that the mecanum's rollers do not spin when the vehicle is moving forward/backward*, but they do spin (very fast) when the vehicle is strafing. The friction in the roller bearings wastes energy that would otherwise go into vehicle motion. The inexpensive mecanum wheels used by most FRC teams exhibit this behavior. It is possible to design and build mecanum wheels that minimize roller bearing friction but doing so would be beyond the resources of most FRC teams.

In directions other than pure forward/reverse or strafe, there is a theoretical reduction of maximum speed (even with friction-free roller bearings). This theoretical reduction reaches a maximum of 30% in the pure diagonal direction.


*There may be some slow spinning of the rollers due to axial free play in the rollers, or under high loads (accelerating, climbing a hill, or pushing an object) when operating on a compliant surface such as soft carpet.

[2611.Shooter]

Originally Posted by jhellr13

If you could though, send me a picture of code that works the way you described. I can't really visualize in my head

we are using C++, and I do not, unfortunately have access to the programming laptop. All I was saying was to control rotation with a second joystick, instead of axis 4 on the first joystick. this lets a second person worry about how the arm is positioned independently of the movement of the robot. It also lets you do stuff like this. http://www.youtube.com/watch?v=sM8cixsE5fo

[Ether]

Originally Posted by 2611.Shooter

All I was saying was to control rotation with a second joystick, instead of axis 4 on the first joystick. this ... lets you do stuff like this. http://www.youtube.com/watch?v=sM8cixsE5fo

I could be wrong, but I would guess that field-oriented-control is what lets the 488 robot do what you saw in that video. You could just as easily do that with a single joystick with the rotation controlled by the twist axis if the translation commands (Y and X) are field-oriented.


of a 3-axis joy

[2611.Shooter]

The point was that hooking up a gyro can make driving while turning easier. sorry if I was unclear, I was just saying how my team had set it up.

[Nemo]

Originally Posted by jhellr13

I have been looking around at info regarding mecanum driving. I have seen you really need to use tank drive. I also found it can be done with arcade too. Except that rotating doesn't work like in tank drive. I was thinking if we used arcade drive with the logitech attack 3d extreme joystick that has a swivel joystick, would rotation then work if linked up to the swivel axis. Could this work?

Thanks

You could certainly set mecanum up as a tank drive with one x-axis (or both x-axes averaged together) used for strafing. You'd need to invent your own mixer code that tells the motors what to do when, for example, your driver hits up-left 50% on the left stick and down-left 25% on the right stick. It would need to output the four motor outputs that would make the robot do a combination of moving diagonally left-forward at a certain rate and rotating to the right at the appropriate rate.

Actually, I'm thinking about this, and maybe that would be relatively simple to try. If you just subtracted Y-axis 1 from Y-axis 2 and divided by 2, you'd have a rotation axis. You average Y-axis 1 and Y-axis 2 together to get your forward/backward axis. Then you average X-axis 1 and X-axis 2 together to get your strafing axis. Feed those three numbers into the mecanum code that all teams were given, and I think it would work as a tank drive.

Originally Posted by Ether

I could be wrong, but I would guess that field-oriented-control is what lets the 488 robot do what you saw in that video. You could just as easily do that with a single joystick with the rotation controlled by the twist axis if the translation commands (Y and X) are field-oriented.
of a 3-axis joy

Field oriented control would certainly make this easier. Our drivers have also practiced this maneuver using the regular arcade drive / robot-oriented control that is provided in the FRC LabView libraries with our own gyro feedback VI added in. This year we used an XBox controller to drive, which has two joysticks. One of the sticks does rotation (uses x axis only) and the other does forward/backward and strafing. We also set up the trigger buttons to strafe left/right (those are axes, not True/False inputs). To do the 180 maneuver in the video on robot centric control, you have to start the forward/backward joystick straight ahead. Then you have to start rotating it (go sideways on the rotation axis) and simultaneously roll the other joystick around from front to sideways to backwards.

Field-oriented control is easier to use in some ways but not strictly superior to robot-oriented control. For one thing, robot oriented control allows you to achieve the robot's maximum speed simply by hitting straight forward. Because you can't go as fast at an angle or sideways, that isn't always true on field oriented control. Also, moving the joystick straight forward always moves your manipulator straight forward (if it points forward), which can be preferable if you have the robot lined up to a field element and just need to move it closer. I talked to our driver for this year about the trade-offs, and he prefers robot oriented control. It does take some practice, particularly in a game like this year's where the robot is facing toward you so much of the time.

[buchanan]

Regarding the tradeoffs between field-oriented vs robot-oriented...

It's really simple to set up the controls so that the driver can use whichever one works best for a given situation or maneuver. Set up one stick to operate robot-oriented and another field-oriented. Whichever one is non-zero takes control. Have a precedence rule in case both get grabbed, but in practice that won't happen if the same driver moves the same hand from one to the other.

2077 has used this arrangement with holonomic drive for the past two years. Our driver uses the field-oriented motion stick when looking directly at the field (3rd person viewpoint, 3rd person control) and the robot-oriented stick when looking through the camera (1st person orientation). We prefer rotation on a separate stick, common to both modes, but using twist on the motion sticks would work too.

Try that with your 6wd and let us know how it goes .

[Ether]

Originally Posted by buchanan

It's really simple to set up the controls so that the driver can use whichever one works best for a given situation or maneuver. Set up one stick to operate robot-oriented and another field-oriented. Whichever one is non-zero takes control. Have a precedence rule in case both get grabbed, but in practice that won't happen if the same driver moves the same hand from one to the other.

Just use one joystick, but use robot-oriented when the trigger is pulled and field-oriented when the trigger is not pulled.

[buchanan]

Just use one joystick, but use robot-oriented when the trigger is pulled and field-oriented when the trigger is not pulled.

Certainly could do; whatever the drivers prefer.

While the IMO trite "lots of practice" is true in principle, and MAY even be the most important factor in driving effectiveness, it's not the only factor. Some control arrangements are better than others, and it's worth some effort to design one that works well for your situation. For a given amount of practice, whether a little or a lot, better control design gives better results, and better control design means better results with limited (imagine that) practice.

As the only team in FIRST that doesn't have a full sized practice field and multiple practice robots on which dedicated drivers with no other tasks during the build season can practice on from day one, we've had to deal with the fact that our drivers can't get as much practice as we'd like them to have. We are no doubt unique as well in having on ocasion not had a working robot ready for driver practice until ship day or regional practice day.

Practice is good, but good controls can help you deal with not getting as much of it as you'd like. One of the big practical advantages of holonomic drive is it gives you some control options you don't have with other arrangements