Do you need "real time" for motor control

Brian Dean wrote:


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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

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 http://enerd.ws/robots /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
D. Jay Newman wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

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.

Nice.
I wish you luck. A lot can be done with Linux. -- D. Jay Newman http://enerd.ws/robots /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I think there is a slight misconseption here: real time doesn't mean fast. It means predictable worst-case behavior. I.e. you have an upper bound on the delay in which you react to input. I think in that sense all robot control systems *have* to be real-time.
Now, for specificly control loops for servos: if you go with traditional control loop theory and implementation (read PID loop), your loop delay is very critical. In the complex frequency domain that delay will be turned into a constantly growing phase-shift by the frequency-axes. As you probably know all stable control loops must have less than unity gain at the 180deg. phase point. Since the loop delay adds an additional phase-shift that grows as the frequency grows, it can make your control loop unstable pretty quickly. And even if it does not, since your 180deg. point gets to a lower frequency point your ability to control the device will degrade. I mean the control-loop error will be biger for step-function input signals. In this sense just sampling the inputs and the outputs (implementing a PID loop in SW) adds a loop delay of at least one sample-period.
My experiments show that if you want to have an agile PID control loop with a small D.C motor (540 type R/C car motor) you would need a control-loop frequency of at least 100Hz.
Another important factor for control loops is that the periodicty of the updates must be fairly precise. You might be able to control with aperiodic sampling but the theory for that is significantly more complex. If you just run a PID loop with the asumption of peridodic sampling whan it is in fact aperiodic, you interoduce additional noise to your control signal. In other words clock-jitter in the sampled control loop directly transfers to output noise.
Regards, Andras Tantos
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Andras Tantos wrote:

That is exactly right.

Not so. PID has nothing to do with a fixed delta T.

That assumes that the motor is more responsive than the worst case sample rate.

OK, no problem I have a bigger electric motor that is much less responsive than a small DC motor, and my average sample rate is 100HZ.

Not true.

A lot of people are confusing PWM generation with PID calculation. I have an external PWM generator, and it is updated at about 100HZ. += 0.01 seconds.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Snipped much content...

Every control loop has a delay from when the measurement was taken to when the action upon that measurement reaches the controlled device. This delay time can be critical for the stability of the control loop. You're right it has nothing to do with PID loops. It has to do with *all* control loops, including PID loops. For continous time control loops the delay is usually rather small compared to the other time constants in the loop and that's why it's often disregarded. For digital control loops however the delay must be at least one sample period, which can in fact be in the same order of magnitude as other time constants in the loop. If that is the case, than the additional phase-shift from the sampling delay can be rather substantial. In other words: your asumption that the discrete time implementation of the control loop is a good approximation of the continous time equivalent circuit is not true any more. And digital PID control loops have this assumption.

Yes. See above.

You can do non-periodic sampling but the customary theory assumes periodic sampling. You would probably have the invent your own control loops for that. You almost certainly can not use a traditional PID loop there. But if you have references to the contrary, I would be interested to read about it.

No, I'm not. PWM generation is just a way of going from the digital to the analog domain. A D/A converter if you wish with poor anti-aliasing characteristics. I'm talking about the whole control loop, from beginning to end.
Regards, Andras Tantos
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Andras Tantos wrote:

Very true.

If it exceeds a duration which can't be controlled or is unaccounted for.

Yes, my argument is the assumption that a fixed delta T is required.

More or less that is true.

Why? If you could control a motor accurately with a 50hz sample rate, why would a variable rate between 400hz and 50hz be a problem?

Your argument assumes an acceleration response the exceeds the worst case latency. If this is not the case, then this argument does not apply.

Not "customary theory," so much as "customary implementation."

