Do you need "real time" for motor control

All x86 processors since the Pentium have a 48 bit hardware register that counts the number of machine clocks since the processor was turned on. The
counter runs at the clock rate of the processor (2.4 gigahertz processor means 2.4 giga counts per second on the counter).
This counter can be read with an unprotected assembly instruction "rdtsc". This does not require a system call to do it. You can use this little ditty to read it.
static __inline u_int64_t rdtsc(void) { u_int64_t rv;
__asm __volatile(".byte 0x0f, 0x31" : "=A" (rv)); return (rv); } Thought this might be useful.
MCD

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
48 bits
how many seconds (minutes, hours, days, years?) will this be able to count at 2.4 GHz?
Rich
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
My handy dandy calculator says 3.7 years. Keep in mind the counter starts at zero after each reboot. So if you plan on your application having an uptime of more than 3.7 years you will have to handle the counter wrapping. If your application is Windows based, you have nothing to worry about. ;-)
MCD

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Oops, they must have added some bits while I wasn't looking. A quick google says the counter is 64 bits.
MCD

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

MCD:
Thanks, that is a useful piece of code to stuff into my bag of coding tricks. It also explains why Linux now has microsecond grain accuracy.
-Wayne
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, Apr 10, 2005 at 05:27:16PM -0400, mlw wrote:

There are two aspects to consider. The one you mentioned is a response time issue of the robot. One obvious example is for safety. The problem with non-real time control here is that response is unpredictable. Is the response to bumper switch activation .000005 seconds or 2.5 seconds? Shutting down the motors in 5 microseconds might mean you stop in half a second, but more importantly, not shutting down the motors instantly means you collide with the obstacle under full power. That does a lot more damage than colliding under no power. Think of bumping into a chair and it moves a half-inch or so. Now think of running into the chair and pushing it across the floor and right through the china cabinet.
The other is control signal generation. These have varying demands depending. Lots of small robots use R/C servos. The timing of the pulse needs to be within the range of 1ms to 2ms with around microsecond resolution, and repeated with a period of around 20 ms. The repeat period is not so critical, but the pulse duration is. If the timing constraints are not met, you get jitter.
Direct h-bridge control requires the ability to generate the PWM waveform - typical square wave of fixed period and varying duty cycle. The duty cycle determines the power across the motor. The frequency is pretty important - there's not one size fits all for frequency, but in general, higher is better, both from a control point of view and also that lower frequencies tend to make the motors whine and can be quite noisy and irritating. Failure to meet these timing requirements also is bad - your motors don't do what their told.
Typical microcontrollers handle this latter with specialized hardware support to generate the PWM signals. Typically it involves configuring a hardware timer, configuring pins to do the control, and then plugging the duty cycle into an "output compare" register. After that, the signal is totally hardware generated and the MCU spends 0 processor cycles generating the wave form. PC's typically don't have this hardware - you won't find it on your parallel port or general purpose I/O card. Your choice is to add hardware to do it, or generate the signals using software. Generating them with software is going to be difficult to meet the timing requirements to control multiple motors.
Both are real-time requirements, just at different levels of control. I think you've been thinking of mostly the former, but I think a lot of the folks responding to you about microcontrollers have been thinking of the latter. At least I have, but I can't speak for everyone.
-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
Brian Dean wrote:

OK.
2.5 seconds is unacceptable. Assume no greater than two quanta, say 0.02 seconds, which means on average you can expect 0.1 seconds response time. In real life on a system without competing high priority processes, it is usually MUCH less.

Again, how much precision are you using? Microseconds? How think is your bumper? What's it made of? Actual physical switch response time? Nature of the surface on which you are runing. Tread ware of the wheels. There are so many factors, 0.01, hell, even 0.05 seconds isn't going to help you.

This isn't a small robot, 25~40 lbs.

What makes you think I'm timing the PWM?

I am using an analog signal from a D/A converter and sending that to a PWM motor amplifier.

Don't need it.

Or use a ramp generator and some comparitors for $3.00

