[FTC]: Encoders on new Andymark motors.

[PhilBot]

I was really excited about the new andymark motors that we are allowed to use this year (Game Manual 1).

However, I see that the encoders only give 280 pulses per shaft revolution (PPR). The old encoders give 1440 pulses per revolution.

So the old encoder would be giving 3600 pulses per second at full speed , and the new encoders will be giving 700 pulses per second at full speed.

By my reckoning this will totally mess up any chance that the motor controllers have of achieving the correct requested speed, and subsequently cause all sorts of overshoot when attempting to "run to position".

eg: if I ask for 10% speed, I'm going to get %51 speed. Because the motor will keep speeding up until the pulses get as fast as expected.

I guess if I limit my speed requests to 20%, I'll get a proportional range, but I KNOW it's going to mess up the PID position controller since the gain will essentially be 5 times higher.

Does anyone at Hitechnic know if we can use the "gain" settings in the motor controller to compensate for this much-reduced PPR?

[emmell]

Phil:
I think you'll have to contact AndyMark instead of HiTechnic since it's there motor/encoder.

[Scott_4140]

Originally Posted by emmell

Phil:
I think you'll have to contact AndyMark instead of HiTechnic since it's there motor/encoder.

AndyMark is not going to change the encoder at this point. Beyond that, there's not much they can do. They essentially provide an input.

The PID is buried in the firmware of the HiTechnic motor controller. Hopefully, the "gain" or another hook can compensate. It may take some combination of the HiTechnic firmware and code in either LabVIEW or RobotC.

[Sasha]

Or you can just write your own PID. In fact, for position control it suffices to use proportional control (P of PID), and the code is quite simple - this is what we are doing.

[PhilBot]

Thanks for the replies.

I did also contact AndyMark, but I suspect they may say "Oh Well". I was hoping they have worked with Hitechnic to figure out a work around.

I'd like to buy 20 of these motors for my two teams, but if the encoders don't help... it's no bargain.

Doing our own PID is possible, but since one of the most unreliable parts of the FTC system is the NXT <-> Motor controller interface-comms (an NXT problem) adding hundreds of more commands back and forwards seems like asking for trouble.

We do some of this for "Run to position" but I would really like to be able to use the constant speed control mode without having to add a lot of CPU cycles.

Still hoping for some inside help.... I've done a lot of work with the internal Motor Controller registers. These are "gain" values in there, but the docs say to leave them alone...

Phil.

[PhilBot]

Originally Posted by Sasha

Or you can just write your own PID. In fact, for position control it suffices to use proportional control (P of PID), and the code is quite simple - this is what we are doing.

But when you are doing that, are you running your motors using the constant speed or constant power setting? I would assume you are using constant speed to overcome varying drag and friction etc. If that's the case, don't expect constant speed to run smooth anymore. It will probably hunt up and down.

Phil.

[BSV]

So has anyone been able to test out the encoders, yet?

We've ordered the motors, but the encoder wire wasn't available, yet (hopefully it can be ordered tomorrow). There is a hack available to get it to work, but we've got other stuff to do so we can probably wait a few days.

I started mentoring some FTC teams this year, and apparently they've never used encoders before (at least not recently - I found a couple but they were damaged). The FLL kids who have moved up to FTC this year are wondering how the heck the previous teams built a robot that doesn't have any sensor feedback.

[Sasha]

Originally Posted by PhilBot

But when you are doing that, are you running your motors using the constant speed or constant power setting?

Constant power.

We were doing things in a very primitive way, without using Tetrix controllers built-in PID (in motor setup tool, PID box was unchecked). Probably the speed was not constant, but we never noticed any speed variations as long as the battery was charged, and "going the set distance" function was working quite reliably, with the accuracy of about 1/2 inch.

