Motor interface electronics



While I agree with your point...
I have to wonder about this mythical $5 microprocessor. I'm beginning to suspect they are phantoms that don't exist.
I've had folks mock my products, imply I'm price gouging, and say they could do the same thing with a $5 micro. Hear it all the time.
Of course, that's what they say. But instead, what they do... they never do anything. They never show anything. They never build anything. Just another good project idea gets killed by the mythical $5 micro.
Sure, I can even get a $.70 68HC908 that could probably do better motor control than a whole PC with an OS could do, but, it doesn't have a program in it, and it isn't $5 once it's on a board and in a system. Whosh! The phantom disappears again.
I think we're hurting ourselves (robotics community) by believing in the mytical $5 microcontroller. This is an interesting enough point to me, I think I'll start a new thread about it.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Randy M. Dumse wrote:

Might be a good idea about the separate thread, but in my particular experience, $5 is about right, including a small board and external parts. The AVR AT90S2313, while not the most powerful microcontroller in the world, does an excellent job as a main processor for little robots, and a subprocessor for larger robots. It's routinely available for about $3 to $3.50. (There are others, with more I/O like the '1200, and the Tiny and Mega lines; many are under $5 and almost all are under $10.)
While I happen to use a STK500 programming board, you can program these from your PC with just a few wires and some resistors. I happen to like Bascom AVR for its simplicity, which you can get for free if you're happy with the 2K program limit (usually suffices for most subprocessing jobs) there are all sorts of C compilers available for it, some free and others not so free.
There is a place for every type of microcontroller architecture. I wouldn't dream of asking a '2313 to do the things your Iso products do, for example. Apples to oranges, IMO.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

In most PC operating systems, he IOS is not used after boot.

Why would I need to?

Because if I can eliminate the $5, thats less that people need to buy.

Not at all.

OK.
Perhaps, but the sub $500 robot has a tight budget.

I haven't missed them, I disregard them.

There are number of point that seem to be missed:
The sub $500 robot costs no more tan $500 dollars to build. The only assumptions are a networked PC.
I ave no desire to write code for an embedded system. If I can buy one that performs a specific task, at commodity prices, like an internet router, perfect.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JGCASEY wrote: [snip]

Basically the issue is interrupt latency -- which can be quite long and unpredictable with a non-rtos. Note that the "Real Time" part of RTOS means that the operating supports a deterministic interrupt latency.
There is actually at least one real-time Linux version (RTLinux). I believe that it basically runs Linux as a seperate task, and your time-critical tasks run as other tasks. I'm not sure to what extent (if any) they actually have the functionality of the Linux part of the OS available.
However, even with an RTOS running on a mobo, you're either short on I/O ports altogether (at least the kind useful for robotics) or are stuck using stupid hacks to get what you need -- and you're still limited. Moreover, we haven't even begun discussing power consumption issues, which may or may not be a factor in a particular application.
A MUCH easier approach is to use microcontrollers or DSPs for the low level stuff and let them talk to your motherboard, which can handle the stuff that requires more horsepower, or which will interface with peripherals that would otherwise be difficult or impossible to talk to.
This is what most of us have been trying to get through to mlw without much success. There's no real dichotomy here -- if you need vision processing, if you want to run a web server on your robot or do anything computationally intensive, a pc mobo is ENTIRELY appropriate. It's just a poor choice for the lower-level workaday tasks that most general-purpose robots are likely to need to do. For the record, both of my larger platforms are designed to support (and one does, on occasion) small form-factor pc-type boards.
Cheers -- tAfkaks
--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
the Artist Formerly Known as Kap'n Salty wrote:

Everyone uses "real time" as some magical statement. "Real time" is very subjective. I would argue it is largely not needed on a general purpose mobile robot.

It works something like that, yes.

I'm not sure what you mean.

One I/O card and you are good to go, what's the big deal?

Probably minimal compared with motor power requirements.

Yea, that is a standard approach. Most things that connect to a PC are some form of controller. That isn't this debate.

