Use case for switching controller

Hello,

I'm currently working on a robot simulator. The robot, let's say the "Plant", can be controlled by a speed controller or by a position controller. Like it's done in the rtt-exercices, I would like to switch the controller at runtine. Currently, I have one periodic activity for each component (Plant, SpeedController and PositionController). They both run at the same frequence, and the Plant input/output are permanently connected to both controller.


When I start the application, I do the following :

SpeedController.start()
Plant.start()

since I want the SpeedController to be executed before the Plant. When it's time to switch to PositionController, I run a script that does the following commands :


SpeedController.stop()
PositionController.start()

However, since the Plant has never been started, I guess the execution order would become : Plant first, PositionController second. I could have stopped the Plant before starting the PositionController. However, in the case of a "real" plant, I may not have the possibility to stop the plant task.


The only option that I see is using the SlaveActivity. I could have a main component which explicitly execute the slave activities. Since I'm using the deployer, the components don't really know each other so this option is almost impossible. What I would like to do is to fix the order of execution when deploying the component. In other words, the order of execution would be independent of start/stop sequences. Is there a way to do that?


Thank you,

Philippe Hamelin

Use case for switching controller

On Thu, 11 Dec 2008, Philippe Hamelin wrote:

> I'm currently working on a robot simulator. The robot, let's say the
> "Plant", can be controlled by a speed controller or by a position
> controller. Like it's done in the rtt-exercices, I would like to switch the
> controller at runtine. Currently, I have one periodic activity for each
> component (Plant, SpeedController and PositionController). They both run at
> the same frequence, and the Plant input/output are permanently connected to
> both controller.
>
> When I start the application, I do the following :
>
> SpeedController.start()
> Plant.start()
>
> since I want the SpeedController to be executed before the Plant. When it's
> time to switch to PositionController, I run a script that does the following
> commands :
>
> SpeedController.stop()
> PositionController.start()

Oops... I don't like this approach _at all_!!! Using different activities
(threads) for different controllers is a very unfortunate thing to do, and
opens up more than one single can of worms :-)
Instead, you should use a _state machine_ (within one single activity) that
can switch between the _algorithms_ that implement your Plant,
SpeedController and PositionController.

Avoiding this "thread fiddling" development is _exactly_ the reason why I
started the Orocos projects 8 years ago ... :-)

> However, since the Plant has never been started, I guess the execution order
> would become : Plant first, PositionController second. I could have stopped
> the Plant before starting the PositionController. However, in the case of a
> "real" plant, I may not have the possibility to stop the plant task.

This kind of "scheduling" of threads to "guarantee" some causal path of
execution is not a good idea! If you need sequence garantees, please
program them explicitly in your state machine, and don't rely on any kind
of "application agnostic" scheduler.

Herman

> The only option that I see is using the SlaveActivity. I could have a main
> component which explicitly execute the slave activities. Since I'm using the
> deployer, the components don't really know each other so this option is
> almost impossible. What I would like to do is to fix the order of execution
> when deploying the component. In other words, the order of execution would
> be independent of start/stop sequences. Is there a way to do that?
>
> Thank you,
>
> Philippe Hamelin
>
>
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
Tel: +32 16 322480
Coordinator of EURON (European Robotics Research Network)

Open Realtime Control Services

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Use case for switching controller

On Dec 12, 2008, at 07:43 , Herman Bruyninckx wrote:

> On Thu, 11 Dec 2008, Philippe Hamelin wrote:
>
>> I'm currently working on a robot simulator. The robot, let's say the
>> "Plant", can be controlled by a speed controller or by a position
>> controller. Like it's done in the rtt-exercices, I would like to
>> switch the
>> controller at runtine. Currently, I have one periodic activity for
>> each
>> component (Plant, SpeedController and PositionController). They
>> both run at
>> the same frequence, and the Plant input/output are permanently
>> connected to
>> both controller.
>> When I start the application, I do the following :
>> SpeedController.start()
>> Plant.start()
>> since I want the SpeedController to be executed before the Plant.
>> When it's
>> time to switch to PositionController, I run a script that does the
>> following
>> commands :
>> SpeedController.stop()
>> PositionController.start()
>
> Oops... I don't like this approach _at all_!!! Using different
> activities
> (threads) for different controllers is a very unfortunate thing to
> do, and
> opens up more than one single can of worms :-)
> Instead, you should use a _state machine_ (within one single
> activity) that
> can switch between the _algorithms_ that implement your Plant,
> SpeedController and PositionController.