A lot of people responding have strong feelings about the subject, but not a lot of strong information. They make assumptions and work from their assumptions.
Take for instance, ".000005 seconds or 2.5 seconds?" clearly you know that 2.5 seconds is out of the question, but you don't think that I would have thought about that. It would have been better for you to ask "How will you manage response time? What is your maximum response time?"
To which I would reply, "well, I've been doing some tests on the PC, and under load, a single high priority task has never seen more than 0.02 latency variation." Which is about to be expected.
The real problem is device driver interrupt routines, these need to be inspected for quality and how long they diable interupts.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Just out of curiosity, does the $3.00 include the D/A converter? Do you have a specific D/A converter that you are thinking of using? If so, which one?
-Wayne
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Wayne C. Gramlich wrote:

I've seen some I2C D/A converters for about $1.50 at digikey.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

Could you provide a part number? There 1000+ D/A converters at DigiKey. I've done a variety of searchs and can't find any that are that inexpensive. It probably means that I haven't found the right set of parameters to search for.
-Wayne
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Wayne C. Gramlich wrote:

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

Are you sure that is the right device? The quantity 1 price at Digikey is $3.04 and the quantity 1 price at Future is $3.00. Also, it only has one D/A channel, so you would need one of these chips for each motor. Am I missing something here?
-Wayne
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Wayne C. Gramlich wrote:

Wierd, they were cheaper. I'll have to find something else.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Wayne C. Gramlich wrote:

You see this chip on the Linux boards from time to time because someone wrote a library for it. Philips has others if you're not looking for the A/D channels. Also note Digikey is 0 stock, and Future has a minimum of 25 (for the rail).
A quick look shows Digikey has a 16-bit I2C DAC (DAC8571), in MSOP package, in available quantities. But it's $6.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

Gordon:
I've used a MAX548 on some of my many other projects (non-robotic). It is a dual 8-bit 3-wire serial D/A, but it still costs $4.64 quantity 1 from Digikey. What I liked about it is that it comes in a 8-pin DIP. I've also used a TLC5620, which is a 3-wire serial quad D/A. It actually costs a little less at $3.60 quantity 1 from DigiKey. Neither of these 2 parts work with I2C though.
-Wayne
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Mon, Apr 11, 2005 at 07:24:32AM -0400, mlw wrote:

You can't assume any such thing. Your process might be swapped out to disk. It could be many hundreds of milliseconds or even seconds before your process gets control. Or ... you reference an unmapped page of virtual memory which causes a page fault or multiples of page faults. There are lots of code paths in non-real-time systems that can result in unpredictable timing.
Just because you ran it for a while and the greatest you saw was 20 ms doesn't mean that is the largest it can be. You aren't seriously calling that a proof, are you? Surely you know better.

I'm taking about your response time being non-deterministic. See above. If you are unable to respond to a bumper switch because your process is not in memory and takes a long time to swap in, you collide with the obstacle while your motors are fully powered, rather than braking. There's a big difference. Just to illustrate what I'm referring to, golfers know this as follow-through on their swing - means the difference of the ball going a 400 yards vs 50 yards. Golf swing: follow-through = good; out of control robots: follow-through = bad.

That's irrelevant.

I never said you were. I was answering your question about why motor control is a real-time process - which you did ask, did you not? You mentioned only one aspect of motor control - the macro level of stopping the base or platform. There's also the actual control aspect of driving the motor.

Yes, I remember.

In case your other method doesn't work out for some reason, you'll need a "Plan B."

Fine.
You are too.

That's not clear at all. See, there you go making assumptions that you are accusing everyone else of making.

Apparently not.

You've only shown that your system is operating reasonably as expected under conditions that you have anticipated. I would certainly expect it to be reasonably well behaved under these conditions. But what about conditions that you haven't anticipated? Do you really think you've exercised even a fraction of the available code paths? Have you really loaded up several memory hungry processes to see what happens when your systems starts swapping? Or what happens if you cause a packet storm - i.e., a flood ping or similar? You did mention your system will be networked. Does your kernel rate limit responses so that it doesn't suffer from DOS? All these things can a do affect your response time. And not just a few milliseconds. We are literally talking seconds in some cases.
-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
Brian Dean wrote:

