Encoders on mecanum drive?

[jtrv]

Can someone explain how encoders work on a mecanum drive? I don't really get how its supposed to work. The only encoders I've worked with are 1 dimensional - we've always used tank drive (until this year) and we just put encoders on each side of the drive, and got 2 values for each side, either + or -. We could then convert it to tell how far we've traveled.

How on earth does this work with mecanum when you can travel at a 45 deg angle, and how do you measure left or right directional movement?

[Alan Anderson]

It sounds like you've just been using encoders as odometers, rather than as elements in a closed-loop control system.

The typical use on a mecanum drivebase is to maintain highly detailed control over the wheels, to make the robot go in exactly the direction and at exactly the velocity desired. Each wheel is independenly driven with encoder feedback letting the speed controller update the voltage quickly in order to keep the wheel turning precisely as specified by the software.

[juchong]

Originally Posted by Alan Anderson

It sounds like you've just been using encoders as odometers, rather than as elements in a closed-loop control system.

The typical use on a mecanum drivebase is to maintain highly detailed control over the wheels, to make the robot go in exactly the direction and at exactly the velocity desired. Each wheel is independenly driven with encoder feedback letting the speed controller update the voltage quickly in order to keep the wheel turning precisely as specified by the software.

If you couple this information with a gyro sensor, you can achieve very accurate field-centric driving! It also has the side effect of making your autonomous very predictable!

[rsaccone]

Are there code samples available to illustrate how this might work?

[dougwilliams]

As Alan pointed out, you can use encoders for more accurate speed control of individual wheels (which in itself may have utility). However, I think jtrv is probably really looking for the distance traveled function / odometer (as Alan pointed out).

That in itself you can do (easily?) - as you would need to mathematically combine the feedback from all four wheel sensors. I've been thinking about that the last few days, and in theory, it seems like you could do that and understand what is being driven to each wheel. If you mathematically reversed the trig functions from the software motor drive functions - you could effectively tell yourself what direction the robot is going, and for what amount of time.

The caveat is - what direction the robot "should" be going is different that actually going. You could spin a mecanum if you are stuck against something, and that problem is more prevalent in comparison to a traction wheel which might just stall. It wouldn't account for designed slip of mecanum rollers.

I'm curious if anyone has done that and what the utility of that wound up being (if so please send a link or reference).

And then as juchong pointed out, with a gyro/IMU you should also be able to take encoder inputs and couple that with accelerations and gyro spin feedback and predict better where you are on the field.

Has anyone ever seen that done - and again - if so, what was the overall effectivity of that for positional control? It's something I'd love to do - but don't have a good understanding of the resources needed and whether it's worth it. If anyone has any additional info I'd love to take a look.

[jojoguy10]

Originally Posted by rsaccone

Are there code samples available to illustrate how this might work?

I'm curious about this as well.

[Tom Line]

Since doing this is very difficult, you have a couple other options.

You can put a couple unpowered casters with encoders are them to measure location. Or you could use distance sensors on the robot to determine positions from the walls.

Each has it's own issue. The casters may bounce on the bumps and be inaccurate, and different sensors have their own issues with different wall materials and surface finishes.

[Ether]

Originally Posted by Tom Line

You can put a couple unpowered casters with encoders are them to measure location.

Could you please give additional detail what you have in mind? Two casters with two encoders on each one? Something else?

[IronicDeadBird]

Not sure if this is a thing because google searching on my phone is all sorts of awful. Looking at past technology I know we can measure movements on a captive ball system (you all remember those funny mice with the little grey ball on it) or even more recently high end gaming mice. Is anyone aware of these sort of devices being used in the FRC world?

[dougwilliams]

Originally Posted by Tom Line

...
You can put a couple unpowered casters with encoders are them to measure location. ...

I assume you have one X and one Y caster. If you do that, you still need to track rotation of the robot, as you spin those will later their orientation and not be accurate to original absolute X and Y.

[gpetilli]

Originally Posted by IronicDeadBird

Not sure if this is a thing because google searching on my phone is all sorts of awful. Looking at past technology I know we can measure movements on a captive ball system (you all remember those funny mice with the little grey ball on it) or even more recently high end gaming mice. Is anyone aware of these sort of devices being used in the FRC world?

I know one team at the Fingerlakes Regional about 5 years ago won the Innovation in Control award for using a mouse for movement sensing. The last we looked at trying this, the modern mice were too precise (6000 pulses per inch) and the cRIO could not handle the pulse rate.

What we did last year and intend to do again this year is to use two smaller omni-wheels (VEX 2.75in) with encoders mounted orthogonally square to the frame. They directly measure the actual motion, not the intended, wheel slip free, motion. The important thing is to ensure the un-powered follower wheels are always in contact with the floor.

[Ether]

Originally Posted by dougwilliams

I assume you have one X and one Y caster.

A caster looks like this. It is neither X nor Y. See post8 in this thread.

[dougwilliams]

Originally Posted by Ether

A caster looks like this. It is neither X nor Y. See post8 in this thread.

Sorry, poor choice of language. I assume for full field localization, the poster was implying placing 2 individual casters, one oriented in X direction, and one placed orthogonal, in what they assume to be a Y direction.

Then you have one dragging caster at all times, or you go the mouse ball route. Even with the mouse ball, you still need to track rotation, as the mouse operates on the assumption of having the same general yaw position on a persons desk.

[Ether]

Originally Posted by dougwilliams

I assume for full field localization, the poster was implying placing 2 individual casters, one oriented in X direction, and one placed orthogonal, in what they assume to be a Y direction

A caster swivels. It's not clear what you mean by orienting a caster in the X (or Y) direction.

[Ether]

I theory, you could track angular orientation and XY displacement using 3 unpowered omni wheels with one encoder on each.

See attached sketch.


3 unpowered omni wheels L, R, & C, with one encoder on each wheel.

Forward (FWD) is upward in the diagram, strafe right (STR) is to the right in the diagram, rotation (omega) is positive clockwise.

The red dot is the reference point of robot motion (typically, but not necessarily, the center of the robot).

Here's how to convert the L, R, and C encoder speeds in fps into robot-centric motion FWD, STR, and omega:

FWD = (L+R)/2 fps

STR = C fps

omega = (L-R)/W rad/sec