Encoders on mecanum drive?

[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?

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

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

[dougwilliams]

Originally Posted by Ether

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

True again, I guess in my mind I had imagined the locked/non-swiveling caster-style wheels.

Swiveling caster with an encoder will only track total distance traveled from starting. Unless you track wheel spin and another encoder of the orientation of the caster. Which may, in fact, be what the poster meant originally and I misunderstood.

[Ether]

Originally Posted by dougwilliams

Unless you track wheel spin and another encoder of the orientation of the caster.

Please read post#8 in this thread.

[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

[idahorobot]

Originally Posted by juchong

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!

Do you or the community have some code sample to illustrate this?