Encoders on mecanum drive?
 

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?

Re: Encoders on mecanum drive?
 

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.

Re: Encoders on mecanum drive?
 

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!

Re: Encoders on mecanum drive?
 

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

Re: Encoders on mecanum drive?
 

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.

Re: Encoders on mecanum drive?
 

I'm curious about this as well.

Re: Encoders on mecanum drive?
 

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.

Re: Encoders on mecanum drive?
 

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

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?

Re: Encoders on mecanum drive?
 

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.

Re: Encoders on mecanum drive?
 

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.

Re: Encoders on mecanum drive?
 

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

Re: Encoders on mecanum drive?
 

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.

Re: Encoders on mecanum drive?
 

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

Re: Encoders on mecanum drive?
 

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

Re: Encoders on mecanum drive?
 

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

Re: Encoders on mecanum drive?
 

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.

Re: Encoders on mecanum drive?
 

I have bolded the lines to pay attention to. Replace "4301" and all team-related items with your own code.

Re: Encoders on mecanum drive?
 

Stay in touch man that sounds like an awesome thing to do. It's like the ABS system on your car minus the annoying noise it makes. I'm interested in seeing how well that works. Albeit this year sensing when your robot is being pushed and getting feedback on that isn't as helpful as last year it would still be a nice off season project for some member.

Re: Encoders on mecanum drive?
 

Please read post#8 in this thread.

Re: Encoders on mecanum drive?
 

The posted code performs a field oriented drive. At any point in time we can set the robot to a known orientation on the field (the direction it is facing).

This is different than absolute field position. It would seem in autonomous we are concerned with absolute position of the robot in relation to the field and/or field elements so we know where to make the robot go to in order to pick up a tote or other task.

Field oriented drive (the code posted) does not help with that aspect of the task.

Re: Encoders on mecanum drive?
 

The context of this thread is mecanum, which has 3 degrees of freedom.

How do you intend to process 2 encoder signals to detect those 3 motions? (forward, strafe, rotate)?

Re: Encoders on mecanum drive?
 

Last year's robot used two omni-wheels plus a compass. We had lots of reliability issues with the compass due to interference from the CIM motors (solved with 4ft distance), and a mounting screw which was evidently magnetized. This year we intend to replace the compass (and gyro) with a second pair of instrumented follower wheels. The two X and two Y wheels will be located one in each of the four corners. A side benefit of this approach is that we can calculate the rotation about a point near the center of the robot without locating the rotational sensor in the center of the robot (middle of a tote).

Re: Encoders on mecanum drive?
 

OK. That's a horse of a different color.

Re: Encoders on mecanum drive?
 

We had actually discussed this approach last year and you posted a "homework" discussion thread on the topic. I hope you still feel the math will work because I just ordered all the omni-wheels.

Re: Encoders on mecanum drive?
 

Okay, well, I seem to only have gotten one decent solution, that I get encoder values and reverse the mecanumDrive trig functions to get distance.

problem: i still don't understand where they even attach to and what exactly they measure.

Do they still measure distance traveled? How do I even track direction with 1 encoder per wheel? If i go 45 deg to the right of initial orientation, and I move 1m, what would the 4 encoders even read?

as of right now we don't have a base, nor anything to attach mec wheels to, so... until then us programmers are kinda sitting here putting stuff on smartdashboard...

Re: Encoders on mecanum drive?
 

That sounds familiar now that you mention it. I'll go take a look :-)

Re: Encoders on mecanum drive?
 

1) As the robot moves, there are three degrees of freedom; lets call them X (strafe),Y (forward) and R (rotation/orientation). Lets call the starting position (when the robot is powered on) [0,0,0] then if you measure the changes from the starting position, you can know your current X,Y,R. They dont have to be the same kind of sensors but ideally they are "orthogonal"

2) There are several sensors available to us. We need to be careful on units. Encoders measure rotation of a shaft. A quadrature encoder also detects the direction (CW/CCW) the shaft is rotating - VEX has a good writeup on how that works. If you know the circumference of the wheel turning the shaft and divide by the pulses per rev (PPR), you can calculate the distance travelled. If in addition you know the time over which you took the measurement, you can calculate the linear velocity of the wheel. The WPI API code for the encoders will both count the pulses and convert them to velocity.

3) The typical way to (indirectly) measure R is to use a gyroscope. The gyro gives you angular velocity at the physical location of the sensor. If you want the direction you are facing, you need to "integrate" the velocity over time to get degrees from your starting orientation. This is useful for mecanum in that you can use it to drive straight by adjusting the power to the wheels in such a way to maintain a zero angular velocity (not turning) while you move in any combination of X and Y. Gyros are notorious for having "drift" which means that very small errors in the measurement of the angular velocity can create large errors during the integration process to create the current orientation angle. You tend to use velocity for teleop control and angle for autonomous (only 15sec, so drift not an issue).

4) encoders can be used on either the driven wheels or on separate non-driven wheels (which my team calls a pedometer). Most FRC gearboxes have an easy way to mount an encoder. If you are using mecanum wheels, you may need to reverse the trig to separate X and Y.

5) Another way to measure R, is with an electronic compass. This directly measures the sensor orientation with respect to magnetic north of the earth. The issue is that other magnetic fields (motors) can confuse it.

In the end, you need to first decide what you want to control, then how you are going to measure it (and with what sensor). There are lots of example code on how to control a mecanum drive with encoders plus a gyro.

Re: Encoders on mecanum drive?
 

What you have described is called forward kinematics. If your wheel speeds are not kinematically correct*, you cannot compute a true forward kinematic solution, because there will be wheel scrubbing. You can find a least-squares solution, but there's no guarantee that will describe the vehicle's actual motion.

By the way, there are no "trig functions" required to do mec inverse kinematics.

*due to an incorrect inverse kinematic computation, or differences in motor controller calibration, or differences in performance among the 4 motors, or differences in resistance among the 4 motor wiring circuits, or differences in friction among the 4 gearboxes, or differences in friction of the rollers among the 4 wheels, etc etc etc.