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 www.linuxpcrobot.org 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?

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

>> 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 www.linuxpcrobot.org
>> 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?

> Wayne C. Gramlich wrote:
>
>

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

>
>
> 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 o[b]jective 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.