Not at all. I have said, over and over, that microcontrollers have their place in well defined tasks but that I would not base a robot on one because they are too limited. This has been taken to mean that I would never used one anywhere. Its not true.
I have done my share of micro development and it doesn't interest me. In this project, the sub $500, robot, it will not use any because they cost too much.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

"Real time" is not a subjective term. It has a specific meaning when applied to operating systems and control applications. Sheesh.
[snip]

I imagine you'll find out soon enough.

Unless your motors run constantly -- no, it isn't actually. It depends greatly on the application.
[snip]

And where exactly did you do this development -- ExpensiveLand? How much do you think modern microcontrollers cost? Let me give you a hint -- for the cost of your $50.00 I/O card, I can put together and network six or 7 microcontrollers, each having 30 or so lines of I/O, including 6 channels of A/D and built-in PWM hardware and pulse capture. External part count for each MPU? Around 4. Each of thse MPUs can be reprogrammed on the fly if desired, and have sufficient horsepower to do a significant amount of preprocessing of raw sensor data -- I routinely do trig on PICs.
And as Randy mentioned, this is OLD technology. There are newer MCUs and DSPs out now that far surpass this.
--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
the Artist Formerly Known as Kap'n Salty wrote:

Yes, "real time" has a specific meaning to specific groups, too bad they don't all agree. To the data acquisition people, the software guys have a different view from the hardware guys.
All I'm saying is that "real time" is subjective to your task. "real time" updates of traffic is every 10 minutes. "real time" control of motors is measured in milliseconds. "real time" measurement of signals can be in picoseconds.
There is no "one size fits all" solution that is affordable, "real time" to your application is defined by your application.

Oh, like no project runs into its snags. Get a grip, there will be issues around which must be developed. Using a PC over a microcontroller gives me a larger set of tools to bring to bare on the problems.

What part of mobile isn't motors running. When it isn't running it will be in the charger.

And how much is a vision processing system for your micros? How much is a speech synthesis board? How much is a video display? How much and what software exists (and how much is it) for networking protocols like ssh, http, etc? What about storage? What about a development system?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

No, Mikey is right. When it comes to OSs, "real time" has a specific meaning. Your examples are irrelevent; none of them have anything inherently to do with priority switching, an interrupt-driven scheduler, task-to-task interfacing, or anything else you'd see in an RTOS.
It follows that if you're talking about addressing hardware interrupts in real time, it's assumed flyback or latency is as fast as the system can manage. What that time measurement is, precisely, is a matter for the hardware, but the definition of what *needs* to happen is not up to subjective interpretation.
Whether or not a robot needs an RTOS is a matter of debate among those who have actually done it. Regardless, experience has shown that even with a Linux based robot, time-critical events demand more control of the system queue. Robotics entails several of these time-critical events. If no one ever needed to address this issue for harware, then RTOSs would not exist, and we know that's not the case.
For a larger robot it is wise to consider either an RTOS (RTLinux, BeOS, QNX, LynxOS, or whatever or want), or consider offloading time-sensitive subprocesses to some other circuitry in order to free up CPU time, enable watchdogs, and provide for fail-safes. Believe me, a robot that's reading its hard drive while doing speech processing and doing vision analysis, will have a hard time scheduling itself to stop the motors in time before it hits something. (Or maybe you don't want to move the robot during these processor-intensive periods. But that would be a shame, given the availability of options.)
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

[snip]
You forgot to add "as usual".
--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
the Artist Formerly Known as Kap'n Salty wrote:

Ooops, sorry! I won't make that mistake again!!

Better yet, buy a box of the books, and send a robot to college. <g>
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sat, Apr 09, 2005 at 07:29:18PM -0400, mlw wrote:

That's a marketing term used by news channels. There's nothing real-time about this.

You are off by several orders of magnitude.