Just scale the encoder counts based on actual change in time. Here are some sippets. The code works, but I am ironing out some kinks and last night I smoked the power transistors with a careless test lead.
int ScaleMovement(int ticks, int elapsed) { return (ticks * SCALE_FACTOR)/ elapsed; } int PIDControl::CalcPID(int actual) { int error = m_target - actual; double ecur = error * m_gain_error; double eint = m_error_total * m_gain_int; double edif = (error - m_error_last) * m_gain_dif; m_error_total += error; m_error_last = error; m_pos_last = actual; return (int) round(ecur + eint + edif); }
int encvLeft = enc.GetEncoderValue(LEFT_WHEEL); int encvRight = enc.GetEncoderValue(RIGHT_WHEEL);
int valLeft = ScaleMovement(encvLeft, elapsed); int valRight = ScaleMovement(encvRight, elapsed); int speedLeft = pidLeft.CalcPID(valLeft); int speedRight = pidRight.CalcPID(valRight);
The only difference betwen the above code a classic PID implementation is that elapsed time is used to factor the PID correctly.

Sure you can.

I couldn't point you to a specific book as a lot of the knowledge comes from many sources, some really old and disty motor control books, and old Galil motion controller manual, and lots of hands on experience.

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

Well, if 50Hz is enough, why do it sometime at 400Hz? In other words: if your loop is stable with a 20ms delay and with whatever filtering you have in place, what 400Hz update rate buys you? But putting that aside for a minute, let's examine your solution:
From your example code below you seem to assume that the rotation speed (input) was constant during the whole time of the unsampled period. You can model it like this: you have your regularly sampled input (let's say at 400Hz and let's call it 'S') and than you randomly replace some input samples with their previous values (sometimes maybe more than one up to 8 so that you can get down to 50Hz). Let's call the modified sample sequence 'W'. Than you run your regular PID loop on the (now periodically sampled) input. This model should give the same set of output than your original code, but now using periodic sampling which can be attacked by traditional methods.
You can further modify this model: instead of replacing some input samples with the previous values, you modify them such that they match the previous value. You can rephrase this even further, saying that your new input (W) is your original input (S) plus another stream of values, where some samples are non-0 - their values are selected such that you get the effect of duplicating some values in the stream. Let's call this new stream of data 'N'.
So, now your modified input (W) is your original input (S) plus this additional signal (N):
W = S+N
If you had a regular 400Hz PID loop, your control signal would be its response to S, wihch is PID(S), but instead you're feeding it with this modified signal (W) so your control signal will be PID(W). Since your PID loop is an otherwise linear system, you can separate its output to individual responses to each input:
PID(W) = PID(S + N) = PID(S) + PID(N)
Here you can see that the control signal that you will be giving your motor will contain the control that you would give it would you sample the original input periodically (PID(S)), plus the PID response to that additional signal (N) that you've introduced by not sampling it periodically (PID(N)). Thus you can look at this second input stream (N) as a disturbance to your original signal (S), also called noise.
If you knew the transfer function of your motor, you would also be able to calculate the noise that you've introduced to the rotation speed of your output shaft like this:
Rotation_noise = Motor(PID(N))
You feed this noise back to the input of your control loop (closing the loop on the noise as well) giving your final noise-floor for your solution on your output shaft:
Total_Rotation_noise = Motor(PID(N)) / (1+Motor(PID(N)))
if we disregard the transfer function of your feedback circuit.
Wether that effect is important in your scenario, you are the only one to judge, but it will degrade your performance to a certain degree.

In other words: your minimum sampling rate is determined by the acceleration response of your system. Which (since it is a mechanical constant) says that there *is* a minimum acceptable sample rate, in other words a *maximum* acceptable response time, which is - by definition - a requirement for a real-time system - to answer your original question in the subject line. And if you can meet the minimum requirements, doing the extra work of evaluating your loop more often occasionaly, wouldn't buy you much.

Well, I guess I have to correct myself here: you can, but you have to tune it for the worst case, in which case, again, doing the extra work wouldn't buy you much.
Regards, Andras Tantos
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Andras Tantos wrote:

Well, the 400hz was a strawman, but there is real need to have a higher rate than the worst case.
If 20ms is my worse case deadline and my OS can typically spaz out for some limited period of time not likely to exceed 15ms. I can't depend on any specific 20ms period. Right? I can, however, depend that the system won't go away for more than 15ms. If I try to sample every 5ms I will never miss my 20ms deadline.

What "unsampled" time? There is the a sime that covers an elapsed time and that is assumed constant, yes. We know this to be false, but give the nature of the gearbox, wheel, and motor, well within error margins.