One of the reasons was that initially only 1 out of 4 drive motors was equipped with encoder (because we didn't have enough encoders). After that, it was "do not fix what is not broken".

[CougarRobot]

Interfacing the new AndyMark NeveRest Motor with the HiTechnic Motor Controller

We have tested the new AndyMark NeveRest Motor and it works well with the TETRIX/HiTechnic Motor Controller. Here's what you should expect and what you need to do to make it work the way you want on an FTC robot. We will use motorD as our motor in our examples.

First we need to agree on some terminology. The TETRIX shaft encoder used with the TETRIX motors is a US Digital e4P with a 360 degree encoder wheel. Model E4P-360-236-N-D-H-D-B. To use US Digital's terminology it produces 360 Cycles Per Rotation (CPR) or 1440 Pulses Per Rotation (PPR). It is a quadrature encoder producing 4 Pulses per Cycle. In FTC use, with ROBOTC, it will produce 1440 PPR, ticks, or a count of 1440 in nMotorEncoder[motorD] per revolution.

The AndyMark NeveRest motor's built in encoder produces 280 cycles per revolution (CPR). We tested it. As expected with 280 CPR, it outputs 1120 PPR, ticks, or a count of 1120 in nMotorEncoder[motorD] per revolution.

So, here's the only tricky bit. The NeveRest motor’s 1120 PPR is only approximately 78% of the TETRIX Motor’s 1440 PPR. You need to adjust your range when running under PIDControl from 0-100 down to 0-78.

The HiTechnic motor controller expects 1440 PPR and is "tuned" to drive a Tetrix motor at about 150 rpm when using PIDControl and a commanded speed of 100% motor[motorD]=100;. That is, the motor controller will up the power as necessary to try to achieve 3600 Pulses per second when commanded to run the motor at 100% speed, or at about 1800 Pulses per second when commanded to run the motor at a speed of 50%.

At full speed, 150 rpm, the NeveRest motor encoder will only produce 2800 Pulses per second. Using the 1440 PPR Tetrix motor with shaft encoder will produce 2800 ticks at 78% speed or 117 rpm. Since the motor controller will try to adjust power as necessary using the built in PID to achieve the correct speed, a speed setting of 78%, i.e. motor[motorD]=78; will achieve full speed on the NeveRest Motor. Likewise, a speed setting of 39, motor[motorD]=39; (½ of 78) will achieve approximately 50% speed on the NeveRest motor running under PIDControl. Any speed from 78% to 100% will cause the controller to run the motor at 100% speed. Please keep in mind that this only works this way under PIDControl and not under openLoop. Under openLoop mode you are just passing a percentage power to the motor controller and you will need to revert to using 0 through 100 for your power levels if you want to get full range & power out of the NeveRest motor.

[ftcTeam6389]

Thank you very much for this info @CougarRobot! Very helpful!

- - - -
Rachel
Team Captain
FTC Team #6389 - "The LazyBotts"

[Jay Clayton]

Team #7060 Fried Fuzes , would like to know if anyone using the NeveRest encoder cable, black end will not fit in the Motor Controller. With some trimming of the black plastic it will fit. BUT what is the proper direction in the MC ? Can anyone tell us what are the pin colors of the encoder port ? Yellow pin on the inside or outside , black end goes in MC both ways .

Thanx , Confused and Frustrated #7060

[PhilBot]

Hi

The Yellow wire is nearest to the outside of the Motor Controller.

Phil.

[Jay Clayton]

Originally Posted by PhilBot

Hi

The Yellow wire is nearest to the outside of the Motor Controller.

Phil.

Thanks for everyones help ��

[Sasha]

Image from AndyMark page

[dcribbs]

A couple of questions concerning using the AndyMark encoders on the NeveRest Motors with the new MRI controllers.

1.Which set of encoder wires work best (or with the least modification)?
a) am-2965 both ends white connectors
b) am-2992 one black, one white connector


2.What is the correct orientation for the encoder cables to plug into the new MRI controllers?

I read the above posts about the built in Hi-Technic controller. Has anyone had issues with the new MRI controllers? Any advice on using the encoders with autonomous?

Thanks for your help!