Bar trivial examples, I would strongly agree with Herman here. We use
a state-machine within our Plant to control whether it is safe,
holding position, or moving. We then have multiple controller
components, all of which are controlled by a master controller
component who is basically nothing more than a state machine dictating
which controller components are on/off. Then an HMI component sends
events to the two state machines (plant, and master controller) to
make the system do what it is supposed to.

Buried within the RTT and OCL code are examples like this, but it took
quite a jump for us to make a working system from them. One of my
thoughts is to actually extend Peter's examples/tutorials to include a
complete example like this, rather than have to burrow through
partially-working code to learn this.

HTH
S

Use case for switching controller

2008/12/12 S Roderick <kiwi.net@mac.com>

On Dec 12, 2008, at 07:43 , Herman Bruyninckx wrote:


On Thu, 11 Dec 2008, Philippe Hamelin wrote:


I'm currently working on a robot simulator. The robot, let's say the

"Plant", can be controlled by a speed controller or by a position

controller. Like it's done in the rtt-exercices, I would like to switch the

controller at runtine. Currently, I have one periodic activity for each

component (Plant, SpeedController and PositionController). They both run at

the same frequence, and the Plant input/output are permanently connected to

both controller.

When I start the application, I do the following :

SpeedController.start()

Plant.start()

since I want the SpeedController to be executed before the Plant. When it's

time to switch to PositionController, I run a script that does the following

commands :

SpeedController.stop()

PositionController.start()



Oops... I don't like this approach _at all_!!! Using different activities

(threads) for different controllers is a very unfortunate thing to do, and

opens up more than one single can of worms :-)

Instead, you should use a _state machine_ (within one single activity) that

can switch between the _algorithms_ that implement your Plant,

SpeedController and PositionController.


Bar trivial examples, I would strongly agree with Herman here. We use a state-machine within our Plant to control whether it is safe, holding position, or moving. We then have multiple controller components, all of which are controlled by a master controller component who is basically nothing more than a state machine dictating which controller components are on/off. Then an HMI component sends events to the two state machines (plant, and master controller) to make the system do what it is supposed to. 



Buried within the RTT and OCL code are examples like this, but it took quite a jump for us to make a working system from them. One of my thoughts is to actually extend Peter's examples/tutorials to include a complete example like this, rather than have to burrow through partially-working code to learn this.



HTH

S


Ok, I will try to write out the use case to clarify some points to me.



Let's say we have a single Plant component, multiple Controller
components and a MasterController component. The Plant component and
the MasterController components have there own PeriodicActivity, while
each Controller components have a SlaveActivity.



A state machine is running inside the MasterController, which manages the execution of the Controller components. In other words, the state machine decides which SlaveActivity to execute at each step. By using a state machine, it's also possible to manage "transition" between control strategies.


However, tell me if i'm wrong, but I could also use a script instead of a state machine. It could be something like :

    while(1)
    {
        try SpeedController.execute();
        try PositionController.execute();

    }

In addition to this script, I  may need an other script to start/stop the Controllers. Like Peter said, if the controller is not started, the SlaveActivity will not be executed. However, with this script I can't manage the transitions between control strategies. I agree that a state machine if very versatile, but for a first design iteration it may work, am I wrong?


Thank you for your help!
Philippe Hamelin

Use case for switching controller

On Dec 12, 2008, at 11:10 , Philippe Hamelin wrote:


2008/12/12 S Roderick <kiwi.net@mac.com>

On Dec 12, 2008, at 07:43 , Herman Bruyninckx wrote:

On Thu, 11 Dec 2008, Philippe Hamelin wrote:

I'm currently working on a robot simulator. The robot, let's say the
"Plant", can be controlled by a speed controller or by a position
controller. Like it's done in the rtt-exercices, I would like to switch the
controller at runtine. Currently, I have one periodic activity for each
component (Plant, SpeedController and PositionController). They both run at
the same frequence, and the Plant input/output are permanently connected to
both controller.
When I start the application, I do the following :
SpeedController.start()
Plant.start()
since I want the SpeedController to be executed before the Plant. When it's
time to switch to PositionController, I run a script that does the following
commands :
SpeedController.stop()
PositionController.start()