No such thing would happen. "Processes" don't get swapped out, unused VM pages may get flushed, but they have to be "unused."
And yes, I know not to have the system in a memory starved configuration.

Nonsense. This is not an arbitrary use system, it is a robot that is running a number of well understood programs.

Why would I do that?

On what grounds do you make this claim. You know neither the condition nor the length of the test.

What would be proof?

Yup.
OK
The process will be running at a high priority and the pages will be marked as non-swappable, how's that?

That's my first golfing metaphor, usually its cars.

Not true. It takes less energy to stop something with less mass. (assuming equivilent velocity)

It does work.

No assumptions, actual physical testing. Measured.

And the system will operate under expected conditions.

Yup.
Like software I forget I installed?

Ahh, "code paths." Nonsense.

"System starts swapping?" Not going to happen, $25 for a stick of RAM if it gets cramped.

Why would that happen?

Yup.
Considering it is behind a firewall, why would I get a DOS attack? Even so, that wouldn't affect the system dramatically.

And all these things can be managed.

Oh, but it is.

No.
This not some internet terminal in a kiosk, it is robot. Geez.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Mon, Apr 11, 2005 at 08:51:26PM -0400, mlw wrote:

Pages of "processes" that have been sleeping for over a certain amount of time are most certainly high on the list to swap out when memory is in short supply. The paging system doesn't select random pages for swapping out to disk. Whether your process is entirely or partially swapped out is kind've irrelevant if the pages it needs to run are on disk. The point is, when it needs to run, it can't do so in a timely manner - some other processes's pages may need to be swapped out in order to make room for your process's pages to be swapped back in so it can execute.

So you don't make programming errors? Cool.

With no bugs, of course. Again, my hat is off to you.

Oh, I don't know, maybe you call 'malloc()' or something? Maybe you call printf() or any host of other library routines which can call 'malloc()'? And then, after calling it, maybe you actually reference the memory address which generates a page fault which in turn causes a physical page of memory to be mapped in at said address? So your supposed 3 clock cycle memory access that you so carefully planned for in your timing requirements suddenly becomes many thousands of clock cycles. That's how virtual memory works.
<rant>
As a side note, I was at first surprised at the breadth of your knowledge, but it quickly became clear that the depth of your knowledge in any given area appears to be very shallow. It's actually becoming quite tiresome. You seem to have accumulated a collection of "facts" with little understanding about how things work. And the really irritating thing is that you don't seem to realize that you don't know how things work. I'm not saying that to be mean - it's just an observation. And that I'm a little irritated at your combative attitude and responses, so don't take offense - I'm just airing a bit. As a bit more constructive criticism, perhaps you would do well to not post a question, if you are going to simply mince words and go on the offensive with anyone who takes the time to respond. It's fine to have disagreements, but my impression is that you take it to a combative level with anyone who has a differing opinion than you - like when you demand that folks must prove their assertions. I say "No!". They have answered your question - if you want more background information do your own homework and don't ask everyone here to spoon-feed you answers. And if you think you already know more than everyone on this list, why are you asking us? Instead you should simply point us to your accomplishments so we can look upon them in admiration.
Also, its irritating when people say "you should listen to me because I have ..." and then start spouting off credentials about where they used to work, etc, etc. We don't really care. Nobody here does that. If you want to impress us, show us your robots.
</rant>
BTW, I'm still waiting to see your mouse encoder adapted to motor / wheel encoder. So far I have not seen any of your work.

That's not what I meant. The discussion wasn't really about the size of your robot, but rather that motor control is a real-time process. Size of the motors are irrelevant.

I have no doubt.

Limited testing. Which is fine, for you.

So you can predict the future now, too?

More like programming errors. Oversights - no one is perfect. Also, a little thing affectionately referred to as "Creature Feep."

Maybe you can make that RAM materialize while your robot is careening down the stairs. Again, that's the beauty of the unexpected - you never know when you will need it.

