Motor interface electronics

Kidding aside...

Despite your stated proclivities, you seem to be the one unwilling to learn something new. You apparently don't know microcontrollers _are_ usually what is used to do motor interface electronics these days. And being ignorant entrenched in your misgivings, and apparently unwilling to learn, you can't even hear the answer.

It is erroneous to think microcontrollers are the same as they were in the early 1980's, which seems to be at the root of your misunderstandings. They are as different today as your MiniITX is to a

4.77MHz PC. The early 1980's PC couldn't (meaningfully, usefully, if a at all) run Linux, web servers, MPI, SQL, or V4L, etc. either. It didn't have the memory, and it didn't have the speed, and it didn't have the peripherals. It would be a bad choice for those apps, given modern alternatives. The same is true of motion control, and the microcontrollers of today. Using a PC of any flavor, with any PC oriented OS, for motion control, over a modern micro designed for motion control, is also a bad choice.

So you are ignorant of LAP (locked antipahse) one-line methods as well? Too bad, it's probably one of the more commonly used methods in driving robot motors today. Uses a little more power. But has the advantage of continuous control over the motor, preventing such effects unpowered, or oversped, down-hill roll aways.

Ha! Are you so behind the times! The short answer is:

26

That's hardware, btw. With _no_ on-going processor overhead required. But then that's open loop, and not so interesting.

The extended answer of significance is: 6 axes of current sensed, quadrature decoded, closed-loop, velocity limited, acceleration determined, trapezoidally profiled, PID, and even co-coordinated motion. On one microprocessor. With processing power left over, btw.

Motor interface electronics today, state of the art, _is_ a micro, with level shifters to the drive transistors - straight to the motor, or PWM to an integrated H-bridge. No op-amps, no comparators, no D/As. Just the micro, and a few transistors and resistors, or an H-bridge chip.

Of course, using a micro is the modern professional approach to motor control, instead some amateurish analog kluge tacked on a PC, for at least three reasons. 1) Better reliability. 2) Better control. 3) More cost effective results. In the end, a micro produces vastly better results, while completely unburden any other PC's in the system from having to deal with a job it is very poorly equipped to do. Even with an I/O card, the PC's is still ill-suited unless that I/O card has a micro like this on it, or an FPGA as Alex suggested, that makes up for the PC's shortcomings.

Yes, short comings! And the number one reason PC's have short comings is the processing overhead taken by the OS they run, and the tasks they were designed to do (and do well btw), versus the hardware support requirements necessary for those tasks; all interfere with doing other things they then cannot do well. Motion control being a very obvious one. A PC is a very poor platform for motion control, missing the necessary hardware, and otherwise overloaded with realtime tasks of communications, data transfers, and display. So if you aren't willing to spend the money to buy a motion control card for more than your entire budget

formatting link
...

The best, most cost effective way to add motion control to a PC is to add a micro which has the hardware to do the control.

Reply to
Randy M. Dumse
Loading thread data ...

Gordon:

It is to MLW's credit that he came over to comp.robotics.misc and asked his questions, unfortunately, he does not seem to be listening to the answers. MLW's loss. However, it is a free world and he/she is free to spend his time and money any way he sees fit. I just hope that other people are listening the answers.

So far my favorite MLW quote from this thread is the following:

The last sentence was a belly buster for me. A PIC16F630 costs $2.05 for quantiy 1 from Digikey and tube of 25 costs $1.32 each ($33.01 for the tube.) I guess he has not figured out that we use microcontrollers like he seems to want use op-amps and comparators.

Anyhow, back to building robots that actually work...

Later,

-Wayne

P.S. To E-mail me directly, send to Wayne .at. Gramlich @dot@ Net.

Reply to
Wayne C. Gramlich

Actually I plug it into the 240v (110v in your part of the world) socket. My little robots have been connected via wires to the power and brains. They were only experimental bases to test the software for the day I build a real robot :)

As for my big robot it uses large batteries that make up 90% of its weight. The base is solid steel and the wheels have strong wheel bearings. It uses