This statement is close. Real time, as the term is used in embedded control actually is a combination of predictable or deterministic time from when service is requested to when it is received. Better real-time systems can even schedule conflicting real-time requests so that they can all be satisfied. This requires pre-knowledge of the amount of time each service handler takes so that the schedular can interleave the jobs appropriately.
A fast computer system that _happens_ to do what it needs to do most of the time is _not_ a real time system.
Real-time is a guranteed response time to an event that requires service within the time window. If the response is late, you get the wrong answer. Simple as that.
CD burning is a real time process - if you don't get data to the burning process in time, you burn a coaster because the process cannot be stopped and restarted once it is started. Window's systems burn coasters all the time if the system is doing anything else, especially things like IDE disk activity which tend to hog the CPU and busses and by the time the CD burning process gets control back, the FIFO is empty and you have a coaster. Unix is better due to better process scheduling, but they are not immune. Note that this can happen on very fast multi-GHz systems.
A real time scheduler gurantees that the job that requires service, gets it, perhaps at the expense of other non-real time jobs or real-time jobs that don't yet need service.
So the definition is not fuzzy or subjective. If your real-time requirements are not met, you get the wrong answer. In terms of motor control, the wrong answer means your motors don't behave - maybe they jitter, etc.
While Linux, FreeBSD, *BSD, etc are better than Windows at this, they are all time-sharing systems. These schedulers actually try to be fair in terms of scheduling time. Processes that are CPU hogs tend to have their priorities dynamically lowered so that they get less CPU in order to be more fair about the scheduling with other competing processes. Conversely with processes that perform I/O - they tend to get their scheduling priority raised, since they typically only use the CPU for a short amount of time and then go back to waiting on I/O.
A real time system is definitely NOT fair in terms of scheduling. It is very unfair. Non-real-time processes may starve in order to meet the demands of the jobs that have real-time requirements. Not fair, but necessary.
But worse than that even, Unix, Windows, etc, all use virtual memory and process data swapping. What if your "real time" process finds itself swapped out to disk due to memory constraints. Your real-time event comes in and your swapped out process needs to service it. Disk access is very slow, but worse, it is unpredictable. There may be many I/O transaction requests in the disk queue ahead of you and it could literally be many seconds before your job gets swapped back into memory so that it can service your "real time" event.
Like I said, a fast system that performs correctly _most_ of the time, is not a real time system. Real time systems imply a guaranteed response time that Unix, Windows, and other operating systems with non-real-time schedulers just cannot make.
-Brian
--
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
there was a motion control system out there that used an FPGA to drive steppers. It ran under DOS, it ran under Windoze 95A. It did this by pretending to be a disk drive... windows 98 killed it.
The real issue here that concerns me, is that there is a level of communication that you speak at, that not everyone can absorb. This is not a fault of your own, on the contrary, you communicated the points here with such clarity, that I have copied this post, so that I may plagarize it wholly or in part in a future column ;^)
It is a simple matter of understanding the fine points, and a matter of real world experience. I think that MLW just needs to run a couple of 2 kHz PID loops using a PS2 mouse under windows, linux, free bsd, or QNX, and see for himself what he is up against. If he succeedes at real motion profiling and real motor control, with enough horse power left for vision, navigation, speech recognition, speech systhesis, etc, then more power to him, we shall learn a lot from him in the process, I am sure.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, Apr 10, 2005 at 02:43:05AM +0000, blueeyedpop wrote:

Thanks - some of the points might be a little subtle if you are not used to the language typically used to talk about this stuff. I appreciate that you appreciated it :-) I guess my main point was that the term "real time" is actually very precise, within the circles that use the term in the way that it is being used here, and to give one example that I think most everyone can relate to - CD burning. "Real time traffic updates" - Puleeeaze.

