DPRG List  

[DPRG] How to protect TETRIX motors

Subject: [DPRG] How to protect TETRIX motors
From: Karim Virani karim at bigthought.org
Date: Thu Feb 21 14:23:34 CST 2013

Nice idea on switching gearheads with encoders still attached.  Might even be able to do that without dismounting the gearhead from the clamp?  Sounds way less error prone.  I always monitor encoder disk pulls with angst.

Should have of thought of the emergency stop on the controller.  It was such a short season for us - beginning in December after FLL.  Time for reflection at a minimum.

Cool idea for blacking out either fore or aft to simplify, though in theory our hope was to shuttle back and forth without much turning since the arm can go past vertical.

From: dprglist-bounces at dprg.org [dprglist-bounces at dprg.org] On Behalf Of Paul Burrell [peburrell at yahoo.com]
Sent: Thursday, February 21, 2013 12:29 PM
To: Karim Virani; dprglist at dprg.org
Subject: Re: [DPRG] How to protect TETRIX motors

I wanted the kids to do an elevator to keep it simple.   They really wanted to do a multijoint arm.  So, I let them do it.   My team is three sixth graders and one seventh grader.  The arm stuff worked out pretty good.   Three joint arm (shoulder, elbow, and wrist, all single DOF).  They spent about 3 weeks refining poses and motions between all poses.  We have a 21 X 21 test matrix for the arm.   There is a driver and a ring manipulator.   Once you understand the control, it is really easy to do all of the arm motions.   It is all about the practice, but you already know that.  They can blackout one side if they have a near perfect match with little defense.   The top row is also fitted with double rings.

As for motors, we were warned about that from a previous team.   I also had some experience with the minibot competition with FRC.   We have 4 brand new motors still in the bags as standby.    I think the real thing that helped us out from burning up motors was to have an emergency stop button with a motor control task.   If they see anything unexpected, they quickly hit the emergency stop before there is an opportunity to burn the motor out.   Most of our recent issues have come from using the encoders.   If the encoder fails (we had a broken wire on one), the software applies additional power trying to hit the target.   You can quickly see that it is not moving as expected.   We have since fixed the cable and it is running smoothly.

As a side noteon replacing motors, make sure they are accessable quickly.  If it has an encoder on it, the easiest thing to replace the motor is to move the gearhead and move it.   You have to remove the 2 screws for the encoder, twist it to access the 3 bolts.   Move it over and reasseble.   If you try and remove the encoder, most people don't understand how fragile they can be.


From: Karim Virani <karim at bigthought.org>
To: Paul Burrell <peburrell at yahoo.com>; "dprglist at dprg.org" <dprglist at dprg.org>
Sent: Thursday, February 21, 2013 9:55 AM
Subject: RE: [DPRG] How to protect TETRIX motors

We have about the same wiggle room with rings as you since we have a simple overhead hinged freely swinging open slot bucket for holding the rings.  The team calls it their Ringamagig. The rings almost want to fall into place. We found a variant of it online - so not our original idea.  We might have more accuracy than needed.  Once the 2-joint arm stabilizes, it's usually pretty steady.  And the whole arm is mounted on a vertical linear slide that gives us much more accurate vertical positioning over about a 9" range.  Our problem has been more with driver control.  It's a very complicated setup with 5 degress of freedom (rookie wisdom) and it came together way too late.  Like the day before our qualifier.  No time for drivers to learn our complicated joint-by-joint controls.  IK would have simplified the controls hugely but proved out of reach at their age.  Their current plan is to provide preset shoulder, elbow and wrist positions for the dispenser and 3 rack heights.  Most of the programming is done, but we can't test/refine until we get more motors.  Expecting them today or tomorrow. We hope to demo the presets at Tyler, but if it doesn't happen we'll disable the arm for safety.  Full manual control in the hands of a 6th grader is outright scary.

BTW - didn't enforce KISS because this was an exploratory year for us.  So we designed for ambition, not practicality.  Costly choice, but good lessons learned.

From: Paul Burrell [peburrell at yahoo.com<mailto:peburrell at yahoo.com>]
Sent: Thursday, February 21, 2013 10:53 AM
To: Karim Virani; dprglist at dprg.org<mailto:dprglist at dprg.org>
Subject: Re: [DPRG] How to protect TETRIX motors

I am not sure of the legality of putting limit switches inline with motors.  Based on FRC, I would think it is not legal, but FTC does have some interesting differences.

We saw some of the same twitching at the end as well.  I am not sure of the exact implementation, but I think that the software team put a deadband in place as well when they were waiting for the task to complete.  If it was in the deadband  but didn't stabilize after 3 secs, they stopped the command and delt with the position is was left.    The arm had about a 1.5" flexibility zone in which rings could always be "forced" to go on with our implemenation.  We allows for that when we designed the system knowing that positioning would not always be perfect.


From: Karim Virani <karim at compuguru.com<mailto:karim at compuguru.com>>
To: 'Paul Burrell' <peburrell at yahoo.com<mailto:peburrell at yahoo.com>>; dprglist at dprg.org<mailto:dprglist at dprg.org>
Sent: Wednesday, February 20, 2013 9:23 PM
Subject: RE: [DPRG] How to protect TETRIX motors

I saw some posts about replacing or bypassing those inductors in some FRC threads in the year of the minibot.  They were pushing those motors to their max.  Haven’t tried replacing one yet – like you discovered – the exact part seems to be obtainable only by harvesting from a TETRIX motor…

I take your point about getting what you pay for.  The portescap and pittman motors I have are rock solid.