24volt truck window wiper motors. It is powerful enough to carry a full sized human or push a large couch around the room! How else is it to rescue its master from danger :) Or push the mower over the lawn? It is a prototype and one day I hope to replace it with the guts of a small electric wheel chair, only a PC will work the controls. I don't see mwl's $500 as a realistic figure for a real robot. That might be enough to cover its brains hardware but that's about it.

If a robot is to do some hard work it will need lots of power. This is the Achilles heel of the robots today.. no cheap lightweight portable power source. The other limitation is the cost of actuators.

[...]

You can add as much i/o as you need. How many pins does a PIC have? More than say 3 parallel ports or a group of USB ports. I fail to see that as a problem.

There is nothing to say the i/o modules cannot use micro controllers rather than use umpteen ICs from your IC junk box.

Every three years or so you have to replace your PC with a new one to keep up. So I have spare PC's. The one I am using at the moment is my old 800MHz laptop which has been replaced with my latest and greatest.

How much cheaper can you get than that?

The i/o circuits can be inherited by each new PC.

This is I understand essentially a hardware newsgroup.

For me I want to use what little time I have actually experimenting with software and use the hardware I can afford to buy.

You can have the neatest piece of engineering under the sun, bristling with microprocessors and PID controllers, and yet not being able to compete with a scrappy remote control car driven by a human brain.

You can get a dumb machine to do some very neat movements using stepper motors or fast acting servo control, but they are still dumb machines.

The motor control on my large robot is so bad I am thinking of calling it Jerky. But, if it is smart enough, it can work around its handicap until I get around to installing a better system.

It comes down to cost, availability, area of interest, time available and ultimate goals.

The PC based robot vs uController based robot is not an XOR situation. They are both worthwhile activities.

IMHO :)

- John Casey

Reply to
JGCASEY

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

Reply to
the Artist Formerly Known as K

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.

Reply to
Randy M. Dumse

Wayne C. Gramlich wrote: [...]

It has certainly made me look into the use of PICs. Unfortunately they are not something I can buy from the local electronic shops along with how to manuals. So it is going to be some culling of web sites until I get up to speed on how to use these little chips.

[...]

-John

Reply to
JGCASEY

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

Reply to
Gordon McComb

I think Dick Smith carries PICs and PIC programmers, though I don't know how far away you are to one of the stores. (It is my understanding that Australia is a very small country, and you can travel its entire distance coast-to-coast in about an hour. Correct me if I'm wrong...)

Seriously, there's also Dontronics.com, a very active mail order outfit in Victoria, and Don sells both PICs and AVRs. You might want to look at both, and decide which has the functionality you like best.

-- Gordon

Reply to
Gordon McComb

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?

Reply to
mlw

Actually, I've heard of it being done, seen an RS-232 to I2C dongle, but I don't have any actual information about it.

Yea, the parallel port is an awesome resource.

Reply to
mlw

:)

You are surely not confusing us with Austria?

A lot of Americans do!

formatting link

Oh, you *were* joking,

We have a shiny new Dick Smith store. The staff know nothing about electronics. It has become a retailer of mostly electronic products like all the other shops that sell tvs, computers, etc.

There was a kit programmer available for $99.95 with an obsolete PIC16F84 included.

Don is the the best choice but he is internet based. I like to talk to people and handle the merchandise. I would hate to end up with a stack of boards that really weren't what I thought they were or lack the documentation that a hobbyist would need to use them.

Also I don't trust internet transactions.

Still I will use the internet to learn about them.

-- John

Reply to
JGCASEY

Eljin wrote: ...

Serial to I2C can be implemented quite simply using our famous $5 microcontroller .

Seriously though, a cheap MCU would probably be the easiest way to do this. With something like the AT90S2313 (or ATTINY2313 when supplies are exhausted), you could do the serial side with the built-in UART and then bit-bang the I2C.

I've seen PICs on eBay (Australia) and surplus cheap as cheap (but never AVRs :( ), but don't know if they have the on-chip UARTS. Then again, it should be easy enough to bit-bang a serial port as well as the I2C.