Personally, I would make it happen as part of my testing and ensure that my system could handle that. I know I'm not a perfect programmer and if I write a program to open a socket to my 'bot to display a live video feed or whatever, I also know that I can make a programming error and perhaps cause a similar event, unexpectedly. So I would test for it.

I wasn't really considering an intentional DOS attack - I was thinking DOS due to programming error, looping process becoming a major CPU hog, etc. It's an accidental, self-inflected DOS.

Yes.
I don't know what your Linux experience has been, but even on my Dual 2 GHz PowerMac G5 with 512 Meg of memory, processes get swapped out while doing certain highly memory intensive operations - the game Halo comes to mind :-). You can really feel the response suffer when you exit the game and press a key in the window of a swapped out process. Several seconds for response is not unusual at all. Adding a Gig of memory for a total of 1.5 Gig fixed that, but that doesn't mean it can't still happen with an even more memory intensive application.
No, I don't anticipate you will be playing Halo on your robot, but you did say real time vision processing - lots of memory and CPU utilization there. Speech recognition and generation - lots of CPU, modest memory. Navigation - are you constructing maps of your environment? - more memory and computation. Path planning? More memory and computation.
-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
Brian Dean wrote:

"When memory is in short supply." Not going to happen.

Nope, pages that are not regularly used.

Why would pages of a regularly executed process be swapped out to disk? (Assuming the pages are not marked as non-pagable)

Assuming (a) a memory starved condition, (b) the process and pages that need to be executed are somehow at the top of the LRU list, and (c) the pages are not marked non-pageable.
Three assumptions that can easily be managed.

If we are talking about programming errors, a RTOS won't help you either.

Again, if we must account for bugs, what is a RTOS going to do with a NULL pointer?

If the system is running a well defined loop to handle the motors, it isn't going to call malloc, it isn't going to execute code that isn't regularly hit. It's going to stay in a few VM pages (stack, data, and code), never get swapped, and live in a high priority task.

It is tiring to have done the very things all you people say can't be done, and be accusued of ignorance or stupidity because I don't listen.
In your critique of VM paging, you say I don't know what I'm talking about. You are so busy trying to come up with strawman scenarios to "prove" that it can't be done, you refuse to see that these scenarios can easily be avoided.
My motor control loop isn't going to be paged out and you know it. It is an active small process running at high priority, sleeping most of the time, and hitting no external functions except for read(), write(), and select(). I have 512M ram on the robot, swap has 0K used. How will that be paged? It is a stupid argument made for the sake arguing. I can even mark the pages so that they are non-pagable if I ever see a problem. It is a non-issue, but we have to argue about it, and I'm the one who is [fill in the blank: argumentative, ignorant, etc.]
You talk about bugs, well, if you get a null pointer or bad code on a RTOS, that will be just as much a problem as any other.

When I did post a clear concise question, like all usenet postings, the thread gets all wild and out of hand.

That's called an engineering discussion, it is not being "combative." Maybe I'm too used to dealing with engineers.

I don't ask anyone to spoon feed answers, but lines like "You'll need a microcontroller because a PC can't do it," are nonsense. It is not based in fact, it is their preference on implementation. I have a different preference. So I ask for a logical rational explanation for the statement, and they get bent out of shape.

Well, I've spent a lot of years working on engineering projects heavily weighted down by NDA, I have nothing to point to at this time. It is frustrating to have built the motor controls, the power supplies, written the software, and built the systems over my career, but have nothing that I can show.
I am used to working with head strong engineers and scientists. I guess I'm having difficulty communicating here.

I usualy respond like that when people say things like "You should listen because --qualification--."

