Encoder count maximum value

[Philbot]

We don't even have a Neverest 3.7.

This issue is occurring for us with a BaneBots gearbox.

OK, but once again, not the standard 20/40/60 spur gear gearbox.

Perhaps the first planetary plate of both gearboxes are miss-aligning the motor shaft/encoder magnet.

[Alec]

OK, but once again, not the standard 20/40/60 spur gear gearbox.

Perhaps the first planetary plate of both gearboxes are miss-aligning the motor shaft/encoder magnet.

AndyMark has reproduced the issue of the encoder not producing the published encoder ticks per revolution on the NeveRest 3.7 motor.

AndyMark is working on tracking down the exact cause.

[FTC3888]

We can replicate similar results if we switch the A and B signals of the encoder cable, effectively reversing the direction of the encoder. To test if your A and B cables are reversed, turn on a motor with a constant positive power using Core Device Discovery. Ensure your encoder value is increasing. If the encoder value decreases with positive power, switch pins A and B referencing the image linked below.

http://modernroboticsinc.com/content/images/thumbs/0000315_core-motor-controller.jpeg

-Modern Robotics

[Alec]

We can replicate similar results if we switch the A and B signals of the encoder cable, effectively reversing the direction of the encoder. To test if your A and B cables are reversed, turn on a motor with a constant positive power using Core Device Discovery. Ensure your encoder value is increasing. If the encoder value decreases with positive power, switch pins A and B referencing the image linked below.

http://modernroboticsinc.com/content/images/thumbs/0000315_core-motor-controller.jpeg

-Modern Robotics

Hi FTC3888,

Thanks for re-tweeting. I believe most if not all FTC teams are using the am-2992 cable with the NeveRest motors:

---

---

With the am-2992 encoder cable it is not possible to reverse the A and B signals.

The worst you can do is plug the cable into the motor controller the wrong way in which the motor controller will get no encoder signals at all.

[Philbot]

AndyMark has reproduced the issue of the encoder not producing the published encoder ticks per revolution on the NeveRest 3.7 motor.

AndyMark is working on tracking down the exact cause.

They just recommended to me that I try 44 Counts per revolution...
which would give a Max Speed of 1300 CPS. Still sounds a but high. but it's getting much closer.

[4634 Programmer]

Hi FTC3888,

Thanks for re-tweeting. I believe most if not all FTC teams are using the am-2992 cable with the NeveRest motors:

---

---

With the am-2992 encoder cable it is not possible to reverse the A and B signals.

The worst you can do is plug the cable into the motor controller the wrong way in which the motor controller will get no encoder signals at all.

Actually, we had to reverse A and B on those encoder wires because otherwise the pinout wouldn't match the motor controller's.

[Alec]

Actually, we had to reverse A and B on those encoder wires because otherwise the pinout wouldn't match the motor controller's.

We don't have any issues with the batch of am-2992 encoder cables that we have. Our am-2992 cables work exactly per these specs from Modern Robotics:

To test if your A and B cables are reversed, turn on a motor with a constant positive power using Core Device Discovery. Ensure your encoder value is increasing.

-Modern Robotics

[zain]

FWIW, I had the kids approach this using phil's motor data spreadsheet from that other thread, wherein he showed the tables of power setting, motor voltage, speed in CPS and output RPM.

And they didn't change the max CPS at all, just treated the "max" for the AM motors to be ~0.72, which is what you'd expect given the encoder ratios. Thus leaving all the motor controllers in default settings they didn't have problems with integrator wind ups or anything else when running their shooter in RUN_WITH_ENCODERS so that both motors were closed loop with matched speeds.

This saved getting too far into all the control theory of it, and they understood why they could code a ratio like that into their code.

FWIW, motors don't match too well spinning CW vs CCW, so I had them measure the voltage on each while they were running them in RUN_WITH. So that they could see the control-loops running one with more voltage than the other to make them spin at the same rate. And to see how close they were getting to the max voltage out of the motor controller, and thus hos close to no longer having the RUN_WITH closed loop be able to make their motor speed matching work. Spent some time on where battery sag would come into play. etc.

In any case, this all seemed an easier and more accessible way to go.

- Z

[Alec]

AndyMark has reproduced the issue of the encoder not producing the published encoder ticks per revolution on the NeveRest 3.7 motor.

AndyMark is working on tracking down the exact cause.

I just received this document from AndyMark:

---

3.7 NeveRest Encoder Update

The Issue:
Teams have been reporting that the encoders on the NeveRest 3.7 are not reporting the
expected pulse output.

What’s Different with NeveRest 3.7:
The encoder that comes with the NeveRest 3.7 Gearmotor has a different architecture and with
it a different magnet. The magnet is energized with 3 poles. This is different than the magnets
on the motors that ship with the NeveRest 20, NeveRest 40, and NeveRest 60 gearboxes.