Then with the bargain $10 of components (I'm talking surplus/cannibalised, not RS/Farnell prices [shift decimal point to right]), you have to invest $$$ of your precious time sorting out the bulk of the problem in software ;-)

Cheers

M
Reply to
Matthew Smith

I learnt basic electronics and programming from books so I had no one to demand an answer from.

When I did a course on program design the lecturer said he could tell I was self taught :)

I have an excellent, but dated with regards to hardware, book called "How to Build your own working Robot Pet" by Frank DaCosta based around sonar and the 8085A. That is the kind of thing I mean.

Sounds like me :) except I have plenty of practice soldering.

I would use a breadboard system which contained the circuits for support such as the power supply, logic probe, led display and so on and thus the beginner could use solderless breadboard sockets to put their projects together.

John

Reply to
JGCASEY
[...]

Just been to the Kadina web site. I see you are interested in privately developing hardware/software solutions for independent living for the elderly and disabled.

This should be a real growth area in our aging population, at least Japan thinks so.

I visited a relative in aged care who is still youngish but suffered a stroke. If only he had a robot he could command to look after his needs, for the understaffed home for the aged cater to their needs first. I couldn't get anyone interested in his plight.

Robots might not have feelings but they could turn out to be the best friend you have.

- John

Reply to
JGCASEY

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

Reply to
Gordon McComb

[snip]

You forgot to add "as usual".

Reply to
the Artist Formerly Known as K

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

Better yet, buy a box of the books, and send a robot to college.

-- Gordon

Reply to
Gordon McComb

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

Reply to
Brian Dean

I always find it amusing when people have to impugn the person with which they are debating. I always ask myself "Is their point so weak that they have to attempt to discredit the person? If they knew what they were talking about, wouldn't the information suffice?"

And who said they weren't?

Again, *you* have assumed quite a bit of what you think I have said. You are so busy defending microcontrollers that you fail to see that I've always said they are fine in a very well defined task.

Another assumption. A bad one too. Ever use a StrongARM processor?

I'm sure.

ok.

Actually, the PC couldn't run a "real" OS until the 80286 based machines that could go into protected mode (16 bit selector). It wasn't until the

80386 (32 bit flat) that it could do it well. What peripherals were not available?

I'm not sure what this sentence means.

Statement with no supporting facts.

Why? You make a statement, now make a technical argument to support it. You can't because it isn't true.

Actually, I am familiar with it and it is a bad design, it wastes power, especilly on high power motors. It is actually an interesting design in that, if done correctly, can use back braking to recharge the batteries, but doing it correcty isn't simple. I opted for analog control which works like a sign-magnitude system and is very simple, hence the D/A requirement.

On very small systems, yes.

The efficiencies are poor on large motors.

That is the job of the motor controller.

How's the vision system with that? How's the navigation? The remote monitoring? The speech synthesis? Oh, that's right, it doesn't do those things.

Open-loop surely you know I can run 12 open loop motors on a PC, and I have enough computing power that it doesn't matter. I can even synthisize speech and do vision processing.

The PC has some interesting extensions to the parallel port that allow greater programability.

That is cool, but not nessisary for my application.

Perhaps in your field. There ae many fields that use motor control.

Why?

Why?

Why?

You've made three technical assertions but made no attempt to validate them.

An unsupported opinion.

This statement makes several assumptions that are not true. (1) The job of the PC in this aplication is to deal with this sort of ting. (2) In he designed used, it is perfectly well equiped to do it.

I have never said microcontrolers are bad when used in a very well defined task, but it is not a good base for generl pupose robot.

Like?

Like play MP3s, videos, and networking. These tasks share no common ground with other I/O?

?

There is no reason to waste CPU cycles on something that engineers have done already and manufacture for less than $10.00. If it has a micro or not makes no differece. I'm not going to waste my time developing PIC or basic code.

Realy?

A PID algorithm is easy. The PS/2 interface is fine for encoder input. A number of strategies can be used to control the motor amplifiers. What's missing (of any material importance?)

Maybe you missed my point. Less than $500 dollars.

That's nonsense. I can buy an I/O card or system (USB, I2C, PP, Serial) and do the rest in the PC, in a device driver if I have to.

>
Reply to
mlw

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.

Reply to
mlw

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.