Yes we likely need to add physical limit switches in series with the motor power cable.  That would be good insurance.  I just didn’t know that would be legal.

We avoided using the motorencodertarget command because of the bug but continued avoiding it after the fix because the point at which it would terminate was very unpredictable.  It would get near the set point and then spend a variable amount of time shifting around in the hold condition.  Probably would work fine for driving, but for our arm it was unpredictable.  We went with PID so we could control our own constants.  Our PID setup works pretty well now – except when we get careless with code changes or startup conditions.

From: dprglist-bounces at dprg.org<mailto:dprglist-bounces at dprg.org> [mailto:dprglist-bounces at dprg.org<mailto:dprglist-bounces at dprg.org>] On Behalf Of Paul Burrell
Sent: Tuesday, February 19, 2013 10:55 AM
To: Karim Virani; dprglist at dprg.org<mailto:dprglist at dprg.org>
Subject: Re: [DPRG] How to protect TETRIX motors

The tetrix motors have a series inductor built into the motor.  When the motors smoke (and i do mean smoke), this is the common failure point I have seen.    You can open up the motors and replace them.  See chiefdelphi for information on the inductor.  The motor is really never the same, so if you are going to use it for competition, it might not perform as expected.  Also, FIRST requires that the inductor be replaced with the exact part.  Since they don't tell you what it is, I am not sure it would be legal.

The exact purpose of the fuse is not quite clear.  It ends up acting like a non-replacable fuse.

As for the motors, yes, they are not great, but what you you expect for $30.  Good motors with gearheads new cost more like $100 to $300 in low volume.  Until you ever use a really good motor, you don't know what you are missing.  It put companies like portescap, maxxon, fauhauber, etc in that category of motor.  You can apply a very low voltage and watch the motor shaft with no load move at 1/4 rev/s without jerking or stalling.  Try that with cheaper motors.  Most of the good ones are 7 to 11 pole motors.  Some of them are coreless.  With DC motors, you do get what you pay for.

As for using the encoders as limits, that is just the first line of defense.    The motor controllers/NXT are not exactly the most responsive system.  We ended up putting limit switches as a secondary protection.  We smoked 2 motors early in the season, but have not done so since.    There was also bugs in RobotC 3.51 with the motor target command.  They seem to fix it in 3.54.

Hope this helps some.


From: Karim Virani <karim at compuguru.com<mailto:karim at compuguru.com><mailto:karim at compuguru.com<mailto:karim at compuguru.com>>>
To: dprglist at dprg.org<mailto:dprglist at dprg.org><mailto:dprglist at dprg.org<mailto:dprglist at dprg.org>>
Sent: Monday, February 18, 2013 2:44 PM
Subject: [DPRG] How to protect TETRIX motors

So I've grown to love/hate TETRIX as a prototyping system for robotics. VEX
might be better - I'm not in a position to judge, but we went with TETRIX
because it continues our investment and experience in NXT hardware and
sensors.  Mostly, (expense aside) I think it's great.

My biggest beef with the platform, though, is the motors.  The standard DC
motor is called a 12 volt and is meant to run off a 12v nominal NIMH battery
pack, which usually runs 14v on a fresh charge.


These motors burn out easily.  My robotics team has just burned up its 6th
motor. At 30 bucks a pop this feels like a racket.  They burn up within one
second of hitting a stall condition.  In my book, I don't think these motors
should be rated for 12 volts if they're going to burn up that fast.  I don't
think they'd ever be considered in the automotive industry.  Am I off target
with this opinion?

None of the motors driving our wheels has had a problem - the wheels will
typically lose grip before stalling the motors.  The motors used on our arm,
though, are susceptible to stalling when the end of travel is hit.  We have
encoders on the motors and have profiled the arm's legal limits and have
those limits built into the software.  But remember that I'm working with
middle school kids who are still learning and far from cautious.  Limits
have been disabled by errors in coding and/or by invalid startup conditions.
And the limits don't help when getting stalled by other barriers in the

So we need to know how to protect these motors.  TETRIX produces an optional
thermally protected wire harness for these motors:

These are actually supposed to work more like a circuit breaker.  They are
supposed to reset automatically once the power goes to zero.  They did
indeed protect the motors.  But in our experience, after they've been
triggered once or twice they begin to progressively drop the voltage to
levels where the joints might barely move. This behavior, before it was
understood, cause havoc with our attempts to tune our PID constants.  So
they're actually more like expensive disposable fuses.  I'd rather figure
out a cheap and reliable fuse to try out.

So as a software guy, I'm pretty clueless with electronics.  I'm not sure
what we need.  I believe fast blow fuses aren't right for inductive loads,
but a slow blow might be too slow to protect these fragile motors.  I want
something that trips within half a second (or less) at stall but otherwise
permits the motors to drive well above no-load conditions. Are there medium
speed fuses?  Is that something Tanner's would carry?  What values should I
choose?  Is there some other kind of option?  AFAIK there is no current
sensing ability in the HiTechnic motor controllers - and it likely wouldn't
be legal in FTC to add such circuitry.

Here's a thread that has some specs for the motors:

Greg Needle participated in that thread and posted this link to the
semi-official specs for these motors:
note how they didn't measure but rather extrapolated the stall figures.  I
can't actually say what load will fry them.

Thanks for any and all advice,


DPRGlist mailing list
DPRGlist at dprg.org<mailto:DPRGlist at dprg.org><mailto:DPRGlist at dprg.org<mailto:DPRGlist at dprg.org>>

More information about the DPRG mailing list