Exactly.
I agree. I really want to see him do it without any specialized support hardware. PC MOBO only, as he has said! I'm wondering how he's going to generate a 20KHz PWM signal using his general purpose I/O card, continuously, without interruption - not just for short bursts at a time, as required to drive a simple h-bridge. Let alone multiples of those, each at a differing duty cycle. And still be able to do his vision processing, etc, etc. Microcontrollers have built-in hardware to do this - just set up the facility and plug the duty cycle into a register. Set and forget.
Heck - even R/C servos which are the dregs of motion control and if your signal is off by just a few microseconds you get jitter. I just don't see you having this kind of control using a PC parallel port where system response is highly dependent on load.
Oh, nevermind. I just remembered - he's using a DAC to drive some op amps. I'll take a good reliable h-bridge with high current MOSFETs anyday, though. Check this one out:
http://www.bdmicro.com/include/display_image.php?img=DSC01406.JPG
Anyway, these threads remind me of a signature someone is using in another list:
"Good judgment comes from experience, experience comes from bad judgment"
I love that! It's so true. More so for some than others :-)
I seriously hope MLW doesn't give up, though - keep at it. Persistance in this field is key to success! You never know, maybe the end result of all this is that he will design a 40mA Athlon based PC motherboard with all the bells and whistles that we need for our robots that runs on 4 AA's and make a fortune selling it to us for $99.
-Brian
--
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Yup, just about sums it up.
interrupt driven I2C DAC off the parallel port to an LM12.
I think that this is the time for him to maike a new BIOS, and write an OS in ASM.
Those look like 18201's on that board. Trying to make a toaster ;^)
Try 16 LM12's and you can cook a pork roast.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
blueeyedpop wrote:

Not a kosher robot, I take it...
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I know of a particular device that uses literally dozens in parallel to control a big motor. It has a specific need to not be chopping Watts at such a scale, and making Mr Marconi jealous.
We can do lamb. how about gyros ?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, Apr 10, 2005 at 04:54:52AM +0000, blueeyedpop wrote:

Actually those are 16 IR high current MOSFETs ganged 4 in parallel for greater current carrying capacity. Each row of 4 is a leg of the h-bridge. There's also a pair of high-side MOSFET drivers on there and an ATmega32 microcontroller providing the "smarts."
It does RS232, RS485, I2C, R/C servo pulse, and simple potentiometer control. The potentiometer can alternately be connected to the shaft of the motor and used to make a giant "servo" where it gives position feedback.
It also does quadrature encoder input and PID control.
It's not all done yet - not quite fully functional, firmware wise, but getting there.

