Do you need "real time" for motor control

Wayne, I ran your code on an AMD 650mhz machine running Freebsd 4.6 with no load beyond X and the firewall and got the following results:

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

Bob

Bob:

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.

-Wayne

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.

Funny.

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.

And no way to reach the robot.

What kind of motor control, velocity or position?

Where is your encoder within the system?

How many counts per second will you generate?

Do you have any guesses as to the mechanical time constantant of the components between the copper winding and the encoder.

If you plan on closing the loop with an encoder not affixed to the motor shaft, how many counts of hysterisis do you have?

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.

It is attached to the back of the motors

http://64.46.156.80/robot/hpim0706.jpg>

Per second? Depends on the speed of the motors.

What? copper winding? Like the motor's windings?

The encoder is on the motor shaft.

http://64.46.156.80/robot/hpim0711.jpg>

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

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.

Nice.

I wish you luck. A lot can be done with Linux.

-- D. Jay Newman

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

how many seconds (minutes, hours, days, years?) will this be able to count at 2.4 GHz?

Rich

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

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

Oops, they must have added some bits while I wasn't looking. A quick google says the counter is 64 bits.

MCD