Do you need "real time" for motor control

I've seen some I2C D/A converters for about $1.50 at digikey.

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

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.

Lookup PCF8591

What do you mean by real time? Is there an upper limit to the latency? If so, that would seem to satisfy a real time constraint even if it's a real slow time and you can just design the system to work slowly enough that there won't be any problems. If there's no upper bound then this can't work all the time.

Mitch

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

Andras,

That was poetry.

Thanks (wiping a tear from my eye)

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.

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.

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

Oh my.

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

Wierd, they were cheaper. I'll have to find something else.

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

Well, a RTOS has a deterministic and predictable latency, a non RTOS does not. '

There is a "practical" upper limit that is not garanteed.

Is it 100.00000% absolutely perfectly reliable? Of course not, but the software probability of failure is no worse than anything else in the system.

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

It has problems for a couple of reasons:

First, operating system timekeeping calls that I have messed with tend to have very large granularity. the worst I have seen are microslop at

18.xxx ms. The unix variants will return an answer alluding to microseconds, but generally the time is only kept to 10's or 100's of microseconds. This problem could be avoided with a hardware timer providing adequate resolution.

The second reason is that the PID algorthm is not linear with respect to time. Approximations can be made to fix it, but it is not really worth the effort.

You could run a PID servo system in a non-realtime OS if you hung the PID code on a high priority hardware timer IRQ and had hardware support for encoder tracking and PWM generation. I would not want to run a disk based file system in this environment, but a RAMDISK would be fine.

The encoder hardware is required to keep the measurement period accurate and near in time to the PWM calculations. The PWM generation needs hardware support because running software assisted PWM off a single frame timer timer thrashes the interrupts so badly that you spend more time getting in and out of interrupts than servicing your PWM.

All this hardware support can come from a $500 hardware timer board or a $50 microcontroller board. Then you get to write and debug device drivers and see why wierd stuff happens when the moon phase is just right on odd Thursdays and interrupts get missed.

You're right. Processes merely get suspended when they aren't running at the moment. And in Linux on a single-processor system only one processor runs at a time. And if a process is not run for too long, why, parts of it can get paged out...

And your motor control alone takes 5% of the CPU. Imagine what will happen when you add in image processing. And if your sensors are as efficient as your motor driver, even with 1% per sensor, this robot is going to be CPU-starved very quickly.

And frankly I've rarely seen a Linux box CPU-starved outside of animation farms.

The only time my robot's Mini-ITX boxes get even 100% CPU utilization is when I'm recompiling the system. And even that leaves plenty of time to do other things (the compilation becomes a bit slower, but not enough for me to notice).

What? You mean you won't allow users to write their own programs? Or do you require them to write fully debugged programs to your exacting specifications?

Because you're running a non-real-time OS. I suppose that you could merely disallow paging. This works until memory gets full and the system crashes.

I would base it on operating system theory and engineering. Basically on any non-real-time OS a path can be pointed out that would take longer than any arbitrary time. This is by definition. If I couldn't point out such a path, it would be a real-time OS.

Rigerous mathematics showing the minimum and maximum latency.

Of all the math courses I took at the university, the one that made the most impact was Math 402: Proofs. Basically this course showed students that the obvious answer isn't always the correct answer.

I even registered for Math 403, but they changed profs and threw in new curves and lost me totally. Hey, I was either an EE major or a German major when I took the course. :)

That's a good start. How much of the CPU does this task take up? And how much of the system RAM? You can't mark everything as non-swappable or you might as well run DOS.

I still can't understand how this is easier or cheaper than a basic serial or USB motor controller.

If the system only works under expected conditions, why bother making a robot? I want my robot to work under unexpected conditions.

And if I were making a professional robot (especially in the medical field), you bet there would be testing under *extremely* unexpected conditions.

Perhaps this is a basic misunderstanding. I thought that you were trying to *sell* this robot. Not just build one for your own amusement.

Yes, code paths. A fairly well-known term in software engineering and testing.

Don't forget that on the Mini-ITX systems you've mentioned they only have one RAM slot.

And come on, eventually you will want to do something bigger and better.

A basic wall-banger won't use much memory, but what happens when you want it to take wedding photos?

I believe that programmers have a technical term for such a thing. I believe it is called a "mistake".

I have experienced the results of aq system under a DOS. It can be devastating.

And what happens when your robot is out at a show and isn't behind your firewall?

Yes, it is a robot. However, it is running Linux. There are a lot of script kiddies out there with too much time on their hands.

-- D. Jay Newman

I ran the following program on a Red Hat 9 distribution of Linux with the 2.4.20 Kernel on a 1.4GHz Sony Viao laptop (i.e. plenty fast, but not blindingly so):

#include #include

#define SIZE 20

int main(int argc, char *argv[]) { struct timeval timevals[SIZE]; int index;

/* Read the clock as fast as possible: */ for (index = 0; index < SIZE; index++) { gettimeofday(&timevals[index], (struct timezone *)0); }

/* Print out the results: */ for (index = 0; index < SIZE; index++) { (void)printf("[%d]: %d.%d\n", index, timevals[index].tv_sec, timevals[index].tv_usec); } return 0; }

Some example results are:

[0]: 1113276767.827733 [1]: 1113276767.827734 [2]: 1113276767.827734 [3]: 1113276767.827735 [4]: 1113276767.827735 [5]: 1113276767.827735 [6]: 1113276767.827736 [7]: 1113276767.827736 [8]: 1113276767.827736 [9]: 1113276767.827737 [10]: 1113276767.827737 [11]: 1113276767.827738 [12]: 1113276767.827738 [13]: 1113276767.827738 [14]: 1113276767.827739 [15]: 1113276767.827739 [16]: 1113276767.827739 [17]: 1113276767.827740 [18]: 1113276767.827740 [19]: 1113276767.827741

Note that the microsecond clock is, in fact, keeping track of microseconds. I guess the days of millisecond resolution clocks in 'nix are over.

-Wayne

"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.jpghttp://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.

Do you believe it? I would be pretty surprised if you can get in and out of a system call in a microsecond. Further, system calls are often the trigger for task swapping.

Bob

[snip some stuff]

Bob:

The reason why I wrote the code is because I was pretty sure that Linux was only running the clock at millisecond resloution. But I was wrong. If you have a 'nix box, you can take the code that I posted, compile it, and either verify a similar result or post a contrary result. So, the short answer is "yes, I believe it".

-Wayne

Wayne, I am pretty surprised at microsecond timing. I am even more surprised that the process did not swap on the system call. Was there any other load on the system? It has been 4 or 5 years since I have been deep into unix timekeeping. I probably will give it a try.

If you do run across a swap boundary, how long is it swapped out for?

Bob