I posted some code, here is a picture of the motors: http://64.46.156.80/robot /
http://64.46.156.80/robot/hpim0706.jpg
http://64.46.156.80/robot/hpim0711.jpg
Some important sippets of the mouse code:
mousecode.h define MOUSE_ACK 0xFA #define MOUSE_ERROR 0xFC #define MOUSE_BAT_SUCCESS 0xAA
#define MOUSE_CTL_RESET 0xFF #define MOUSE_CTL_RESEND 0xFE #define MOUSE_CTL_SETDEF 0xF6 #define MOUSE_CTL_DISABLERPT 0xF5 #define MOUSE_CTL_ENABLERPT 0xF4 #define MOUSE_CTL_SET_SAMPLERATE 0xF3 #define MOUSE_CTL_GETDEVID 0xF2 #define MOUSE_CTL_SETMODE_REMOTE 0xF0 #define MOUSE_CTL_SETMODE_WRAP 0xEE #define MOUSE_CTL_RESETMODE_WRAP 0xEC #define MOUSE_CTL_READ_DATA 0xEB #define MOUSE_CTL_SETMODE_STREAM 0xEA #define MOUSE_CTL_STATUS_REQUEST 0xE9 #define MOUSE_CTL_SET_RESOLUTION 0xE8 #define MOUSE_CTL_SET_SCALE_2_1 0xE7 #define MOUSE_CTL_SET_SCALE_1_1 0xE6
#define MOUSE_RESOLUTION_1 0x00 #define MOUSE_RESOLUTION_2 0x01 #define MOUSE_RESOLUTION_4 0x02 #define MOUSE_RESOLUTION_8 0x03
#define MOUSE_STAT_BUTTON_L 0x04 #define MOUSE_STAT_BUTTON_M 0x02 #define MOUSE_STAT_BUTTON_R 0x01 #define MOUSE_STAT_MODE 0x40 #define MOUSE_STAT_RPT 0x20 #define MOUSE_STAT_SCALE 0x10
mouse.h class Mouse { protected: int m_fd; int m_type;
Boolean WriteByteAck(unsigned char c); Boolean WriteByte(unsigned char c); Boolean ReadByte(unsigned char *c);
public: Mouse(); virtual Boolean Open(char * device); virtual Boolean Reset(MOUSEBAT *pbat=NULL); virtual Boolean ReadPkt(MOUSEPKT *pkt); virtual Boolean GetStatus(MOUSESTAT *mstat); virtual unsigned char GetDeviceID(void); virtual Boolean SetResolution(int res); virtual Boolean SetSampleRate(int rate); virtual Boolean SetScaling(int scale); virtual Boolean SetMode(int mode); virtual Boolean ReadData(MOUSEPKT *pkt); virtual Boolean SendReadData(void); virtual Boolean EnableData(Boolean fEnable); virtual int Wait(int how, int usec=0); Boolean WaitLoop(int retries, int how); };
mouse.cpp / Writes a byte to the mouse file with error checking Boolean Mouse::WriteByte(unsigned char c) { char szerr[]="Can't write mouse byte"; int result = write(m_fd, &c, 1); if(result == -1) { PERROR(szerr); return FALSE; } else if(result == 0) { errprintf(szerr); return FALSE; } else return TRUE; } // Reads a byte from the mouse with error checking Boolean Mouse::ReadByte(unsigned char *c) { char szerr[]="Can't read mouse byte"; int result = read(m_fd, c, 1); if(result == -1) { PERROR(szerr); return FALSE; } else if(result == 0) { errprintf(szerr); return FALSE; } else return TRUE; } // Write a byte to the mouse and wait for an ACK. Boolean Mouse::WriteByteAck(unsigned char c) { TRACE_FUNCT("WriteByteAck"); unsigned char ack;
if(!WriteByte(c)) return FALSE; if(!ReadByte(&ack)) return FALSE; #ifdef TRACE_DEBUG errprintf("WriteByteAck: %02x %02x ", c, ack); #endif if(ack != MOUSE_ACK) errprintf("Invalid mouse response: %X", ack); return ack == MOUSE_ACK; }

A small little mouse robot will have a shorter stopping distance and time than a larger one. The larger the stopping time, the less of a factor atency will be.

Seriously, I was running it today, but a careless test lead in the motor amplifier burnt up a couple transistors. FedEX comes tomorrow.

Which is fine because it is a limited application.

I can, and you should be able as well, to predict what will run on your robot.

These will affect *any* system.

You can NEVER test all the code paths, not only I, but every software engineering and QA management book proves it.

It isn't going to grow anything out of the lab.

These are very data centric games. The process space for these is probably bigger than available RAM.