Oops... I don't like this approach _at all_!!! Using different activities
(threads) for different controllers is a very unfortunate thing to do, and
opens up more than one single can of worms :-)
Instead, you should use a _state machine_ (within one single activity) that
can switch between the _algorithms_ that implement your Plant,
SpeedController and PositionController.


Bar trivial examples, I would strongly agree with Herman here. We use a state-machine within our Plant to control whether it is safe, holding position, or moving. We then have multiple controller components, all of which are controlled by a master controller component who is basically nothing more than a state machine dictating which controller components are on/off. Then an HMI component sends events to the two state machines (plant, and master controller) to make the system do what it is supposed to. 


Buried within the RTT and OCL code are examples like this, but it took quite a jump for us to make a working system from them. One of my thoughts is to actually extend Peter's examples/tutorials to include a complete example like this, rather than have to burrow through partially-working code to learn this.

HTH
S


Ok, I will try to write out the use case to clarify some points to me.

Let's say we have a single Plant component, multiple Controller components and a MasterController component. The Plant component and the MasterController components have there own PeriodicActivity, while each Controller components have a SlaveActivity.

A state machine is running inside the MasterController, which manages the execution of the Controller components. In other words, the state machine decides which SlaveActivity to execute at each step. By using a state machine, it's also possible to manage "transition" between control strategies.

However, tell me if i'm wrong, but I could also use a script instead of a state machine. It could be something like :

    while(1)
    {
        try SpeedController.execute();
        try PositionController.execute();
    }

In addition to this script, I  may need an other script to start/stop the Controllers. Like Peter said, if the controller is not started, the SlaveActivity will not be executed. However, with this script I can't manage the transitions between control strategies. I agree that a state machine if very versatile, but for a first design iteration it may work, am I wrong?


We use the deployer and no SlaveActivities. Everything is periodic, however, our Master Controller starts/stops components on the fly as necessary. The only caveat here is that it can be complicated dealing with errors occuring when starting components, due to some limitations in the current state machine implementation for entry functions. Peter and I fought with that a few months ago and it works for us now, but just be aware.

HTH
S

Use case for switching controller

On Thursday 11 December 2008 15:25:27 Philippe Hamelin wrote:
> Hello,
>
> I'm currently working on a robot simulator. The robot, let's say the
> "Plant", can be controlled by a speed controller or by a position
> controller. Like it's done in the rtt-exercices, I would like to switch the
> controller at runtine. Currently, I have one periodic activity for each
> component (Plant, SpeedController and PositionController). They both run at
> the same frequence, and the Plant input/output are permanently connected to
> both controller.
>
> When I start the application, I do the following :
>
> SpeedController.start()
> Plant.start()
>
> since I want the SpeedController to be executed before the Plant. When it's
> time to switch to PositionController, I run a script that does the
> following commands :
>
> SpeedController.stop()
> PositionController.start()
>
> However, since the Plant has never been started, I guess the execution
> order would become : Plant first, PositionController second. I could have

Correct.

> stopped the Plant before starting the PositionController. However, in the
> case of a "real" plant, I may not have the possibility to stop the plant
> task.

If you depend on ordering, SlaveActivity is the best choice.

>
> The only option that I see is using the SlaveActivity. I could have a main
> component which explicitly execute the slave activities. Since I'm using
> the deployer, the components don't really know each other so this option is
> almost impossible.

It isn't. You just need to appoint one component as master (which gets a
normal periodic activity), and make the other components peers of that
component (this is all done in XML, big note below (*!) ). The final thing you
need to do is
1. C++ : lookup the peers with
getPeer("the_slave")->engine()->getActivity()-execute()
(You'll be allowed to drop the engine() in RTT 1.8)
OR
2. Scripting:
try the_slave.execute(); // use 'do' or 'try'

So a dumb master could 'try' to execute all its slaves in the desired order.
Only the ones started will actually execute.

> What I would like to do is to fix the order of execution

So do this in a program script or in C++.

Peter

(*!) Due to a 'bug', you're unable to specify a master using XML in the OCL
1.6 library. This has as effect that you need to specify the period manually in
the XML file and can not 'inherit' it from a master task. Also, you're then
allowed to start the slave even if the master is not running. This will be
fixed in OCL 1.8.