It was a lightly loaded system. The only purpose of the code is to point out that the system is somehow measuring time at a resolution of microseconds. It further shows that the overhead of getting into and out of the kernel is less than a millisecond. Clearly, when the scheduler pre-empts the process and resumes it some number of milliseconds later there will be a gap in the measured times, since there is only one process running at a time on a single processor system.
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.
In any event, a short burst of sys calls in a lightly loaded system does not convince me that you could run one or more PID loops as user processes in loaded system. I still believe that the variable latency would require tuning the PID loops to be too sloppy to be useful.
The bot I am building runs 4 PID loops at a 300Hz update rate. Two of the loops are closed with optical encoders on the drive motors and two with pots for moving the vision cameras around. Rather than thrash with keeping that load happy in a 'nix environment, I am using a DSP56807 with A/D's, encoder hardware and full PWM generation. I am planning on running Freebsd or maybe Linux on the PC that will be controlling the motion control system. First I need to finish the motor controller. Unfortunately, I also need to make a living through this process...
I am a firm believer in off-loading stuff to dedicated microcontrollers for robotics applications. PID works best with good velocity measurement. Slapping a US Digital encoder on your motor shaft and letting it spin can easily generate 100K edge transitions per motor. I'm in favor of letting a microcontroller keep track of that kind of signal traffic. However, these are my opinions and MLW is entitled to his opinion as well.
Nope, the process is doing the PID itself, so it is always running.
Well, "a number of process" is a good question. I haven't decided yet. I'm not sure whether it is a number of self contained programs, or a number of discrete threads in a single program.
Individual program are cool because of process isolation and independance. But, to share data I need to use a shared memory metaphore. If I use threads, I can just share memory between navigation and control.
A standard OS won't starve a high priority process either, it just isn't deterministic about it.
On any system, that's why all this is fun.
It has behaviors which a "real time" OS does make easier, but it need not be a real time process.
I disagree -- obviously -- This isn't to say it is a trivial matter, but good code practices and knowledge about OS design can make it very doable.
As I've said in various ways, based on what I know, and what I've done professionaly, I "know" this is doable with PC hardware.
I want the hobbiest not to have to deal with the multiple tool sets required to write code for multiple platforms. i.e. PC and [n] micro-controllers.
Lastly cost, if I can do it in under $400 that would be even better.
Actually, no, no I don't. Hell no! I want to run code on the robot exactly as I would on my desktop. I want an clean homogenous and seamless design.
Because $400 or $500 is cheaper and thus better for students.
Just the robot I posted pictures of. I've done lots of stuff in lots of fields and gotten paid.
Sure, quadrature is nice and clean.
Murphy haunts us all, but good engineering is helpful at keeping him at bay.
Not really. If you look at a non-trivial program, it is virtually impossible follow all the function calls.
Take a disk write, for instance. At the lowest level, reading a sector off the disk may average 1/2 seek time, and 1/2 the rotational period of the platter, but the modern drive electronics, aften times get in the way, and read more than you want, map bad tracks, and stuff like that.
You can only work on a general assumptions.
Take a call to malloc. Malloc is a source of false parallelism in threaded programs because the heap must maintain consistency for all threads, so access is serialized via a mutex or similar construct.
You *never* know how slow malloc will be.
I like the mac. I'm thinking of a minimac for the wife. Anything to get here away from Windows.
Yes, I like freebsd a lot, and a few years ago I would have said, without reservation, that it was better than Linux, but I'm not sure that is true anymore.
Actually, when I took out the printf logging it dropped to 2%!
CPU starved doesn't bother me as long as I am not running competing high priority tasks.
Or beowulf clusters or search engines.
Well, hopefully, the robot system code will work well enought that they don't need to fool with it.
If they write code that kills the robot, that is something they will need to learn.
Assuming that memory use grows infinitely, which we know it does not in a crontrolled environment. The system could be setup with process limits.
Excellent, yes.
True.
But there is none.
Exactly.
What is being missed is after proofs.
Probability, while the system is not a real time system, under nominal conditions, the likelihood of the response time is perfectly accptable, and the average variance can be managed. (IMHO)
Error correction, even if the system "hiccups" once in a while, is it correctable? And yes it it.
This is not a life saving medical instrument, it is not military grade hardware, it is a hobby horse.
It will run fine, will it be "perfect?" Of course not, but a mobile robot operates in an uncontrolled world with imperfect surface and loads. It will never be perfect, start with that assumption, and build in lots of error correction.
You can mark important tasks as non-swapable. And yes, I can disable swap in Linux.
$1.50 dual D/A, $3.00 in parts (A couple TLO84 comparitors, capcitors, resistors) and You've got a PWM controller.
"Expected coditions" is the robot computer.
Like I said earlier, I'm not making a life support robot. I am making a hobby robot. Basically a consumer item, which, by the way, can be "professional."
I'm not sure. Sell it, write a book on it, put up a detailed site with pay pal, or just the site. I'm not sure. Thinking about it.
A fairly well discredited process in the software engineering world. The current buzz is "use cases." My personal preference is "unit testing."
Mine has two.
All add another itx system and use MPI to cluster them.
It isn't going to merely be a line follower.
Like all "mistakes," it will get corrected when it happens.
It is using a internet router being used as an access point connecting to only one other access point, mine. It isn't open to traffic except through something under my control.
I just posted code and a description, right now it is velocity, but path planning can be used to constantly update the target and use accumulated position instead of instantaneous motion.
That would agree with what people have said about printf.
Actually all the search engines I've seen have been I/O-starved rather than CPU-starved,
If you don't allow people to modify the system, it's just a toy. IMHO.
Of course.
Even more proofs. Basically the two courses were designed to show the student that going back to basic principles and proving
*everything* is not only a good idea, but necessary.
Sorry. I didn't mean that you actually *couldn't* disable swap. I've done it before. I just mean that if you do, why are you running a multitasking operating system.
For a PWM controller, perhaps a $3.00 microcontroller and a handfull of parts (a resonator, some caps, etc.) is all you need.
I'm still looking for the perfect hobby robot platform.
They each have their place. I like unit testing (JUnit is wonderful for me) also.
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.
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. ;-)
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.