DPRG
DPRG List  



[DPRG] How to protect TETRIX motors

Subject: [DPRG] How to protect TETRIX motors
From: Paul Burrell peburrell at yahoo.com
Date: Thu Feb 21 10:53:39 CST 2013

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


________________________________
From: Karim Virani <karim at compuguru.com>
To: 'Paul Burrell' <peburrell at yahoo.com>; 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] On Behalf Of Paul Burrell
Sent: Tuesday, February 19, 2013 10:55 AM
To: Karim Virani; 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.  
 
Paul
 
From:Karim Virani <karim at compuguru.com>
To: 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.  

http://www.legoeducation.us/eng/product/tetrix_dc_drive_motor/1610

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

So we need to know how to protect these motors.  TETRIX produces an optional
thermally protected wire harness for these motors:
http://www.legoeducation.us/eng/product/tetrix_thermal_protected_dc_motor_po
wer_cable/2135

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:
http://www.chiefdelphi.com/forums/showthread.php?t=89072

Greg Needle participated in that thread and posted this link to the
semi-official specs for these motors:
http://www.chiefdelphi.com/forums/attachment.php?attachmentid=9675&d=1294973
675
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,

Karim



_______________________________________________
DPRGlist mailing list
DPRGlist at dprg.org
http://list.dprg.org/mailman/listinfo/dprglist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.dprg.org/pipermail/dprglist/attachments/20130221/036ceab6/attachment.html 

More information about the DPRG mailing list