Encoder count maximum value

[zain]

At what value does the encoder counting hardware in the MR motor controllers max-out, and do they then "roll-over" to positive/negative or do then simply stick saturated at that value?

I have a suspicion that the kids with the RUN_WITH_ENCODERS controlled ball shooter are going to ask me, and I should probably know...

- Z

[Philbot]

At what value does the encoder counting hardware in the MR motor controllers max-out, and do they then "roll-over" to positive/negative or do then simply stick saturated at that value?

I have a suspicion that the kids with the RUN_WITH_ENCODERS controlled ball shooter are going to ask me, and I should probably know...

- Z

The encoder value is a 4 byte signed integer which means it has a range of -2,147,483,648 to 2,147,483,647

So at max speed (4000 cps) the motor would take about 149 hours to reach it's limit. You should be OK.

Phil.

[zain]

Cool thanks. I'll have them check for counts and saturation just for the coaching/teaching exercise anyway. But I didn't know how the value was tracked in the HW.

[RedfishRobotics]

The encoder value is a 4 byte signed integer which means it has a range of -2,147,483,648 to 2,147,483,647

So at max speed (4000 cps) the motor would take about 149 hours to reach it's limit. You should be OK.

Phil.

Of course Phil's math is spot-on, because, well, it's Phil. The MRI Core Device Discovery guide ads some context that helped us:

http://modernroboticsinc.com/Content/Images/uploaded/CoreDeviceDiscovery/Core_Device_Discovery_User_Guide.pdf

Happy holidays!

[rbFTC]

The encoder value is a 4 byte signed integer which means it has a range of -2,147,483,648 to 2,147,483,647

So at max speed (4000 cps) the motor would take about 149 hours to reach it's limit. You should be OK.

Phil.

Phil, just found this thread while searching for information on max speed. Where did you get the 4000 cps value for max speed? Does it depend on the motor type, or is it independent of motor being used? Is is hardcoded in the FTC SDK or the MR motor controller?

[Philbot]

Phil, just found this thread while searching for information on max speed. Where did you get the 4000 cps value for max speed? Does it depend on the motor type, or is it independent of motor being used? Is is hardcoded in the FTC SDK or the MR motor controller?

The 4000 CPS comes from the original TETRIX motor/encoder combination. esentially 1000 degrees per second with one count per 1/4 degree.

It depends on many things....
Some motors (Andymark/MATRIX) have the encoder on the primary motor shaft, so the CPS isbased on the motor RPM and the number of counts per sensor revolution. It's not effected by the actual reduction gearbox.
Other motors (like the TETRIX one) has the encoder on the output shaft, so it's based on the output shaft RPM and encoder resolution.

You can hunt down the motor/gearbox/encoder specs, or you can determine it for yourself.

The easiest way to determine an approximate max value is to use RUN_WITHOUT_ENCODER mode (which does not limit the output speed) and then run the motor at 1.0 power for 10 seconds.
Reset the encoder before you start the test, and then look at the final encoder count and divide by 10.

This value will depend on your battery voltage, so start with a fully charged one to get the best possible value.
It is unlikely that you will ever get this high value on a robot with any load on the motor, so take this into account when you choose a max speed for actual competition.

Phil.

[4634 Programmer]

The encoder value is a 4 byte signed integer which means it has a range of -2,147,483,648 to 2,147,483,647

So at max speed (4000 cps) the motor would take about 149 hours to reach it's limit. You should be OK.

Phil.

The internal PID in the MR controllers was reversing our flywheels after only about 1 minute and a half...

[Alec]

The internal PID in the MR controllers was reversing our flywheels after only about 1 minute and a half...

I was able to reproduce this issue with the Core Device Discovery App. Using the Speed mode, the NeveRest 3.7 motor reverses direction within 2 minutes; reverses direction again within 2 minutes, and the reversals keep repeating and repeating within every 2 minutes.

I could not reproduce the issue with NeveRest 20/40/60, which is odd because I thought the only difference between 3.7, 20, 40, and 60 is the gearbox (i.e. the four motors would have the same encoder and roughly the same CPS regardless of which gearbox is attached to the motor).

Motor Controller Firmware ver: 2.0
Device Discovery App ver: 2.0.3
Motor selection: AndyMark
Mode: Speed
Power: 100

[4634 Programmer]

I was able to reproduce this issue with the Core Device Discovery App. Using the Speed mode, the NeveRest 3.7 motor reverses direction within 2 minutes; reverses direction again within 2 minutes, and the reversals keep repeating and repeating within every 2 minutes.