The Solution:
These gearmotors operate the same as the other NeveRest Gearmotors, but require some
adjustments when reading the encoder values.

Poles Per Magnet:
3 ( compared to 7 on the other motors)

Pulses Per Revolution:
3 poles * 3.7 ratio = 11.1
compared to 25.75 on the other motors

Ticks Per Revolution:
PPR * 4 Edges of a pulse = 44.4
Compared to 103 on the other motors

12/7/2016

---

[zain]

Whoo... that's really different. Kinda glad my kids just used the 4:1 gearbox that was available earlier...

[Alec]

Whoo... that's really different. Kinda glad my kids just used the 4:1 gearbox that was available earlier...

I think this thread shows that the best practice for determining the value for setMaxSpeed() is to use Phil's OpMode to measure the max CPS under load.

Phil, maybe you should add your OpMode to the SDK samples.

[zain]

Well yeah... I mean the AM site says it's the same motor. "This product is a combination of a new planetary gearbox, and our existing NeveRest Motor Only (am-3104)."
Which has always sold with the encoder. So the am3104-encoder one gets when ordering the 3.7:1 gearbox is different than the one you get with a Neverest 20 or 60?

Which of the two possibilities of encoder do you get if you order a bare AM-3104, now?
Are the different encoders and magnets labelled differently so kids could tell?
Since motor/encoders have always sold in pairs, ought there not be a new part number for the three-pole-encodered AM3104 to make it clearly different from the seven-pole-encodered AM3104?

Seems like bad juju to have encoder type be tied to what gearbox you did or didn't order, especially if the same P/N is also used to sell the combo without a gearbox...

- Z

[Alec]

According to AndyMark, the NeveRest 3.7 motor:

"is a combination of a new planetary gearbox, and our existing NeveRest Motor Only (am-3104). As per the FIRST Tech Challenge Game Manual Part 1 for 2016-2017, this motor is legal based on the part number am-3104 being listed under RE09, and the gearbox following RM02."

The NeveRest 3.7 motor is not exactly a am-3104 motor, so technically the 3.7 motor was not a legal motor until yesterday. Yesterday FTC published an amendment to <RE09> which now says that any NeveRest motor is legal.

Most probably the supplier changed the NeveRest encoder without informing AndyMark. Quite possibly older batches of the NeveRest 3.7 motors may have the old encoders (the ones with 7 poles per magnet), and newer batches of 20/40/60 motors will have the newer encoders (the ones with 3 poles per magnet). Two months from now NeveRest encoders may have 5 poles per magnet.

The moral of this story is don't trust the encoder specs. This is probably a good thing because the specs are theoretical values. What you want is the actual max CPS under load.

[zain]

Sure. But if the kids have a box of motors and use some as spare parts/assemblies in case something breaks. And all the motors are labelled the same from Andymark, but can have radically different counts per second/revolution that's kinda lame. Though I agree it's prolly their supplier screwing them up.

Some related questions if ya'll don't mind:

At what "level" does setMaxSpeed work? This is to say is it passing a parameter to the motor controller itself, or is it a value that lives on the RC phone? I'd presume it's a parameter used in the controller in the MR module itself, since that's where all the various RUN_MODE seem to operate. Right?

As such is it persistent in some non-volitile memory? As in, will the motor controller remember a max encoder rate value between power cycles? Or does it revert to some default value of CPS?

And whether it's persistent or not, does it work like clearing encoders and changing run modes wherein it might take a few hundred milliseconds to actually "happen" in the motor controller? So then the code would want to "set" the max, and then "get" it and make sure it has happened, before moving on?

And what is the default value? 3000-ish cps, right?


I ask all this because I've already had to referee kids on labeling sensors for which they had changed the I2C address for one robot before putting them back in the bin of sensors. If motor controllers can be set in persistent ways too, I'd just rather know. Especially if robot code is capable of doing it and not the discovery tool. I've been generally keeping every part in defaults and having the kids code around that a little (like using 0.72 as max commanded speed/power in run-with-encoders for AM motors since things are default tetrix). That way all the parts in the spares boxes are good to go and default settings. Not always practical of course.


Thanks!

- Z

[Alec]

Great questions...

The motor contoller has no way of knowing the encoder ticks per second (CPS) of your DC motor [under load], so you have to measure it and program the motor controller's PID with your measurement via setMaxSpeed().

If your OpMode forgot the CPS value it passed to setMaxSpeed(), or if you want to know the default value, you can retrieve it via getMaxSpeed().

You can automate all this by writing a "calibration OpMode" that measures the max CPS of the DC motors that are under encoder control, and saves these values to a "CPS file". Your regular OpModes can read your "CPS file" and properly set the max CPS of all the motors under encoder control.

If you have to swap a motor or just want to re-calibrate, simply re-run your calibration OpMode.