I was just looking at this motor and it's associated shaft encoder -- the motor spec says "Torque: 0.78Kg-cm (rated load) (10.83oz-in)" -- what does this mean in real terms? Could three of these power my robot if it weighed say 10 pounds?
Also to note you may need more power to get up a bump in the road and such. As to your motors, and torque in general. Torque is a simple force times a distance. So if you had a wheel that had a diameter that was ø1" and it took 2lbs of force to get it going, then you would need a motor with 2in*lbs of torque (sometimes also written as lbs*in). As to which motor is stronger, you will just need to do the unit conversions (actually cancel out the appropriate number of zeros) to get to N*m (Newton*meters).
@ Max. Ref your query on comparing motors. Change to a common system of measurements, I prefer metric in this case and N.m, Using Newtons work of Force= Mass x Acceleration (F=ma) convert 0.78kg to Newtons by muliplying by g (accelation due to gravity 9.81 m/s/s) this gives 7.65N-cm. Then convert cm to m by dividing by 100, 0.0765N-m then multiply by 1000 to get mN, hence 76.5mN-m, so motor 2 is better by 2.5%. I've been racking my brains to remember the formulae to calculate the speed/accelaration to weight section, but it currently escapes me.
That encoder is just a US Digital E4P with the proper sizing for the motor's shaft. Another option if you need higher resolution is CUI's AMT encoders, which are <$30 at Digikey. With encoders, you have to match shaft size, mounting holes (or sticky tape), output format (quadrature / sin-cos / serial, single ended / differential, etc), and speed (which won't be an issue in your case). Most (all?) E4Ps are single ended quadrature output.
Next questions, how are you going to read the quadrature encoder? If you use interrupts, you'll be severely limited in speed. Another approach is to convert quadrature to up/down and connect to a counter. Also, there might be encoder input shields available. (Side note: another reason why the BeagleBone is so nice, it's got three quadrature encoder inputs built in)
@TonyTib: Next questions, how are you going to read the quadrature encoder?
Duane Benson is working on something that is so exciting it makes me want to squeal like a school girl. Duane and I will be writing about thsi in the not-so-distant future. Suffice it to say that it can be used to address this issue.
Hi Max: I can certainly say that Crusty knows nothing about robot building, but I do wonder about why you need a shaft encoder, and would that be three? one per wheel?
It seems to my mind that DC motors of the old school have comutators and that you can count the number and speed of segments being powered to determine shaft rotation speed. I did this years ago with a guy called John Ewins for a motor speed controller, for a very accurate tape cassette recorder. Design was published in Wireless World probably 35 years ago.
If you are using stepper motors then you know how fast and how many steps you are sending to the motor.
So why the shaft encoder? It will not give any more information about wheel slip versus distance, or does it? and you are still going to have to count the pulses in the Arduino code.
Though I would drop this in as everyone is helping you on the motors at the moment.
I will be going through similar problems as I am going to try to make an XYZ axis plotter with a lazer head, which will write PCB etches direct to photo sensitive resist coated euro boards.
Any one up for a Kickstarter project with me on this, or has someone got there before me?
> "an XYZ axis plotter with a lazer head, which will write PCB etches direct to photo sensitive resist coated euro boards."
> "Any one up for a Kickstarter project with me on this, or has someone got there before me?"
I'd be in if I could afford it - damn good idea! I got some goodies which were used for writing on drawings - they held a pen and had an X-Y drive and a solenoid to lift / lower the pen. I thought about modifying them - putting a small motor and mill on it but it would weigh too much - drawing pens are pretty light. However a laser diode is a different matter. Also though the X drive was a good few inches the Y drive was only about an inch at the most - enought for writing one or two lines of text. So only very small PCBs. You've obviously given this a lot more thought. Let me know if you get any further with it.
I have been thinking about this for some time. 30 to 40 years ago, I got to like XY plotters when I worked in the LTE labs, where I programmed one to work of an Apple IIe, sadly the plotter is long gone, but I do still have a working Apple IIe.
I am think that XY tables are now coming down in price, so it would be worth a look at using a lazer instead of a fibre pen, to draw on a sensitised surface.
Do you think Max might loan me his 3D printer? It has XY an Z axis movement and the lazer could go in place of the printer head?
Well thats another avenue of research using the cheapest 3D printer, instead of a milling table, which has the greast accuracy?
Your little plotter would be good, now the size of components are shrinking?
What type of laser do I need? Can I use a CD lazer with its constant focus tech.
How do I get my Mac book to spell check on these post boxes while typeing.
I am afraid I can't answer all your questions.....
- I don't know where you would get an x-y table, but I guess you could get such a thing somewhere...anyone know where?
- I think you'd have to wait a bit before Max will lend you his 3D printer, especially if you want to cannibalise it, but you could always ask :-)
- by a happy coincidence I have two of my little writers. They have a couple of steppers in them for X and Y motion, and a solenoid for Pen up/down. And a uC board for driving them. And a keyboard for inputting the text. It would be a simple matter to rip out the guts and connect the Steppers / Solenoid to something else. If you're serious about this and would like one, I'll send it over....not sure how much the postage would be but it couldn't be worse than the parcels we send to the wife's mom in Zimbabwe.... Let me know.
- If it's a true laser you wouldn't need to up/down it, just turn it on and off. What you would have to worry about is the beam size compared to the step size, the beam intensity and time to correctly expose a "pixel", and whether the sensitised PCB is sensitive to red light (they usually want UV - can you get UV lasers?) You might be able to get a UV LED and focus it with optics....
- There does not seem to be a spell check in these post windows. I can spell, but my fingers don't seem to have mastered it.....
@David : I think I have the XY table worked out Proxxon Micromot KT 70 MICRO Compound Table £79 to £86 It gets good reviews from the scientific comunity for accuracy in optical and microscopy usage. Probaly has enough travel to suit the boards I want to make. easily converted to CNC control.
@David, Yes a limited bed size, but as a test bed for the idea it has everything going for it. Even the ability to put in the drill holes.
And it will also fit on my lathe and vertical drill so I get the best of both worlds if the idea is a failure. As luck would have it my Kistarter backing for Microduino presents me with a Microduino stepper kit for 3D printing, so the table can also work for small part printing.
I shall order the table today and wait for all the other bits to come together. Looks like much of the glue circuits will be on Veroboard which is always my fall back PCB.
Thinking about it, I can always put the table to work as a micro milling cutter and mill some circuit boards straight from the copper.
Will try everthing out with and up down fibre pen and paper before moving to a board.
I can see that this is going to turn into a Crusty Bits blog at some stage. Watch out Max!
Life got hectic when I started to rebuild my old UK101 in an FPGA, little did I think I would be looking at home PCB manufacture.
@Crusty: So why the shaft encoder? It will not give any more information about wheel slip versus distance, or does it? and you are still going to have to count the pulses in the Arduino code.
First of all there would be three shaft encoders -- one per wheel. Depending on your motor, you can mount them on the back-end of the shaft (before the gearing) or on the output/drive shaft (after the gearing).
The main reason for having them is to provide another way to measure what the robot is actually doing compared to what it thinks it's doing. Also, there's the point that we have the three motrs, so the way they are mounted means that even if we are going "forward" (say an axis from the center directly betwen two of the wheels -- see my previous blog on this topic), a complete rotation of the wheel doesn't actually equate to the robot travelling the same distance as the circumpherance of the wheel.
Don't worry about my Arduino spending all of its time counting pulses from the encoders -- it won't be spending any time doing this -- based on Duane's current "Secret Squirrel" project, all of the boring counting stuff will be off-loaded to distributed sensor processors ... we'll be talking about this more soon...
@Max Crusty speaks for me too on this one - what did you want to do with your shaft encoder data? If for speed control or distance measurement you'd get some inaccuracy from slippage - especially if your wheels could be driving at other than 0 degrees to the direction of travel? And I seem to remember you were going to have an on-board accellerometer? From which you could get fairly accurate measurements for speed and distance? Speed control from an accellerometer would (to me) be a fairly horrifying conrtol system to implement, but I seem to remember also that you got your degree in control systems, so to a man of your abilities this should be a mere bagatelle?
For a three wheel robot like that, especially running on carpet, I prefer to use a pair of optical mice for movement feedback. It is better if you can use a relay lens to space the mouse sensor up from the floor a little.
@Douglas: For a three wheel robot like that, especially running on carpet, I prefer to use a pair of optical mice for movement feedback. It is better if you can use a relay lens to space the mouse sensor up from the floor a little.
Tell me more (like whats a "relay lens") -- can you email me at firstname.lastname@example.org?
A relay lens is a lens or lens set that replicates an image on a different imaging plane with little or no modification. http://en.wikipedia.org/wiki/Relay_lens A borescope is an extreme example.
In this case a double convex lens can focus the floor on the optical mouse chip without having the chip too close to the floor. I once built a sensor to track the slimey encrusted bottom of a ship for a ship hull inspection robot where the lens also sealed against seawater and provided a 3:1 optical motion reduction so the robot could go faster than the mouse wanted to track. The robot wheels tended to slide on the hull but the optical tracker could track without touching.
@David: And I seem to remember you were going to have an on-board accellerometer?
Yup -- also gyroscopic sensors and a magnetometer. Also ultrasonic range sensors. However, talking to Adam (Aeroengineer) yesterday, he pointed out that untrasonic measurements can be affected by temperature and humitidy, so I'm going to have to have those sensors also. Since this is just a platform for me to play with, I'm going to load it with sensors and then get the robot to use whatever is most appropriate for what it's trying to do at the time (mostly this will involve sneaking up behind the dog and then making a loud noise :-)
Now there's a conundrum: how to squeal without offending Susan??
I've heard of stuck pigs being used for this purpose, but we'll probably offend the animal rights lobby....
And tyres (oops...tires) squeal as well when pushed. But they don't evoke the same sense of excitement.
So I think we're stuck with schoolgirls. Did you never squeal over your favourite pop idol, Susan? Even if you didn't, I reckon the fact that Max and Caleb squeal over Keepon gives you plenty of ammunition for having a dig at them in the future :-)
Hi David: LOL. The pig did cross my mind. (As in male-chauvinist...ha ha.. I could not resist that one.) I don't want to distract from the topic anymore, but I'm just saying that school boys can squeal as much as girls, and some of them even have higher voices for a time. And yes there are usually electronics involved when boys squeal. (I know...I gave a coworker an Enocean energy harvesting dev kit. She came back the next day and said her teenaged son squealed and didn't want to go to the concert or sports event that night with his dad. He wanted to stay home and tinker with the dev kit.)
While bowties are cool, I prefer more the pinstripe suit and a long overcoat. That aside to things of lesser importance, motors. DC electric motors are not that bad if you can get a few numbers out of them. The two main numbers that you will need are the Stall Torque and the No Load Speed. From there I plot that data on a chart with RPM on the x axis and torque on the y axis. The line between these two points represents the operating capacity of the motor. I generally try and keep the motor operating under 30% of max torque for continuous duty operations with brief moments in the 50% torque range. This will keep the motors happy. You can go higher if you have active cooling on the motor. With this in hand, you will then need to determine the amount of torque that is needed on each wheel. Because you are going to loose some efficiency in each wheel (most likely each of these wheels will be around 50% efficient in transmitting torque to the ground). This should give you some general sizing parameters. You would have to do some hand cranks assuming an acceleration rate how much torque would be needed to be delivered to the wheels, but this should give you a starting point.
Unfortunately, I have not any background on motors dynamics, and torque specs are like black magic for me :-(
Having said this, thank you very much for the detail photo of the wheels. When I read your previous blog, I was wondering how the robot was going to deal with the "dragging" force of the remaining perpendicular wheel when moving in a straight line. Now the mechanism is crystal clear!!
No worries. I really love DC and BLDC electric motors. I have dedicated some amount of study to them. DC electric motors are easier to understand and easier to control, but BLDC motors offer more power density and usually they have better efficiencies. This is not always the case, but it is a good generalization.
One thing, though that I have found by creating the simple chart that I described is that you can then you can back out how much torque you are actually using and then size your next round of motors more appropriately. If you take your current motor and make that chart, and then you put the motor under the worst load that you are expecting, you can then measure the RPM of the motor (assuming that you have an encoder and some way to record this). Once you have this RPM, you can go back to the chart you created and just fine on the line the value of the RPM. You then read on the Y axis the torque. Now you have a better estimate for your next round of motors.
Oh and did you get my email on how to solve your motor adaptor problem? I think that it will work for you. Let me know if you need any help getting that drawn up. I can help out with that.
Aero - I've got a motor I'm dealing with (the one I emailed about) that produces 8.5 inch pounds of torque. The limited data I have gives a current of 16 Amps. I'm assuming that's stall current, but it doesn't say.
One of the challenges for me is translating the weight of a robot into power required to move it. It would have to consider weight, rolling resistance, desired acceleration a dn any amount of slope I might want. I suppose I qould emperically determine how much force it takes to move something, but that means I can't really design it until after I've designed and built it.
I'm not sure about a plastic adapter (from 4mm square shaft to something round). I don't know how well the plastic would hold up. Short of getting a piece of metal machined, I just had another thought. I could get a pair of flat L brackets and bolt the together suchb that they have a 4mm square in the middle and four ends sticking out that I could then bolt to a wheel or something. Does that sound workable?
@Adam (a.k.a. Aeroengineer): Oh and did you get my email on how to solve your motor adaptor problem? I think that it will work for you. Let me know if you need any help getting that drawn up. I can help out with that.
Are you talking to me or to Duane (I haven't checked my email yet today)
Max - I've bought a number of motors from Surpluscenter. They have a pretty wide variety. Ov course, since they're selling surplus, you never quite know if you'll be able to buy the same one twice. But they have a good selection and ship things pretty quickly.
These typically resolve the position of the magnet to at least 256counts , and usually use I2C or similar. You can daisy chain the chips with SPI too. These are good, but can be finicky about spacing above the magnet.
This magnet could go on the wheel.
Alternatively if you use a 2pole magnet, you can use a magnetic compass chip, and this can be about 10mm away from the magnet, which might help in your geometry, I've used a magnetic compass chip this way, as a proof of concept for retrofitting the Austria Microsystem chips as an upgrade to reed switches.
Off the shelf linear actuators almost always use a 2pole to 6pole ring magnet attached to the motor or a gear shaft with a screw through the middle. And then standard hall effect switches.
Note if making your own , you must use "Latching" hall effect sensors
I also did a batch of about 100 of gluing encoders to the back of a gear motor,
(insert picture here???? the upload image from computer button has dissappeared?)
This had a 4mm stub shaft sticking out the back of the motor. You take a "Diametrically polarised" disc magnet (about 5mm across) , pick it up with bamboo tweezers put a pinhead of polyurethane on the magnet, then place it on the slowly rotating motor shaft, give it a nudge with the tweezers and it will centralise. You then put two half-pea sized globs on the PCB and push it onto the rear of the motor, and secure with a rubber band while the PU sets. The power is on all the time, so you should see both LED's flashing.
These don't usually work on the type of gearmotor you have there, as the motor shaft is flush on this motor style.
You can just take some of the 3 leaded Hall effects, solder them to a bit of veroboard, and glue this on the motor, The magnet/hall effect combo is quite tolerant of positioning. (Unlike slotted disk optos)
Ok Doing the Quad encoder in Firmware
(a) There is a booby trap in the way Atmel do the pin change interrupts, while you can get a pin chnage interrupt on every single pin, in practice there are only 4 pin change interrupts, one for each port, i.e. A , B,C,D. So you must hook up the "A" channel of your first motor to say any of the A pins, and the "B" channel of your second motor to say any of the B pins, and the third one to any "C" pin. The "B" encoder channels can go aon any pin.
(b) The PCI is set up to go off for any change on hall effect A , so all the ISR has to do is add one if hall effect A and B are both the same , or subtract one if different.
Here is some sample code:
Ew_pulse_isr: If Ew_quad_b = Ew_quad_a Then Ew_position_long = Ew_position_long - Ew_step_long Else Ew_position_long = Ew_position_long + Ew_step_long Return
Note you also get a free "multiply by scaling factor" thrown into the above!
in my case Ew_position_long is a fixed point representation, where the top 16bits are the sun angle in minutes, and the bottom sixteen are the fraction, (so you just map the top 16 bits as an integer and ignore the fraction) the scale factor is embedded in Ew_step_long which equals 8509 with my particular gearing, this is basically a fraction i.e. 8509/65536 = 1/7.7019 , so in my case I move 1 minute (= 1/4 of a degree) with 7.7 counts , and as there are two counts per revolution, this is nearly 4 turns on the motor.
My Mom the Radio Star Max MaxfieldPost a comment I've said it before and I'll say it again -- it's a funny old world when you come to think about it. Last Friday lunchtime, for example, I received an email from Tim Levell, the editor for ...
A Book For All Reasons Bernard Cole2 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...