I could not reproduce the issue with NeveRest 20/40/60, which is odd because I thought the only difference between 3.7, 20, 40, and 60 is the gearbox (i.e. the four motors would have the same encoder and roughly the same CPS regardless of which gearbox is attached to the motor).

Motor Controller Firmware ver: 2.0
Device Discovery App ver: 2.0.3
Motor selection: AndyMark
Mode: Speed
Power: 100

AFAIK, you are correct; there is no difference except the gear box.

We are using the NeveRest motors with a 3rd party gear box. I have not tested our other motors to see if they experience the same problem.

[gof]

The specs for the 3.7 motor show 1784 Rev/min * 1 min/60 sec * 103 counts / rev = 3062 counts per second. As Philbot pointed out, according to the MR specifications http://modernroboticsinc.com/core-motor-controller-3, the encoder is 32-bit and thus has a longer run range than anyone in FTC should be concerned with.

Perhaps this is an issue with the Core Device Discovery tool?

[Alec]

I was able to reproduce this issue with the Core Device Discovery App. Using the Speed mode, the NeveRest 3.7 motor reverses direction within 2 minutes; reverses direction again within 2 minutes, and the reversals keep repeating and repeating within every 2 minutes.

I could not reproduce the issue with NeveRest 20/40/60, which is odd because I thought the only difference between 3.7, 20, 40, and 60 is the gearbox (i.e. the four motors would have the same encoder and roughly the same CPS regardless of which gearbox is attached to the motor).

Motor Controller Firmware ver: 2.0
Device Discovery App ver: 2.0.3
Motor selection: AndyMark
Mode: Speed
Power: 100

I've logged this issue in GitHub (Issue #286)

[4634 Programmer]

...Perhaps this is an issue with the Core Device Discovery tool?

Nope, we are experiencing this issue with the Android control system. (I never tried the CDD tool)

[Philbot]

Nope, we are experiencing this issue with the Android control system. (I never tried the CDD tool)

OK, if this problem is occurring with BOTH the CDD tool AND the SDK, then there are only two common components:

1) The CORE Motor Controller
2) The Neverest 3.7 motor.

The fact that we are only just starting to see this is interesting....

I'm still not %100 convinced it's not the Neverest motor having a hard time with it's encoder alignment.

Lets do a head-count...
Has anyone seen this effect on ANY other motor/gearbox combination than an Neverest 3.7 motor?

Before anyone says "But the motor is the same" remember that variable shaft load has been seen to effect the operation of the encoder before.
Perhaps the 3.7 gearbox is applying a different in/out shaft displacement which is causing excess pulses .

Do we have data showing how the encoder counts increment while the 3.7 is being run?

[4634 Programmer]

... Has anyone seen this effect on ANY other motor/gearbox combination than an Neverest 3.7 motor?

We don't even have a Neverest 3.7.

This issue is occurring for us with a BaneBots gearbox.

[Philbot]

I'm gravitating to the root cause being that the motor/encoder is not generating as many counts per second as we are expecting.

I beleive that if you request a speed (CPS) in RUN_USING_ENCODER mode that is just too high, the CORE controller is accumulating the speed/position error and eventually the integrated error is getting too big, and is wrapping around, causing the motor to reverse.

The proof to this is simply to only request a CPS that is achievable by the motor.
This can only be done by verifying the actual CPS of the motor under normal load conditions.

We seem to be getting strong reports that the NR3.7 motor is NOT putting out the expected CPS.
I am seeing reports of numbers as low as 1260 CPS (rather than the advertised 3000 CPS).

So, anyone with a problem motor should run a full power test on the motor.

Try this teleop routine for a 10 second test. Just run and wait for final value.

@TeleOp(name="Encoder Test", group="Test")
public class EncoderTest extends LinearOpMode {

    /* Declare OpMode members. */
    private ElapsedTime runtime = new ElapsedTime();
    DcMotor testMotor = null;

    @Override
    public void runOpMode() {
        testMotor  = hardwareMap.dcMotor.get("left drive");

        testMotor.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);

        // Wait for the game to start (driver presses PLAY)
        waitForStart();
        testMotor.setMode(DcMotor.RunMode.RUN_WITHOUT_ENCODER);
        runtime.reset();

        // run motor for 10 seconds
        testMotor.setPower(1.0);
        while (opModeIsActive() && (runtime.time() < 10)) {
            telemetry.addData("Encoder", "%4.1f:  %d counts", runtime.time(), testMotor.getCurrentPosition());
            telemetry.update();
        }

        testMotor.setPower(0.0);

        telemetry.addData("Encoder", "%5.0f Counts Per Second", (double)(testMotor.getCurrentPosition()) / runtime.time());
        telemetry.update();
        while (opModeIsActive());

    }
}