Well, a little effort on your part to learn something that hasn't been dumbed down will pay dividends on your ability to accomplish.
What did you try?
Everyone's situation is different.
Nothing worth doing comes easily. The accomplishment is the reward. I know that sounds like a forune cookie, but it is true.
We can't make you enjoy anything. You have to enjoy it.
It's like mountain climbing. If you ride the ski-lift to the top, you see the view. If you climb to the top, you understand the view, and are improved by it.
I know that isn't what you want to hear, but it is true. "Everything should be as simple as possible, but no simpler."
If you want to build a house, you learn how to build a house. If you want to build a playhouse, you learn how to build a playhouse. You don't set your sights by your abilities, you learn what you need to learn based on that which you've set your sights. It doesn't matter what I know or have.
5 years? Hardly, I have a couple lesbian friends that are in the process of building their house. Learn by doing.
too true.
Maybe.
Not really. Ripping apart a mouse and making a motor encoder isn't in my job description.
And amature astronomers find stars and asteroids too.
Why not?
Why not?
OK.
"Pro" athletes are useless, college football is better, local baseball is a blast, and a pickup footbal games rocks.
Experts in the field did not learn what they know in school. Most of the greatest contributions to science and technology have not come from universities.
OK that's great for the end product, but we are the guys building and developing this technology, not the end user. If you want a ready made robot go buy a Robosapien or something.
I thought this was a technical discussion on building robots.
In fact I have been using DOS. You can access as much memory as you like (with a DPMI host) and use 32 bit code. That includes some visual processing using a monochrom ccd based camera.
I have been forced to use VC++ for some experiments with a color web cam as the protocols are not made public (or private).
Just because the time a task needs to be done is different between systems or applications doesn't make the concept of real-time subjective. If the computer is controlling a two-legged walking robot it has to keep those legs moving in a precise way within a certain amount of time, or it falls over.
It could be.
You're exactly right, and that's precisely why it's a bad idea to control a stepper motor with a general-purpose OS. Each coil must be switched on and off with precision down to microseconds to keep it running at a steady speed, or accelerating or decellerating smoothly without losing steps. A dedicated microcontroller with no OS, only application code written specifically to ramp and otherwise control the stepper motor, is ideal for this, and is almost the ONLY thing for this. A larger processor running custom-written code (no OS) would of course work, or even running an RTOS if the interrupt latency is kept low enough. You can be sure interrupt latency is too high with 'desktop' OS's such as Linux/Unix, any version of Windows, or MS-DOS.
You're right again, the speed must be slewed down at a controlled rate, something better handled by a dedicated microcontroller executing higher-level commands sent to it from another processor.
Is the computer runnning-some-OS giving high-level commands to move the arm, or is it switching stepper-motor coils (or alteratively, sending a PWM signal to a DC motor and reading an encoder)? I wouldn't trust a general-purpose OS to do the latter.
What micro-controller are you thinking of? 8-bit processors from Moto, er, Freescale, Atmel (AVR) and Microchip (PIC) are certainly not capable of controlling complex systems with hundreds or even dozens of high-speed I/O's, and the large bandwidth that a high-resolution vision system uses. But they are totally appropriate, and even the best choice, for converting commands such as 'move arm up four inches at two inches per second' into signals that control motor speeds.
But there are other, much 'larger' (as far as word width, instruction set and memory address size) and faster microcontrollers, many 32-bit, and at least one that's been around for a long time, the MC683xx series. There's also the 32-bit ARM, an architecture used by many manufacturers. There are DSP's (many of which are technically microcontrollers due to onchip RAM, ROM and I/O) that can do a large amount of vision or other signal processing, at a lot lower price and with a lot less power consumption than a desktop-computer's CPU doing the same task.
On real-time systems conflicting requirements don't need to be arbitrated, they just need to be done on time (okay, arbitration is deciding which one goes next so that each task is done within its timeframe - if that happens, then nothing is conflicting). This argues for a RTOS, and furthermore (and implied but needs to be stated), a design wich uses it effectively and guarantees that critical things get done within the appropriate amount of time.
This is true, but one can typically plan around variations in response times.
I submit, not on a "non-precision" mobile robot operating in a "non-precision" environment, unless you are a poor engineer.
I would *never* run a stepper motor with an OS, not even a real time one.
Steppers are for zero feedback control system and out of the scope of this discussion. We are talking about srrvo motors right now.
OK, why? What are the technical limitations that require a dedicated microcontroller? A mere assertion is not good enough, tell me why a dedicated system needs to do it.
Stepper motors are not being discussed.
How does this relate to the conversation?
Can they do it better than a PC at a lower cost to the end user? Is it an easier platform on which to develop?
Right, and arbitration agains conflicting priorities always introduces variance in response times and ALWAYS introduces restrictions on the way something is coded. A "real time" OS on the PC hardware is only as well behaved as its worse process.
Not to be argumentative, but this is EXACTLY what I do, using commonly available commercial software. I operate a CNC router that runs off DOS or Windows 98, through the parallel printer port, and it more than adequately controls three steppers simultaneously to their maximum step-per-second rating (which is also the maximum feed-rate for cutting most materials anyway, of about 1.5"/sec). Step control is better under DOS but quite acceptable under Windows. This is on a Pentium 1 133Mhz PC with 64 MB of RAM.
Strange but true.
I haven't seen too many CNC programs these days that don't use standard DOS, Windows, or Linux. Many of them rely on fairly simple bit-banging through the parallel port for stepper control.
The difference here is that apart from reading limit switches, and maybe drawing the toolpath on the monitor during routing, these programs aren't data-intensive during the stepper-control phase. By the time the router starts moving the path has been plotted, and CPU useage is actually quite low. If the OS were also doing some intensive data-crunching, the steppers would be very jerky. PCs have long been able to do ONE thing well at time.
Again, this is real-life experience, and is at odds with what someone might assume. But there is a rationale for why it works in practice.
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.