View Full Version : Motor Testing
Lancer Robotics
14-10-2008, 15:39
Some of our mentors have requested that we do our own testing of motors next season. they did not like relying on the published data (and I think they had not checked out CD) So do any of you have an easy device that you have used to get useful data on motors that we could copy and give them the data they want?
Tom Line
14-10-2008, 15:43
Well, if you attach an encoder to a motor, and use an adjustable 12V dc power supply, it should be very easy to measure RPM vs. Voltage.
After that, get a torque wrench (correctly sized) and you should be able to measure stall torque.
http://lancet.mit.edu/motors/motors3.html
I don't know what you would use but I would like to say that for any purposes in FIRST, the published data is usually close enough. I'll let more experienced members answer your question. :)
It would be an effort to do a self test and it would probably cost some money too.
-Vivek
edit: what tom said...
Kevin Sevcik
14-10-2008, 16:48
*chokes on drink* umm... I recommend just relying on the published data, unless your team has quite a surplus of money, batteries, and motors. While Tom's suggestion for getting no-load speed is easily doable, trying to measure stall torque is going to get rather expensive and hair-raising on some of the motors. Specifically, the small CIMs. If you're trying to measure characteristics at 12V, the CIMs have a stall current of 133A. Which is a lot. You'll be needing a power supply that won't sag much under this kind of load (possibly a bank of 5 FRC batteries), plus a clamp on ammeter that you trust more than the data sheets. Plus a torque wrench that you trust more than the data sheets that can actually measure torques in the range we're interested in. (21-22 in-lb for a CIM at 12V)
Now granted, you can decrease the voltage on the CIM to decrease the stall current and stall torque (mostly linearly), but then you'll have an even tougher time measuring the torque accurately enough.
And that's just the CIM. Our various other motors will all present their own problems, of course. Like the fisher-price motors being likely to melt if you stall them, and having ridiculously low stall torques anyways. Plus no-load speeds likely to give your encoder or tach fits. Or the window, van door, or globe motors, where the output is going to depend on the efficiency of particular motor's gear box.
So. It's possible to build a setup to measure all these different parameters, but it's going to be more difficult than a simple tach and torque wrench. And you're quite likely going to lose some of the motors you're testing. So, really, I think you and/or your mentors need to examine just how accurate they actually need these numbers and how many motors you're willing to sacrifice and/or beat up to get reliable numbers.
Oh, didn't I mention that? Chances are you're going to want to test multiple different samples of each kind of motor, to make sure the numbers you're running with aren't from a fluke motor that's extra bad or good. So atleast 3 samples, but 5 or more would get you better data. Oh. And the multiple runs on each motor in both directions to check for hysteresis. Plus, you'll be wanting to calibrate all your testing equipment to make sure it's giving you those super accurate readings you're looking for. Plus.... Well. 4+ paragraphs probably carries the point of how much work you'll likely need to do to get more reliable numbers that we've got as of right now.
Tom Line
14-10-2008, 17:57
Awww, come on Kevin. You're ruining the fun.
It's a fun engineering problem.
By getting datapoints in the ranges you can easily measure, you should be able to use best-fit lines to get a reasonable idea of what's going to happen.
Even free speed should be reasonably easy to figure out given you know at least 3 or 4 data points at lower voltages so you can fit a line to it.
Joe Ross
14-10-2008, 19:35
We did something similar 10 years ago, with a car battery and a torque wrench. I think the most valuable thing we learned was which motors catastrophically fail when stalled. Note that back then, the motors were not nearly as powerful as they are now.
Kevin Sevcik
14-10-2008, 20:13
Free speed is the easiest condition to measure. Stall is the tough condition to measure, unless you don't like your motors. I note that McMaster has some high accuracy wrenches with top ends of 2,5,10, and 25 in-lbs, so you can probably decrease the voltage enough to avoid blowing the CIM and your power supply and get a few data points. The FP would be exceedingly interesting, as it tops out at 63 oz-in and 70A on 12V. 35A at 6V might be safe for it, as that's only 200W. So that's one data point around 32oz-in. And then you work down from there. The window lifts declare a stall of something like 100+ in-lb, but they've got such a huge error bar on the chart that I don't know why you'd bother even trying... You'd just be testing what makes worm gears more and less efficient.
Anyways, I suppose if you have a large amount of accurate torque wrenches laying about and a good 0-12V 0-50A adjustable power supply hanging about, then it'd be a doable project.... But if you have to buy all that stuff, it's going to be a multi-grand project. I'd just as soon go with the specs as written and de-rate them by whatever you like.
Ken Patton
14-10-2008, 20:25
It's a fun engineering problem.
I agree with Tom that this could be a cool engineering problem for teams to solve.
For example, those of you who have had physics and who are familiar with constant acceleration problems... could you come up with a way to test the motor with just some inertia attached to the motor as well as an encoder attached to the output shaft?
Those of you who have a spare IFI controller lying around.... could you come up with a routine to operate the test instrumentation?
This would make a good topic for a high school or college physics/engineering project. It would make a great topic for a presentation at FRC technical seminars like the one in Atlanta avery year.
Tom Line
14-10-2008, 21:49
Heck - using a flywheel to provide the inertia for each motor, you could easily rig up the encoder to labview and have it to the charting.
The, as he said above, you could back your way into the torque curves pretty easily...
DonRotolo
14-10-2008, 22:02
A dynamometer is the device you want. Building an accurate one is a challenge (possibly beyond most FRC team's resources), buying one is expensive (again, but only money this time), so it can be solved...but is it necessary? (That is - is it a valuable use of resources?)
Rickertsen2
14-10-2008, 23:26
For anything FIRST related the published data is fine. Even if the the published figures were 20% off (which i doubt they are), you are still limited to using the motors in the KOP. In FIRST there is generally a clear best motor option for a particular mechanism. I doubt that you could even use better data. Its not like we have motors whose specs are within 1% of one another and we are trying to figure out which one to use. I cannot possibly think of any way that you would need more accurate data.
Another issue to consider is that a FIRST team has limited money and manpower resources. Your time would be better invested elsewhere.
If you are doing this to build more competitive robots i think your time/money would be better spent elsewhere. If you are doing this to learn about motors and instrumentation then please proceed. You will learn things in the process even if they are not what you originally set out to learn.
EricVanWyk
14-10-2008, 23:39
At the risk of sounding like a hack, I am sure that the good FIRST students can figure out some good enough way to produce a given torque and a good enough way to compensate for supply sag. This isn't rocket surgery, and the first order linear model of a brushed DC motor is good enough for anything we do here.
Claiming that this is too difficult for a FIRST student is simply begging to be proven wrong. I'm betting it can be done entirely with KoP items and some creativity.
A brushed DC motor is a resistor, an inductor, and a voltage source proportional to speed, all in series. Current through the motor is proportional to torque. The voltage and current constants are equal to each other.
If you can measure current, voltage, speed and torque in several conditions AND do a small bit of math, you can find these constants.
Greg Marra
15-10-2008, 00:41
At the risk of sounding like a hack, I am sure that the good FIRST students can figure out some good enough way to produce a given torque and a good enough way to compensate for supply sag. This isn't rocket surgery, and the first order linear model of a brushed DC motor is good enough for anything we do here.
Claiming that this is too difficult for a FIRST student is simply begging to be proven wrong. I'm betting it can be done entirely with KoP items and some creativity.
A brushed DC motor is a resistor, an inductor, and a voltage source proportional to speed, all in series. Current through the motor is proportional to torque. The voltage and current constants are equal to each other.
If you can measure current, voltage, speed and torque in several conditions AND do a small bit of math, you can find these constants.
This sounds familiar...
Claiming that this is too difficult for a FIRST student is simply begging to be proven wrong. I'm betting it can be done entirely with KoP items and some creativity.
I've tried motor testing before. I use the word try because the electronics were apt to blowing up while the motor was running. The underlying process is fairly simple but can't be done with only KoP items. You need a generator and a huge load bank that can handle large amounts of power. Another motor will not work (Actually tried that first) because of the fact that a generator and a motor are wound differently. The load bank is also a problem because you have to dissipate the power produced by the motor in a manner that is safe (I was working with 120V heater elements). As for measuring torque we used a torquemeter:
http://www.himmelstein.com/
Aligning such a device between the generator and the motor was a pain and it typically made ears bleed as we did not have the best ability to align the three things together. The noise was horrendous. Measuring motor speed was the easy part since it was a brushless motor. We just measured the magnet ticks off the back. I would say that most FIRST teams would not have the resources to do this. A generator motor costs a couple hundred of dollars. The torquemeter has to be fairly expensive. We were using Labview and a DAQ card to obtain the data. The load isn't necessairly a problem you just would need a hundred lightbulbs and their corresponding sockets which I guess is a hundred to two hundred dollars.
This isn't rocket surgery, and the first order linear model of a brushed DC motor is good enough for anything we do here.
I don't think it's first order though. I think it's actually third order.
Russ Beavis
15-10-2008, 10:21
I would strongly encourage teams to try testing their motors. This isn't necessarily a practical thing to do and I wouldn't expect that you'll be able to pick-and-choose motors from a sample set. HOWEVER, this can be a highly effective educational tool.
I've attached a motor model with "everything you need to know". With a little bit of differential equations and math, a nice simulation can be created using only a handful of parameters. It's interesting to note that their are really only 4 parameters of interest when specifying a motor (other than size and maximum power/current/voltage) - winding resistance, winding inductance, "motor constant" and motor rotor inertia.
Enjoy!
Russ
Kevin Sevcik
15-10-2008, 10:45
I'm not holding out that it can't be done by FIRST students. I'm simply declaring that it's somewhat impractical and uneconomical... At least doing it in any of the straight-forward obvious ways the were first discussed here. I think Ken's suggestion of using known rotary inertias plus a large amount of math and testing is the most practical solution. Given the datalogging capabilities of the cRIO, you could probably pull it off with the right instrumentation and careful calibration. It wouldn't be quite as simple as he's hoping, I think. The motor would be accelerating the known inertia of your load, plus the unknown inertia of the motor's rotor. In fact, there's a fair few parameters you'd have to account for to model the motor better than a first order approximation. And if you only care to a first order approximation, why aren't you using the spec sheets? Anyways, here's the parameters I can recall/think of:
Motor torque constant
Motor emf constant (should ideally be the inverse of the above, not necessarily independent)
Motor armature resistance (can be tested at low voltages with locked rotor)
Motor armature inductance (ditto)
Motor rotor inertia
Motor static friction
Motor dynamic friction
I know there's possibly external magnetic field losses in there somewhere, but I think those might be negligible in the motors we work with. Anyways, ignoring the resistance and inductance as separate problems, that gives you 4 unknowns, so you'd want 4 independent data points at a minimum. I'm pretty sure it could be done with at least two different load inertias, and two different voltages applied as step functions to the system. That plus some educated initial guesses based on no-load speed, etc., and you could probably get some decent values. Once you've worked out all the non-linear regression stuff you'd be needing. But it could probably be done. It'd certainly make a heck of a capstone project for any FIRSTer that needed one.
And if you only care to a first order approximation, why aren't you using the spec sheets?
Sorry. I became confused. First order approximation does not mean a first order system.There becomes a certain point where engineers just do not care and have to chop the problem down to size. The first order approximation is probably the best model to work because it still is a third order system. Any higher modeling would mean that you would get a forth,fifth,sixth order system which is painfully hard to work with. I forgot what my engineering professor said tends to be the cutoff point in which you actually need to make the model simpler.
Tom Line
15-10-2008, 11:25
I'm not holding out that it can't be done by FIRST students. I'm simply declaring that it's somewhat impractical and uneconomical... At least doing it in any of the straight-forward obvious ways the were first discussed here. I think Ken's suggestion of using known rotary inertias plus a large amount of math and testing is the most practical solution. Given the datalogging capabilities of the cRIO, you could probably pull it off with the right instrumentation and careful calibration. It wouldn't be quite as simple as he's hoping, I think. The motor would be accelerating the known inertia of your load, plus the unknown inertia of the motor's rotor. In fact, there's a fair few parameters you'd have to account for to model the motor better than a first order approximation. And if you only care to a first order approximation, why aren't you using the spec sheets? Anyways, here's the parameters I can recall/think of:
Motor torque constant
Motor emf constant (should ideally be the inverse of the above, not necessarily independent)
Motor armature resistance (can be tested at low voltages with locked rotor)
Motor armature inductance (ditto)
Motor rotor inertia
Motor static friction
Motor dynamic friction
I know there's possibly external magnetic field losses in there somewhere, but I think those might be negligible in the motors we work with. Anyways, ignoring the resistance and inductance as separate problems, that gives you 4 unknowns, so you'd want 4 independent data points at a minimum. I'm pretty sure it could be done with at least two different load inertias, and two different voltages applied as step functions to the system. That plus some educated initial guesses based on no-load speed, etc., and you could probably get some decent values. Once you've worked out all the non-linear regression stuff you'd be needing. But it could probably be done. It'd certainly make a heck of a capstone project for any FIRSTer that needed one.
By using a large enough flywheel error due to the rotor inertia can be neglected if you're willing to accept a small % of error.
Assuming you're willing to accept 5-10% error, you can neglect many of the losses (like friction) that you mention above anyway. Afterall, this is more about the process and the approximation than getting the exact industry answer.
Russ Beavis
15-10-2008, 11:56
Another interesting option with respect to software tools might be -
http://sine.ni.com/nips/cds/view/p/lang/en/nid/13853
You might be able to get an eval copy. I'm not sure whether this is fully supported by cRIO.
For educational purposes, it might make sense to brute force this without using such high-end tools.
Russ
Some of our mentors have requested that we do our own testing of motors next season. they did not like relying on the published data (and I think they had not checked out CD) So do any of you have an easy device that you have used to get useful data on motors that we could copy and give them the data they want?
One important question is, “Why do your mentors not trust the given data?”
If they would like you to do this as a “Good stuff to learn project”, I would agree it is good stuff to learn.
If they want you to do this because they feel they are getting out of spec motors or because things they have calculated should work aren’t working, there could be a larger problem here. Often teams will design systems around stall torques neglecting to remember things like friction, efficiencies…. Then those motors you are using to power a winch that should lift the arm in 2 seconds doesn’t seem to have enough torque to get it moving. I know hitting the overpass at 10 fps added a lot of stiction (it really should be a word) to our elevator.
If it is as a “Good stuff to learn project”, Ken P is right, inertia dynos are relatively simple and accurate. National Instruments used to have a $25 data Acq. System (I think it may have even been free to High Schoolers) that can be modified into a decent data system. Otherwise a tac, and a stopwatch can give you good data.
Kevin Sevcik
15-10-2008, 13:47
I know hitting the overpass at 10 fps added a lot of stiction (it really should be a word) to our elevator.Rejoice! Stiction (http://en.wikipedia.org/wiki/Stiction) might not be in Webster's, but it's a fairly common term in MechE papers.
Anyways, the Labview System ID Toolkit would definitely do most of the heavy lifting for you, but you should be careful in applying it. Waving about mathematical tools you don't have a good understanding of can leave you looking much like the Sorcerer's Apprentice.
Also, as to ignoring friction effects and swamping the rotor inertia with a larger load inertia..... Again, if you don't care about a 5-10% error, why don't you trust the datasheets? If this is a learning project as IKE proposes, then simply hooking up motors to loads and monitoring them would be fine for exploring the dynamics of how motors work, without worrying about the headaches or expense of trying to exactly model the motors.
kramarczyk
15-10-2008, 14:51
What about the case where we don't have the datasheet?
Last time I checked we didn't have datasheets in the KoP. I believe that the datasheets for 2008 were not available until a week into the season. If you have a way to determine to determine the specs for 'the new FP motor' (even +/- 10%) faster than that then it puts you at an engineering advantage.
Oh, this motor's got twice the wattage of last year’s -> drivetrain.
Yeah, there are risks with doing testing on the motors that you need to use, but figuring it out before you need it allows you to truly understand the risks and make appropriate choices. I applaud teams that take on activities like this in the fall.
Ken Patton
15-10-2008, 23:53
Of course the spec sheets will work fine (thats what we use... :)). But it is a cool problem. And it would make a great school project for someone who wants to solve it with the materials on hand.
I hope the engineers talking about how hard it is don't scare away some student(s) from taking this on. I would lobby for the best solution (one that works and can be easily replicated by others) to be asked to give a presentation at the Championship FRC Conference next April. And then I'll make sure our hybrid drive people know who you are so they can get you in for a job interview. So now, not only do you have a cool problem to solve, but you have a little incentive... ;).
Ken
Turns out it wasn't a National Instruments product:
http://www.dataq.com/products/startkit/di194rs.htm
This is a $25 data acquisition system that could be good for a project of this scope, or for other projects. They even have a link with Science Fair Ideas.
Could even be free:
"Science Fair Project Submission Form
DATAQ Instruments, Inc. is proud to offer free DI-194RS Data Acquisition Starter Kits to qualified students grades four through twelve for use in their innovative and exciting science fair projects. DATAQ Instruments will give away one free DI-194RS per month (on average) to students for use in their science fair project. All we ask is that you send us a summary and photo of you and your project at the science fair that we can place on this website. Fill out the application form below for consideration (all fields required and will be validated)."
Here is a link for a frequency to voltage unit. With a little EE work, you have a Tach to connect to the Data Logger above:
http://www.national.com/mpf/LM/LM2917.html#General%20Description
NOTE: Don't use a hotmail account to sign up for a "free" sample as they charge several dollars for shipping and handling.
Lancer Robotics
22-10-2008, 18:16
Thank you all for your input. Our mentors wanted the info so they had some information upon which they could match up the motor to the task. This past season we used motors based upon the best information available and recommendations. I think some of our gear ratios might have let us down but the motors seemed to be fine where we used them. I will pass on your recommendations.
thanks for he help
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.