"Resource allocation" is one of the responsibilities of the control system
that I cannot place unambiguously into the component-based design
approach... There are various kinds of "resources" that have to be
"allocated" (possibly in a "shared" way), and monitored and recovered: the
computing and communication resources, the sensors and actuators in the
robot system, some data structures in the operation system and the
application, etc.
Most of our own use cases have trivial resource allocation problems, in the
sense that it is clear what resources each component needs, and how it gets
them at deployment. But there are lots of challenging use cases where
resource allocation is not so clear:
- a camera used for both goal tracking and collision avoidance at the same
time;
- the RAM that runs out of availability at some moment during the system's
life time;
- the door handle during a door opening task;
- the grasped object during a "shared control" task with a human;
- etc.
Does someone have a clear idea how to tackle these issues?
And how to change RTT such that it can be used for this purpose?
Or don't we need anything more than we have already: the application's
deployer takes care of the static allocations, while its "supervisor"
component "Coordinates" the components in their access to the resources. In
the simplest case (I think), the latter boils down to givin full access and
responsibility of each resource to one single component, and letting that
component provide "access services" to all other components that need such
access.
Herman
What about "resource allocation" in RTT 2.0...?
> Most of our own use cases have trivial resource allocation problems, in the
> sense that it is clear what resources each component needs, and how it gets
> them at deployment. But there are lots of challenging use cases where
> resource allocation is not so clear:
> - a camera used for both goal tracking and collision avoidance at the same
> time;
> - the RAM that runs out of availability at some moment during the system's
> life time;
> - the door handle during a door opening task;
> - the grasped object during a "shared control" task with a human;
> - etc.
Well ... Most of you already know my answer to this kind of problems: planning
and supervision,
Systems like Roby for instance are designed to handle issues like having the
effects of some components (camera image production in one of your examples)
shared between various other components.
In Roby, the canonical example is the Unix processes themselves. Usually,
there are more than one task in one process. Therefore, if the process
crashes, then the effect of that crash is on multiple concurrently running
processes.
So my personal use-case is: left these concerns out of the functional layer,
and leave those issues to a different part, simply because solving them demands
a system point of view. Even more so in the case of multi-robot of robot-human
task execution, where the successful execution of these tasks requires
(As for the RAM, it is a difficult one because the decision has to be made by a
process that can still run even though there is no ram left ...)
What about "resource allocation" in RTT 2.0...?
On Thu, 14 May 2009, Sylvain Joyeux wrote:
>> Most of our own use cases have trivial resource allocation problems, in the
>> sense that it is clear what resources each component needs, and how it gets
>> them at deployment. But there are lots of challenging use cases where
>> resource allocation is not so clear:
>> - a camera used for both goal tracking and collision avoidance at the same
>> time;
>> - the RAM that runs out of availability at some moment during the system's
>> life time;
>> - the door handle during a door opening task;
>> - the grasped object during a "shared control" task with a human;
>> - etc.
>
> Well ... Most of you already know my answer to this kind of problems: planning
> and supervision,
>
This is the _conceptual_ answer :-) (I could have answered my question by
my favourite term, Coordination :-)
The question is not about concepts, but about what _programming primitives_
RTT should offer to support resource allocation. It might turn out that
"supervision"/"Coordination" is indeed the only generic answer, so be it;
than we put all responsibilities in the hands of the application
developer's skills to come up with manually coded coordinaton schemes for
all components in the system.
In the context of "Model-Driven Engineering", I think that this is not a
sufficiently good answer :-( The system will have to be put togethere
(including supervision/Coordination) without human oversight, purely on the
"platform" models of the available resources...
> Systems like Roby for instance are designed to handle issues like having the
> effects of some components (camera image production in one of your examples)
> shared between various other components.
What is the design behind this "Roby" things that makes it suitable to
"handle" resource allocation?
>
> In Roby, the canonical example is the Unix processes themselves. Usually,
> there are more than one task in one process. Therefore, if the process
> crashes, then the effect of that crash is on multiple concurrently running
> processes.
>
> So my personal use-case is: left these concerns out of the functional layer,
> and leave those issues to a different part, simply because solving them demands
> a system point of view. Even more so in the case of multi-robot of robot-human
> task execution, where the successful execution of these tasks requires
>
> (As for the RAM, it is a difficult one because the decision has to be made by a
> process that can still run even though there is no ram left ...)
>
Herman
What about "resource allocation" in RTT 2.0...?
> The question is not about concepts, but about what _programming primitives_
> RTT should offer to support resource allocation. It might turn out that
> "supervision"/"Coordination" is indeed the only generic answer, so be it;
> than we put all responsibilities in the hands of the application
> developer's skills to come up with manually coded coordinaton schemes for
> all components in the system.
What ? Of course not ! The coordination (as you like to call it) *do* *not*
*have* to be manually coded. Supervision systems offer models and execution
layers that handle most of the gory details.
> > Systems like Roby for instance are designed to handle issues like having
> > the effects of some components (camera image production in one of your
> > examples) shared between various other components.
>
> What is the design behind this "Roby" things that makes it suitable to
> "handle" resource allocation?
Depends on what kind of "ressource allocation" you talk about.
In your example, the problem is not ressource allocation, it is ressource
sharing. Roby in itself allows to represent ressource sharing by building
dependency relationships between the processes of your system. Easily, models
representing and enforcing that "this ressource cannot be shared by more than
X tasks" can be added on top of it (I prototyped it quickly at the end of my
thesis). Same idea with non-discrete ressources.
That's for supervision (which is in my opinion broader than "coordination"
because it deals with checking that the execution goes well). For running the
system so that it does not runs into a problem, you need planning
Fundamentally, planning deals with allocating ressources among tasks, making
sure no two tasks are sharing a ressource that should be exclusive (or not
shared by more than X). Modern planning approaches go as far as allocating
non-discrete ressources (like for instance energy on an energy-scarce
environment like space).
What they don't give you is the runtime check, for that you need an execution
layer like the ones I already cited.
So, my answer would be: it's time to read some litterature ! For a good
starting point, go to the ones I already sent to the list and to the
bibliography of my thesis.
What about "resource allocation" in RTT 2.0...?
On Thu, 14 May 2009, Sylvain Joyeux wrote:
>> The question is not about concepts, but about what _programming primitives_
>> RTT should offer to support resource allocation. It might turn out that
>> "supervision"/"Coordination" is indeed the only generic answer, so be it;
>> than we put all responsibilities in the hands of the application
>> developer's skills to come up with manually coded coordinaton schemes for
>> all components in the system.
> What ? Of course not ! The coordination (as you like to call it) *do* *not*
> *have* to be manually coded. Supervision systems offer models and execution
> layers that handle most of the gory details.
What "supervision systems" are you thinking of?
>>> Systems like Roby for instance are designed to handle issues like having
>>> the effects of some components (camera image production in one of your
>>> examples) shared between various other components.
>>
>> What is the design behind this "Roby" things that makes it suitable to
>> "handle" resource allocation?
> Depends on what kind of "ressource allocation" you talk about.
>
> In your example, the problem is not ressource allocation, it is ressource
> sharing.
The allocation of the share _is_ "resource allocation"! That's exactly why
it is hard, I conjecture...
> Roby in itself allows to represent ressource sharing by building
> dependency relationships between the processes of your system. Easily, models
> representing and enforcing that "this ressource cannot be shared by more than
> X tasks" can be added on top of it (I prototyped it quickly at the end of my
> thesis). Same idea with non-discrete ressources.
Where can I find information about Roby?
> That's for supervision (which is in my opinion broader than "coordination"
> because it deals with checking that the execution goes well). For running the
> system so that it does not runs into a problem, you need planning
Both "execution monitoring" and "planning" are part of what I call
Coordination :-) (That is, the "Computation" aspects of "Coordination".)
> Fundamentally, planning deals with allocating ressources among tasks, making
> sure no two tasks are sharing a ressource that should be exclusive (or not
> shared by more than X). Modern planning approaches go as far as allocating
> non-discrete ressources (like for instance energy on an energy-scarce
> environment like space).
>
> What they don't give you is the runtime check, for that you need an execution
> layer like the ones I already cited.
>
> So, my answer would be: it's time to read some litterature ! For a good
> starting point, go to the ones I already sent to the list and to the
> bibliography of my thesis.
>
It would be nice to repeat those... :-)
Herman
What about "resource allocation" in RTT 2.0...?
About Roby, there's also an IJRR paper but I can't make it public yet (I will
have the right to in August I believe). I can send it offline to people that
would want to read it.
What about "resource allocation" in RTT 2.0...?
> Where can I find information about Roby?
http://doudou.github.com/roby/introduction/publications.html
> It would be nice to repeat those... :-)
Right now, I don't have time either to search the archive.