When you said "swapped out" I knew you were a mac guy. Processes don't swap out in OS/X like they did in the old mac. The VM paging is pretty clean. Still if you are using more memory than RAM...

OK, if I don't play Halo on the robot, will you admit that virtual memory is not going to be an issue?

Less memory than you would think. Video capture devices typically use NTSC resolution which is tiny. LOTS of CPU, but a CPU bound process that is not I/O intensive can be put in a lower priority an not affect responsiveness of the system. Essentially suckup unused CPU cycles.

Yup, see above.

Not much memory. I could asign a byte for every squre inch of the house and still be under 64M.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Mon, Apr 11, 2005 at 11:38:30PM -0400, mlw wrote:

Excellent.
You could be right in that I'm assuming too much. Many robot implementations brake up their function by organization into seperate individual "behaviours." Typically these behaviours lie latent until the right set of conditions exist at which time they are activated. While your "motor control" process is always active, the "avoid" behaviour is typically only awoken when some set of obstacle sensors are activated.
So, no, I wasn't assuming that the behaviour that takes control of your robot in response to obstacles was running all the time. And when awoken, I was assuming that it would write its motor control commands out and the motor control process would do as it is told. Thus, it could be asleep for a long time before it is actually needed.

Depends on the RTOS and the architecture it is running on.
Again, I'm thinking of a model where you have broken your robot control down into a collection of processes. Am I wrong to assume this? I would have thought that would be one of the strong points of Linux - process management and the ability to use the rich Unix development environment. If you are making one giant process then I'm not sure you are really making a case for using Linux in the first place.
But there are many bugs that might cause a process to loop. Assuming an independent process model, this will largely not affect the other processes such that they can still keep running. Maybe you've got a bug in a high level process that does something relatively inconsequential such as, oh, I don't know - being beligerant to your neighbors using the speech synthesis or something. Lets just say, hopothetically speaking of course, that it starts looping, repeating the same old stuff monotonously.
A preemptive RTOS will still ensure that your critical real-time processes that you have designated as such will get the cycles they need to keep your 'bot under control, even though you have an errant process trying to consume too much CPU.
Of course, nothing can protect you from every possible mistake.
But I'm not really advocating RTOS's, per se. We started this simply talking about motor control, which is a real time process.

Very good.

Not too many people have said certain things cannot be done. I can only speak for myself and my position is simply that a PC motherboard is not a particularly good platform for the low-level control of a robot. You do seem to agree with that somewhat based on some of your responses to others. I get the impression that maybe you've challenged yourself to do this and if that's the case, then no amount of information or "proofs" or anything else is going to change your mind.
But a lot of your problems pretty much vanish if you use a good old reliable microcontroller. Pick a flavor - we've got Basic, Forth, C, Pascal. AVR, PIC, 68xx, Motorola DSP, 8051, ARM. Unix tools, Windows tools, expensive tools, free tools. Interpretted, compiled. Flash memory, eeprom, serial eeprom. Breadboards, polished boards, surf boards (OK, how'd that get in there?). So much variety to choose from, inifinite diversity in infinite combinations. More flavors than Baskin Robins. There's bound to be one you can find acceptable to you and within your budget.
Come on ... you know you want to.
Why not make your $400 or $500 robot a $500 or $600 robot?

Nothing in all that time - not home made robots or anything?
OK.

OK, that's pretty cool. Were you able to retain quadrature? I'm assuming so if the mouse interface is still working.

I can predict cause and effect. It's harder to predict actual events, though. You know, Murphy and all that.

But you can calculate worst case response time by examining code paths.

Actually I'm a "new" Mac guy - I know very little about MacOS 9. I'm really a FreeBSD guy who switched to a MacOS X desktop about a year ago, and still have a handful of FreeBSD systems for various purposes in my home office / lab. I don't claim to be an expert on the *BSD VM system (there's only a couple of people who can claim that) but I do have a working knowledge of it, as well as most of the FreeBSD internals. Linux less so.

Why don't you want to play Halo on your robot?

Sounds like you have a plan. Keep us updated on your progress.
-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

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.