What? No, I read the encoder values each time. I'm not sure where you think I am reusing encoder reading using privious values.

Which I never do. Where do you think you saw that?

A "real-time" system has one very important quality: A deterministic and predictable response time.
Linux or a BSD does not have this, but they do have a fairly reliable behavior. You can be fairly confident that you will be called, worst case scenario, 50ms, usually much lower.
By coding around the variable response time of the os, you can do it without a real-time system.

Not needing the cost of a micro-controller comes to mind.

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

<sarcasm> Ah, so you're trying to work around the self-imposed limitation of not having predictable behavior from the OS. ;-) </sarcasm>

Yes, that's what I was refering to.

Without pasting in the lengthy argument, I'll try to explain it to you:
You are saying that you don't know how often you're process will be executed, but you do know *when* it gets executed. You're dealing with that fact by scaling your input numbers with the elapsed time between invocations. You will not sample your input signals (your encoder speed) in a regular interval, but you will assume that they stayed constant during the time between your last and current sample.
This is not a model that can be tackled by traditional signal-analysis techniques, so I had to transform your system to one that, given the same input will produce the same output, but operates on a regular sample interval.
To do that, first I had to 'fill in' your signal with the missing values in the data points where you didn't make a sampling. That's where I've used your assumption that the input signal didn't change, so I've used the previously known sample. This is the signal, I've called 'W': the signal that you operated on with values filled in to the points that you've missed it in such a manner that your algorithm would produce the same output for both the original irregular, and this 'W' signal. (Here I mean that your program would produce the same outputs at any given point in time, if it was called at regular intervals for 'W' or at irregular intervals for the original input values.)
For the arguments I made I also needed the 'actual' input (encoder speed) signal even at the locations where you didn't sample it. (Here I mean time locations where you didn't sample because your porcess wasn't invoked at that instance of time. I know you sample every time you're called but sometime this call is missing. That's what introduces the irregularity that I'm trying to model here.) This is the signal I've called 'S'. These two signals are somewhat different, since the assumption that the signal didn't change when you didn't look at it obviously somewhat incorrect. This incorrectness in my model is measured by the signal 'N'. If your assumption is correct, than values of 'N' are small, if youre assumtion is incorrect, the values are large. In any rate 'N' is not constant zero.
These changes made the ground where normal control theory could be applied: from now on both the input and output signals are simple discrete time signals, and your PID loop also operates on a regular intervals. Still the system produces the same command signal at its output as your original algorithm would. Again, this was needed to be able to make arguments and to quantify the effects on the whole system of your solution to the inablity to sample at regular intervals.
After this setup I've examined what error will be introduced in the controlled system by this additional 'N' signal. Note again, that this 'N' signal is the product - and in this sense the representation - of the irregular sampling of your design. So, by estimating the error introduced to the controlled system (motor shaft rotation speed) by this 'N' signal, I'm trying to calculate the effect of the unregularity of the sampling.
I came up with the result of:
Total_Rotation_noise = Motor(PID(N)) / (1+Motor(PID(N)))
This is with the assumption that the feedback circuit is ideal. Now, I can't tell you if this signal is important, all I can tell you is it's non-zero. Well, actually I can tell you one more thing.
Your system's response for a control input ('C') will be the following:
Total_Rotation_controlled = Motor(PID(C)) / (1+Motor(PID(C)))
Of course if your control loop is working correctly than:
Total_Rotation_controlled ~= C
In other words a good control loop does its best to keep the output value as close as the control input as possible. However note that this is the same equation as the previous one, for the noise. This means that your control loop will do its best to copy the noise 'N' to the output as well. What I'm trying to point out here is that you introduce this noise at the worst possible point to the system: you will apply your whole closed-loop transfer function to it and not the open-loop one.
Hope it cleared things up.
Regards, Andras Tantos
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Andras,
That was poetry.
Thanks (wiping a tear from my eye)
Mike

won't
miss
and
say
input
8
sampled)
that
in
the
in
missed
was
that
didn't
assumption
applied:
to
to
to
can't
as
I'm
transfer
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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?

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

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

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.