Encoders on mecanum drive?

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

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

[Whippet]

Originally Posted by idahorobot

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

/* 
 * This is the experimental code for the 2015 robot.  DO NOT USE FOR COMPETITION!  
 * All code that is useful will be in  a separate project.
 */
package org.usfirst.frc.team4301.robot;


import edu.wpi.first.wpilibj.SampleRobot;
import edu.wpi.first.wpilibj.RobotDrive;
import edu.wpi.first.wpilibj.Joystick;
import edu.wpi.first.wpilibj.Timer;
import edu.wpi.first.wpilibj.Gyro;



public class Robot extends SampleRobot {
    RobotDrive myRobot;
    Joystick DriverStick;
    Joystick OperatorStick;
    Gyro gyro;

    public Robot() {
        myRobot = new RobotDrive(0, 1, 2, 3);
        myRobot.setExpiration(0.1);
        DriverStick = new Joystick(0);
        gyro = new Gyro(0);
    }

    /**
     * Drive left & right motors for 2 seconds then stop
     */
    public void autonomous() {        
    }

    public void operatorControl() {
        myRobot.setSafetyEnabled(true);
        while (isOperatorControl() && isEnabled()) {
        	//set x, y, and z values
        	double x = DriverStick.getX();
        	double y = DriverStick.getY();
        	double z = DriverStick.getZ();
            myRobot.mecanumDrive_Cartesian(x, y, z, gyro.getAngle());
            if(DriverStick.getTrigger() == true) {
            	gyro.reset();
            }
            Timer.delay(0.005);		// wait for a motor update time
            
        }
    }

    /**
     * Runs during test mode
     */
    public void test() {
    }
}

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

[IronicDeadBird]

Originally Posted by gpetilli

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.

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.

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

[dougwilliams]

Originally Posted by Whippet

.

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.

[Ether]

Originally Posted by gpetilli

...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 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)?

[gpetilli]

Originally Posted by Ether

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

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

[Ether]

Originally Posted by gpetilli

...a second pair of instrumented follower wheels

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

[gpetilli]

Originally Posted by Ether

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

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.

[jtrv]

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

[Ether]

Originally Posted by gpetilli

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.

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

[gpetilli]

Originally Posted by jtrv

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.

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.

[Ether]

Originally Posted by jtrv

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.

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.