faster field-centric mecanum drive

Technical Programming
1

During the build season, I programmed a basic field-centric mecanum drive on a previous robot. Our driver had driven in both Logomotion and Rebound Rumble using a robot-centric mecanum drive. His biggest complaint about the field-centric drive was that the robot could never move as fast strafing as it did moving forward and backward. For example, when the robot was facing forward and he wanted it to go left, the field-centric code would strafe left, and if he wanted the robot to go forward, the robot would drive forward. The problem came from a difference in maximum velocities. The strafing would always move more slowly at max than the forward/backward movement.

To the best of my knowledge, this is an omni-directional drive issue unique to mecanum drive. I don’t think that either swerve or omni drive encounter this because there is no appreciable difference in force when moving in distinct directions for these drive systems.

Our driver ended up using standard robot-centric drive because he was often moving at full speed, and he wanted to know how fast the robot would move when going forward/backward or left/right. His concern came from the fact that, with field-centric mecanum, he would not know at what velocity the robot would drive when he pushed the joystick completely in one direction if he didn’t know exactly which way he was facing.

I’ve been dreaming up a field-centric mecanum drive system that nullifies this problem, and I wanted to see if anyone has done anything similar. Essentially, the driver would use only one joystick, and the direction that he moves the joystick, the robot will move on the field (field-centric). In addition to moving in that direction however, the robot would also slowly turn to face that direction (or 180 degrees off) simultaneously. The advantage to standard mecanum omni-directional drive would be that the robot should be able to move more quickly when the front-back line of the wheels is parallel to the desired direction of motion.

For example, when the robot is facing forward, and the driver pushes the joystick left, the robot will:

  1. strafe left and turn CCW simultaneously
  2. continue moving left relative to the field as in standard omni-directional drive but simultaneously continue turning CCW
  3. eventually stop turning and drive straight relative to the robot

Essentially, this drive system would allow maximum velocity in any direction (after a short period of time) while also taking advantage of mecanum’s unique ability to move and turn the robot at the same time. It also opens up more capability for the driver with a simplification down to a single joystick instead of two. The driver could also have preset angles programmed into buttons which would cause the robot to switch from my drive system to basic field-centric so that the robot could line up for things like the feeder station or shooting.

In another light, this is similar to a 6-wheel robot field-centric code, in which the robot first turns to the desired direction and then drives that way. The only distinction would be that the mecanum wheels could have the robot already moving in that direction while it is turning.

Has this been done before?

2

I’m not sure if this is exactly what you’re looking for, but here is a video of my teams field oriented drive from 2010: http://m.youtube.com/watch?v=HT3WhTcQvw4
This was before my time in FIRST, so I probably won’t be able to answer many questions about it, but I can direct you to people who can.

3

This is an excellent video demonstrating the functionality of standard field-centric mecanum drive. The drive system that I am proposing however, is a modification to what the video demonstrates.
Thank you though

4

http://www.chiefdelphi.com/media/papers/2438

5

Ether, this is similar to what I was imagining. The difference would be with mecanum wheels, the robot could orient itself and move in the desired direction at the same time. With a 6-wheel drive, this is not possible, but I think it could work for a mecanum drive train.

6

The approach shown in the paper will work even better for a mecanum drive than for skid-steer (because a mec bot rotates more easily than skid).

But if you want to take full advantage of the mecanum’s capabilities (i.e. include the strafing capability in the maneuver), then all you have to do is implement standard field-oriented control of the mecanum, and superimpose on top of that a rotation command to bring the bot into alignment with the joystick angle. Then the bot will go in the direction of the joystick angle (including a strafing component as necessary) while simultaneously rotating to align with the joystick angle.

7

Its not shown in this video, but later in that season we added the “Trigger Function” as we called it. It would take the magnitude of the joystick and apply that as the magnitude for driving, then take the angle of the joystick and use the PID loop seen in that video to control the angle. It made the drivers look really good when all they had to do was point a stick!