I've placed 4 mounting holes to mount an Athlon CPU heat sink fan over top of the MOSFETs :-)
I torture tested it on a 20 HP E-Tek motor and it survived. Some parts did get hot, though. But it still works :-)
-Brian
--
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Sure you have. Just use the OS. Make D/A pins out of the parallel port. Make D/A pins out of the audio channel. Make D/A pins out of the video. Any of these are possible. What's the big problem?
If you use a parallel port, Just use a 100,000 Hz interrupt, count each time, and then along some part of 65536 of those interrupts make the pin go hi, and the remaining make it go low. That will give you a 16-bit D/A output that has about a 1.5 Hz update rate. Easy! right? Maybe there's already some driver written that could do this for you.
Or how about that stereo sound channel? There's two audio outputs, and you can probably shape those waveforms to be just what you need right?
Just assume the D/A's are there, like you suggested. Use the OS. Just pick a couple pins on your PC, and make 'em work. No cost! Easy! You've got them right there on your ITX mobo.
Let us know how it works out.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Can get some cheap pci expansion cards http://www.futurlec.com/ComputerBoards.shtml
You can buy a 1->2 or more adaptor for the mini-itx boards then could plug a couple of these boards in. http://www.mini-itx.com/store/?c=8#p1902
Or other option get a pci to 4 port usb card and buy a few embedded boards that have usb inputs
or pci expansion and a usb adaptor and pc io board or extra paralel and serial card
www.newmicros.com have a few their dsp boards are brilliant for motor control http://www.newmicros.com/cgi-bin/store/order.cgi?form=prod_detail&part=ServoPod-USB can use c , forth or isomax or asm
quite a few articles / projects on the web using a servopod or isopod as the io for a mini-itx board http://www.nwlink.com/~jmc/merriwether.htm http://robots.net/article/983.html some good suggestions at the bottom of this page http://www.bio-bot.com/bio-botsite/lynxmotion/ Mike who posts here a lot is currently selling this on ebay
a single usb connection to a servo pod would let you control 26rc servos if needed
one very cool looking product is the biped scoutn from lynxmotion http://www.lynxmotion.com/Category.aspx?CategoryIDg
Could also get a few of the microchip , pic18f4550's which can do usb2 fullspeed(12Mbps), easy to program and use.
Silabs also make 8051 micros with usb ,adcs , spi and smbus on a single micro.
Can get some cheap reasonably powered bridges http://www.futurlec.com/StepperMotorController.shtml looks like they have droped the price, not bad. datasheet http://eu.st.com/stonline/books/pdf/docs/1773.pdf for dc motor see page 6
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Sub $500 huh.
There isn't a whole lot of context in this message, but I have been reading up on your other posts.
One pattern I see in your thinking is that you appear to feel that a PC is going to be able to do everything. That there is a cheap OS that will have all the functionality.
You are in effect designing the mythical "killer app".
OS I really do not think that you need to concern yourself with OS. PCs running Linux, QNX, Windows, DOS will all have to have specific hardware to achieve the task of robotics. This can be on the ISA, PCI, USB, Serial or LPT port. You will have to roll your own hardware to do this on the cheap. If you use an internal bus, you will need device drivers deep within the OS to demand service from the CPU on a periodic basis.
I saw that you discount microcontrollers. A microcontroller is a micorcomputer with internal memory and specific register based devices for performing specific tasks. Your mouse attached to your PC likely has a Cypress microcontroller with timers to read the quadrature coming out of your mouse encoders, or to read the SPI or quadrature coming out of it's Agilent mouse chip, which is a very specialized microcontroller in its own right.
The mouse is a very specialized subsystem designed for user input. We do not run the encoder lines from it directly into our PC, we use a sub system.
The printer you have next to you is similar, with stepper motor drivers and one or more microcontrollers to mediate its functionality. It has a buffer of commands, and follows them. It demands time slices when the buffer is empty, but otherwise does not place a demand on the OS.
Your hard drive is an embedded system with h-bridges, motor controls and micro controllers.
Industrial automation is using CANBUS and other serial busses to distribute motor control commands in the form of PVT commands to microcontrollers which mediate the final motion.
Automobiles use microcontrollers with a variety of serial busses including CAN, LIN and K-Line. All working in concert, all working on their own with periodic intervention.
Alex mentioned the IsoPod. This is but one example of a device which is a seriously powerful robotics controller in it's own right. Even if you write a simple shell within FORTH to accept commands from the serial line, and wrap that around a simple PID loop, you will be a lot better off in the end. Add a lot of analog and digital sensors, and you are in really good shape.
As a matter of note, you asked how many motors Randy's micro can control. I have run 12 DC motors in open loop, with 1 wire PWM. You can run 6 motors with quadrature feedback and 2 wire PWM, or 8 motors with analog feedback(16 on a servopod) and 1 wire PWM. You can run ~26 motors in locked anti-phase open loop, or 22 closed loop with 6 on quad feedback, and 8 or 16 on analog. Or you could add an SPI a/d and close more loops.
By trying to over simplify your system, you are making it more complicated.
Take your $1.29 D/A converter and replace it with a cheap micro that does PWM and has a few timers for your hacked mouse feedback. If you plan things, you will have some digital and analog lines left for other things. Then build a good and proper PID controller that accepts serial commands with some sensing as a bonus? Drop the mouse and add 4 reflective sensors and a printed wheel encoder wired to an AVR, PIC, ARM, whatever will save you lots of ulcer medicine compared to trying to close a loop through an HID call in an OS.
don't get me wrong, $500 is an admirable goal, but why not add $40 worth of microcontrollers and save the usenet bandwidth, save yourself the ulcer meds and rogaine to grow back the pulled out hair.
just my $0.02

is
http://www.newmicros.com/cgi-bin/store/order.cgi?form=prod_detail&part=ServoPod-USB
of
if
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.