# Do you need "real time" for motor control

We've been debating about "real time" response for motor control. In the right context, I don't believe it does:
A mobile robot with non-zero mass. A mobile robot moving at a non-zero velocity. The motor system is based on servo motors, not steppers.
Now, the robot can not stop infinitely quick. It must stop with a measured deceleration. If it attempts to stop too quickly it can skid or fall over. Correct?
What is the "real" stopping period of a robot? It depends on the surface, the wheels, the shape of the robot, the speed of the robot. The truth is that it can easily be at least one second.
Now, a real time system is nice, but it is not required to control the motor speed. As long as you can predict trends (error increasing or decreasing), factor time between samples, and can respond reasonably within the motors ability to accelerate. The hard core time requirement of an RTOS is not nessisary. This is not to say that the system can go without responding for too long, but a well ballanced system's response fluctuates but does not stop. A properly configured Linux or a BSD running on a PC can operate within these parameters.
As for one person's argument about safety, I'm not sure if .01 seconds makes a huge difference in stopping distance, but I don't think it is a real problem.
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
mlw wrote:

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?
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Andy P wrote:

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

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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
JGCASEY wrote:

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

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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
JGCASEY wrote:

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

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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>

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

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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Mitch Berkson wrote:

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.

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
mlw wrote:

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.
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>

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 <stdio.h> #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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Wayne C. Gramlich wrote:

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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>

[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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Wayne C. Gramlich wrote:

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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>

[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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Wayne C. Gramlich wrote:

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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>

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