Its not terribly compicated, its just a matter of doing out the Trig/Linear Algebra if you choose to, or just running a few overlapping PID loops.

8

We did this in 2011. I’ll point our programming mentor to this thread and he should be able to answer some questions for you.

Our driver could use a joystick button to rotate the robot so the scoring end faced the scoring rack. That button worked independently of other motion, so if he wanted, he could press that button while driving toward the scoring area and the robot would automatically spin as it translated. We also used field-oriented drive.

9

The above is not hard to do.

LabVIEW, C++, and Java all have a “gyro” input for mecanum cartesian to give you field-centric control.

Plug the gyro into that, and plug the X and Y from your joystick into the X and Y inputs. Now you’ve got field-centric “Halo” control of the mec bot.

Now take the shortest-angle difference1 between the gyro reading (process variable) and the joystick angle (setpoint) and use that difference as the error input to a closed-loop controller of your choice. Feed the output from that closed-loop controller into the “rotation” input of the mec cartesian VI (or method). Now your bot will simultaneously move in the commanded direction and turn to face the commanded direction.

1make sure the joystick angle and the gyro reading have the same zero and polarity. Ask if you need help.
*
*

10

scroll down to link for “mecanum gyro follower driver interface”:

http://www.chiefdelphi.com/media/papers/2390

11

We did field-centric control with our corner omni robot - Disco Slide in 2011.

We are attempting field-centric again in 2014 with our octocanum robot - Octanis.

We have not quite got our PID tuned out correctly but we are getting close.

Here is alink to our github and code for mecanum field centric.

12

190 did field oriented mechanum in 2005. The base robot was used to demo the “new” control system at the 2008 Championship. This robot used a segmented frame with a pivot to allow all 4 custom mechanum wheels to always contact the carpet, an encoder on each wheel, and a gyro. In 2005 they ran into the limit of the old IFI control system.

The controls were set up with two joysticks, one for translation left/right/fwd/backward and one for rotation cw/ccw.

13

inkling16, this is very possible. Your idea is a good one - and the fact that you’re listening to your drive team and trying to help them control the robot “the way they want it” is even better.

Your post was a little unclear - it’s hard to tell if you are asking:
-Is this idea new and unique?
or
-How do I do this?

As far as new and unique, not especially, though I don’t think it’s very common. Our team did something pretty similar, and at one point we had it coded up. Unlike your drive team, ours didn’t like it very much, so we reverted to our earlier form. To each their own.

As far as the how:
You’ll need to determine three inputs to drive the robot.
Translation intent: - probably from X/Y axes of a “Translation” joystick
Rotation intent: - probably from X axis (of another joystick) or Twist axis (in a 1-joystick setup)
Translation directional intent: do some trig on the X/Y axes of the Translation joystick in order to figure out in what direction the driver is trying to go.

Compare the translation directional intent to your current heading (you already have a gyro or something like it, since you’re using field-oriented drive). Use the difference between them (the “error”) and determine a rotational input from that (either by using PID or just multiplying by some constant).

When it comes time to actually use the Mecanum code - plug in your translation values as usual, but for rotation:
-If you’re being given an explicit rotation intent from the human operator, use that.
-If the human operator rotation intent is below some threshold (maybe 0.1), use your other calculated rotational input.

14

Wow, I had forgotten about this thread until just now.

JohnGlib, the intent of my original post was to see if anyone had ever made and tested a system like this before. I would still like to see some video of a robot doing this. I know that the programming is possible, and it actually doesn’t seem like the coding would be very different from standard field-centric. What I am curious to see is how a robot with (as Ether called it) Halo Auto-Rotate handles.

Unfortunately though, it would seem that I have not done a very good job describing this system, since people keep talking about standard field-centric mecanum instead of the system that I have described.

It is plausible that my team will be playing around with mecanum this upcoming offseason, if that is the case, I will have them make this kind of system and post video and results here afterward.