Do you need "real time" for motor control

Moving at just 4 mph, in just .01 seconds that robot moves about 3/4 of
an inch (.704 inches to be exact).  To get something moving that fast,
youd have to drop it from ~1.5-2 feet from the ground.  Take a 50 pound
somethin or other with a nice edge (assuming a 50 pound robot, with
batteries and motors and all) and drop it onto your shin from ~1.5-2
feet above it.  See if it moves your shin 3/4 of an inch.  I guarantee
those bones are not 3/4 of an inch thick. In other words, it will take
much less than .01 seconds for whatever you dropped to travel through
said bone.

If you have bumper switches, say, 3 inches in front of your robot...they
can compess a total f 3 inches if needed.  As soon as they touch
something, they send a signal that takes only a nanosecond or so (a few
at the most) to trigger emergency braking.  reverse the motors.  Even if
it cant stop inside that .01 seconds, and can even only half it's speed
in the time it takes for it to travel those three inches of the bumpers,
you take it's impact force down to almost 1/4.  Possibly even more,
depending on your braking system.  So putting that into the above
experiment, now drop a 12 pound thing onto your other leg (since your
first one is broken) and commence screaming and swearing and possibly
bleeding, then limp away on leg #2.

Now do you think .01 seconds matters in safety?

Assuming the robot goes 4 miles per hour, that's a pretty fast clip for a
robot, but OK.


Not sure I know why this is here.


Yes, very dramatic but a pretty silly argument. You are using a higher
presision than you really have.

0.01 seconds, in a real world environment, is beyond practical measurement.
What triggers the event that causes the robot to stop? Surely some
real-world event, be it a bumper or a human hand hitting a switch, could be
affected 0.01 by wind currents from an open window.


Again, your bumper material what is it? If it is compressable, it will need
to compress some amount before it can trigger some sort of switch. How long
does that take? Does temperature affect this substance? If it is colder
will the bumber be less compressable and thus have faster response time?
How about on a hot day? will the material be less rigid and thus take
longer to compress enough to trigger the switch?

If you put the switch on the outside of the bumper, how much travel does it
have before a connection. The bumper will still need to compress some
amount before it provides enough force to trip the switch. What sort of
debounce capacitor do you have?

You are working with precisions that are not realistic for the environment.



I still think its fine.

Wouldn't any mathematical analysis be pointless
until you have built your robot so you can plug
in the actual figures?

Start with your requirement that it *must* all be
controlled from your Mini-ITX board and design the
robot and its actions around any limitations that
may result.

I would suggest you build the robot and see what
happens. If it fails to stop in time worry about
it then. The solution might be simply to move
the "whiskers" or "bumpers" out a bit further
from the robot. Maybe when contact is made a little
extra spring in the bumpers will do the stopping
by itself?

It may be a matter of simply setting your sensors
to trigger at a safe distance. This could even be
velocity dependent. As you go faster the bumpers
could move out in front. Or a more practical method
using light have the angle of the beam change with
velocity to detect an obstacle at a safe distance
for that velocity?

With some ic logic you could arrange it so that
*any* combinations of contacts desired would
disconnect the motor/s automatically until over
ridden by the main program.

Just go for it, forget about the doubters. If it
turns out to require a uC you can always add that
later?


-
John

Just an aside, um, wouldn't it make sense to design the system before you
build it?

While I disagree with he conclusions drawn by the post, I appreciate the
work done. It is exactly the sort of up front work one should do.


If this were a business, I would call that a product requirement.


It is in the process, but it never hurts to do the design up front.

Up to a point.  Things never work for me as I plan
them anyway as there is always something I didn't
take into account, like the rocking tank base I
mention in another thread.

It really depend how good your model is. Ultimately
you will have to build and test the real thing. Why
not just go ahead and do just that, particularly as
you feel it will work.

My impression is your requests for input result in
people saying you can't and you saying you can...



Often though you might be planning for things that
never eventuate and neglect things you never thought
of. Those that know, never do, to find out how to do
it anyway.

That was the point of my suggestions. Ok, so what if
you were wrong and the post was right. Maybe there is
a way around it anyway. Necessity is the mother of
invention.  If the time to stop is unknown than give
yourself a system that is adaptable to that. Just as
you whiz along the road in your car your obstacle
detection system is planning well ahead. You don't
wait until your touch sensors signal your head going
through the front screen window after hitting a tree
before you take evasive action. This whole .01 second
thing may not be relevant if the software is smart
and the obstacle sensors long distance.

That was the point I made in another post as regards
an intelligent system working around the limitations
of the hardware.


-
John

Well, there are always unplanned circumstances, but a well engineered
product isn't hit by many.


Well, I like to know something is going to work before I spend the money on
parts and time building.


I never asked anyone "if something could work," as I've done the engineering
first. When I have asked questions, they have been specific "which would be
better" types of questions, but alas, people have ignored the question and
again said it couldn't or shouldn't be done.

A good engineer tends to have fewer unplanned circumstances.


The post was not right. I proved it wasn't. Number don't lie. In the case of
a mobile robot, 0.01 seconds is not an "real" number. If your robot is
moving a 4 miles per hour and makes contact with a wall or barrier, 0.01
seconds isn't going to make one bit of difference because in the physical
world there is so much slop, that if it didn't come from the robot, it
would come from the temperature, the angle the robot hits a barrier, or
what ever. There are too many factors involved to properly calculate.

The real issue is to not hit the barrier.


Time to stop can be known, only to a point. You have an unpredictable
surface and tire ware, just to name a couple factors, that could easily
affect the stopping distance.

This debate isn't about the system be adaptible or not, it is about whether
or not you need a "reat time" OS to control the motors.

On Sun, 10 Apr 2005 19:54:47 -0400, Andy P


Maybe if you have a robot that is only an inch long and could
actually stop in .704 inches it might make scense. Scale this up
to a robot railroad locomotive moving at 4mph and .01 sec is
probably plenty of time. You must be thinking of only those
little things that skitter about on the floor.

Yes, you do need "real time" for servo motors. The sample period of a
servo system is an implicit part of the math. If the period varies, you
must compensate the measurements. Even with a hardware assisted sample
period, a variable delay in updating the motor drive will cause loop
tuning problems.

Bob

Why?

Suppose this:

while(1)
{
gettimeofday(&tvCurrent,NULL);
if(!encoder.Update())
{
        errors++;
        continue;
}
unsigned long elapsed = ((tvCurrent.tv_sec - tvStart.tv_sec)*1000000)+
                        (tvCurrent.tv_usec - tvStart.tv_usec);


int speedX = pidX.CalcPID(
                ScaleMovement(encoder.GetEncoderValue(0),
                elapsed));

tvStart = tvCurrent;
}

Why does this have a problem?

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

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.

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.

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 <sys/time.h>

#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

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

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

[snip even more stuff]


Bob:

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.

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

[0]: 1113279875.766695
[1]: 1113279875.766702
[2]: 1113279875.766708
[3]: 1113279875.766714
[4]: 1113279875.766721
[5]: 1113279875.766727
[6]: 1113279875.766734
[7]: 1113279875.766740
[8]: 1113279875.766746
[9]: 1113279875.766752
[10]: 1113279875.766760
[11]: 1113279875.766765
[12]: 1113279875.766772
[13]: 1113279875.766779
[14]: 1113279875.766786
[15]: 1113279875.766791
[16]: 1113279875.766797
[17]: 1113279875.766805
[18]: 1113279875.766811
[19]: 1113279875.766817

5uS to 8uS. Interesting. Still faster than I expected though.

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