1. Home
  2. General Robotics Forum
  3. PC based robot design -- musings

PC based robot design -- musings

As I am working on the robot software. You make changes here and there, and you start to think about how to make things easier/better etc.

My main PID loop has been rewritten to be more of a time slice mechanism for various periodic systems. (I'll post new code on

formatting link
when it is in a form I'm satisfied with)

Baically, it has been redesigned to accept task objects and a run priority. The PID object runs every time, but things like the keyboard scanner runs much less often, the report object runs MUCH less often.

I typically would have the OS do this sort of thing, but there are so many periodic tasks, I would have so many small tasks calling usleep(). This way, I can have a bit more control when certain functions are run in relation to others. I'm not convinced that this is any more efficient, but it does provide a flexable system I could move to threads or processes if I want.

I know this is not rocket science, and there are probably many implementations of it out there, but I started thinking...

The task objects have only a few virtul API entry points, these could easily be wrapped in a UNIX shared library or Windows DLL. Outside a few control API functions, there are three operational funtions:

Boolean Init() Boolean Handler(int usec) Boolean Shutdown()

Init is called to initialze the object "in system" but outside timing loop. By returning FALSE, the object can indicate it could not be initialized and should not run.

Handler is called periodically according to system load and priority. The "usec" variable is a precision measurement of elapsed time since its last run. If the funtion return FALSE, it is removed from the task list and its Shutdown function is called.

Shutdown is called when the object is not longer being used and no longer scheduled. If the object is shutdown successfully, the function should return TRUE, otherwise FALSE. Currently the return value is ignored.

My thought is that functionality is added to the robot via this API and end users (developer/users) simply make a shared library (or DLL or COM object for Windos) that provides these entry points.

What do you think?

Reply to
mlw
Loading thread data ...

I have been giving this a lot of thought. There are a number of real-time packages available and a number of real-time vendors. The problem is that a "real-time" system is not quite main stream. If I want to support Macintosh, Windows, BSD, and of course, my first target Linux, I must be able to run on these systems "as likely deployed." A "real time" requirement is not acceptable.

I have also written a lot on this group about not needing "real-time" systems for most of the sort of things that people insist require them. I have done at least a few projects for Windos that are engineered to work around "reasonable" latencies and its bad behaviors.

My ojective is to create a workable software base that works on Linux at first, followed (maybe) by Windows and more. Without the need for real-time extesions.

Without getting off too far on a tangent, most systems do not need realtime control. They need precision time measurement and a fairly high probability of being within a time span more then precise process scheduling. Most of the time, depending on load, you can rely on a PC to call you frequently enough to manage your algorithm. There are, absolutely, cases where a RTOS is a requirement, but a lot of the time it isn't required.

Reply to
mlw

I've asked this before and got no response, so I'll ask again: is there some reason why you are not using one of the real-time Linux extensions?

-Wayne

mlw wrote:

Reply to
Wayne C. Gramlich

Fair enough. It makes your life much more difficult, but it does expand the potential user base by a lot.

You might consider using Linux with one of the RT extensions just to get started, and then see if you can wean yourself from the RT extensions. An advantage of this approach is that you can truthfully say `I used an RTOS and a non-RTOS, and the robot behavior is equivalent.' That is a powerful statement to be able to make. It also might get your robot up and running a little faster.

I have no real argument with you here. I might quibble a little and say "many systems do not need realtime control" tho'. The problem of controlling robot speed and direction via differential steering is clear soluble via an RTOS, clever algorithms, or dedicated microcontrollers -- it is a matter of what trade-offs the engineer in charge chooses to make. You are choosing clever algorithms which is fine by me (not that my opinion really matters.)

[snip]

Alas, I'm going off-line in a couple of hours for a couple of weeks (vacation) and won't be able to see how this thread plays out.

My $.02,

-Wayne

Reply to
Wayne C. Gramlich

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.