Hello,
We have an application with several realtime and non-realtime
taskcontexts. Each TC has several properties and attributes. These may
be scalars, 1d vectors or 2d vectors.
I'd like to provide an easy, graphical way to access and change the
property/attribute variables. This would enable calibration of
parameters "in the field" (in our case, a moving truck).
One solution I can think of is to create a separate GUI program that
connects to some TC that implements a TCP/IP server (which perhaps
inherits from the TaskBrowser). The GUI should then be able to detect
all the running TCs and also detect all the properties/attributes of
each TC. It can then present each property/attribute to the user in an
appropriate way. ( For example, if the property is a 2d vector, it is
shown as a table. ) The user should then be able to change the value(s)
and they should be propagated back to the appropriate TC.
Question: Is this a reasonable approach, or is there a better way? How
would you detect all taskcontexts and get full knowledge of their
attributes/properties?
Regards,
Sagar
runtime calibration of attributes/properties via a GUI
I have one single question: are you using typegen to wrap your types ?
If it is not the case, then you should ;-)
If it is the case, I'm working at making sure that Rock's tooling works
fine with "plain" orocos components (orocos components that use typegen
but not orogen). I would strongly suggest that you have a look at Rock's
tooling in this context:
http://rock-robotics.org/documentation/tutorials/200_display_logging_and...
http://rock-robotics.org/documentation/gui.html
The task inspector presented in the first link also allows (on top of
displaying the data) to change the properties.
You *do* have to remember, though, that changing properties is not
thread-safe. It's best to have a stop/cleanup/configure/start cycle when
doing so. Something we could/should integrate in the task inspector
@Alex: how is it done currently ?
runtime calibration of attributes/properties via a GUI
On Fri, 2012-03-09 at 09:53 +0100, Sylvain Joyeux wrote:
> I have one single question: are you using typegen to wrap your types ?
>
> If it is not the case, then you should ;-)
>
> If it is the case, I'm working at making sure that Rock's tooling works
> fine with "plain" orocos components (orocos components that use typegen
> but not orogen). I would strongly suggest that you have a look at Rock's
> tooling in this context:
>
>
> http://rock-robotics.org/documentation/tutorials/200_display_logging_and...
> http://rock-robotics.org/documentation/gui.html
>
> The task inspector presented in the first link also allows (on top of
> displaying the data) to change the properties.
>
> You *do* have to remember, though, that changing properties is not
> thread-safe. It's best to have a stop/cleanup/configure/start cycle when
> doing so. Something we could/should integrate in the task inspector
>
> @Alex: how is it done currently ?
At them moment the attributes are set without checking if the task is
running or not. But we should add a message-box for cases where a task
is running to ask the user if the stop/cleanup/configure/start cycle
shall be triggered.
Alex
runtime calibration of attributes/properties via a GUI
On 03/09/2012 09:53 AM, Sylvain Joyeux wrote:
> I have one single question: are you using typegen to wrap your types ?
> If it is not the case, then you should ;-)
The system isn't implemented yet, but I guess typegen will _have_ to be
used in order to make the datatypes not-opaque. (From what I've seen
during previous orocos fiddling, unless the data-types are standard int,
string, float etc., they will show up as unknown_t, unless typegen is used.)
> If it is the case, I'm working at making sure that Rock's tooling works
> fine with "plain" orocos components (orocos components that use typegen
> but not orogen). I would strongly suggest that you have a look at Rock's
> tooling in this context:
This looks interesting. Perhaps we can think of using Rock instead. Is
Rock LGPL or with a runtime exception like Orocos?
> You *do* have to remember, though, that changing properties is not
> thread-safe. It's best to have a stop/cleanup/configure/start cycle when
> doing so.
Hmm.. If the task needs to be stopped every time a property is changed,
then properties don't seem to be a good way to implement calibration
data. For example, if we are in a moving truck and calibrating a
speed-vs-braking_torque curve, it won't be nice (or even safe) to stop
the controller every time a value needs to be changed.
Tools like dSpace, Mathworks xPC target or even labview permit
on-the-fly changing of values. Is there no way to do this with Orocos/Rock?
/Sagar
runtime calibration of attributes/properties via a GUI
On 03/09/2012 10:37 AM, Sagar Behere wrote:
>> If it is the case, I'm working at making sure that Rock's tooling works
>> fine with "plain" orocos components (orocos components that use typegen
>> but not orogen). I would strongly suggest that you have a look at Rock's
>> tooling in this context:
>
> This looks interesting. Perhaps we can think of using Rock instead. Is
> Rock LGPL or with a runtime exception like Orocos?
Rock is LGPL, but the LGPL does not cover the code generated by typegen
/ orogen (the license explicitely states that the generated code is YOUR
code). As always, there's always a difference between the letter of the
license and the intent we had, and I'm not a lawyer. What's the "runtime
exception" you are talking about ? Do you have a problem with LGPL in
general ?
>> You *do* have to remember, though, that changing properties is not
>> thread-safe. It's best to have a stop/cleanup/configure/start cycle when
>> doing so.
>
> Hmm.. If the task needs to be stopped every time a property is changed,
> then properties don't seem to be a good way to implement calibration
> data. For example, if we are in a moving truck and calibrating a
> speed-vs-braking_torque curve, it won't be nice (or even safe) to stop
> the controller every time a value needs to be changed.
Well, it depends on your time frame. I'll have to work very VERY soon on
a system to safely update properties at runtime. It will involve calling
operations, so you should definitely design your component configuration
with few of these properties, as e.g. using confguration structures and
single properties using these structures. The added cherry being that
you get a method call when the property changes, which acts as a natural
(1) validation and (2) notification mechanism.
runtime calibration of attributes/properties via a GUI
On 03/09/2012 10:45 AM, Sylvain Joyeux wrote:
> On 03/09/2012 10:37 AM, Sagar Behere wrote:
>>> If it is the case, I'm working at making sure that Rock's tooling works
>>> fine with "plain" orocos components (orocos components that use typegen
>>> but not orogen). I would strongly suggest that you have a look at Rock's
>>> tooling in this context:
>>
>> This looks interesting. Perhaps we can think of using Rock instead. Is
>> Rock LGPL or with a runtime exception like Orocos?
> Rock is LGPL, but the LGPL does not cover the code generated by typegen
> / orogen (the license explicitely states that the generated code is YOUR
> code). As always, there's always a difference between the letter of the
> license and the intent we had, and I'm not a lawyer. What's the "runtime
> exception" you are talking about ?
Orocos is distributed under a GPL + runtime exception
http://orocos.org/orocos/license
From that link: "The 'runtime exception' says explicitly that using the
C++ templates (or any other function) of the RTT software does not make
your derived work GPL. The derived work may be distributed under any
license you see fit." There's something about LGPL not being compatible
with C++ templates in general.
> Do you have a problem with LGPL in general ?
No problems with LGPL. We are a university, but we work with the Swedish
automotive industry and their lawyers become quite uncomfortable if we
say, ".. and oh-by-the-way, we'd need to make all the code for feature X
available to the general public." I think that is the case with GPL.
>>> You *do* have to remember, though, that changing properties is not
>>> thread-safe. It's best to have a stop/cleanup/configure/start cycle when
>>> doing so.
>>
>> Hmm.. If the task needs to be stopped every time a property is changed,
>> then properties don't seem to be a good way to implement calibration
>> data. For example, if we are in a moving truck and calibrating a
>> speed-vs-braking_torque curve, it won't be nice (or even safe) to stop
>> the controller every time a value needs to be changed.
> Well, it depends on your time frame. I'll have to work very VERY soon on
> a system to safely update properties at runtime. It will involve calling
> operations, so you should definitely design your component configuration
> with few of these properties, as e.g. using confguration structures and
> single properties using these structures. The added cherry being that
> you get a method call when the property changes, which acts as a natural
> (1) validation and (2) notification mechanism.
Sounds good. Would it be reasonable to assume that you'll announce the
implementation of this feature on this mailing list?
Thanks,
Sagar
runtime calibration of attributes/properties via a GUI
On Fri, Mar 9, 2012 at 10:37 AM, Sagar Behere <sagar [dot] behere [..] ...> wrote:
> On 03/09/2012 09:53 AM, Sylvain Joyeux wrote:
>> I have one single question: are you using typegen to wrap your types ?
>> If it is not the case, then you should ;-)
>
> The system isn't implemented yet, but I guess typegen will _have_ to be
> used in order to make the datatypes not-opaque. (From what I've seen
> during previous orocos fiddling, unless the data-types are standard int,
> string, float etc., they will show up as unknown_t, unless typegen is used.)
>
>> If it is the case, I'm working at making sure that Rock's tooling works
>> fine with "plain" orocos components (orocos components that use typegen
>> but not orogen). I would strongly suggest that you have a look at Rock's
>> tooling in this context:
>
> This looks interesting. Perhaps we can think of using Rock instead. Is
> Rock LGPL or with a runtime exception like Orocos?
>
>> You *do* have to remember, though, that changing properties is not
>> thread-safe. It's best to have a stop/cleanup/configure/start cycle when
>> doing so.
>
> Hmm.. If the task needs to be stopped every time a property is changed,
> then properties don't seem to be a good way to implement calibration
> data. For example, if we are in a moving truck and calibrating a
> speed-vs-braking_torque curve, it won't be nice (or even safe) to stop
> the controller every time a value needs to be changed.
>
> Tools like dSpace, Mathworks xPC target or even labview permit
> on-the-fly changing of values. Is there no way to do this with Orocos/Rock?
If on-the-fly thread-safe changes are needed, the use of DataPorts
instead of Properties is recommended.
> /Sagar
Ruben
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
runtime calibration of attributes/properties via a GUI
On 03/09/2012 10:41 AM, Ruben Smits wrote:
>> Tools like dSpace, Mathworks xPC target or even labview permit
>> on-the-fly changing of values. Is there no way to do this with Orocos/Rock?
>
> If on-the-fly thread-safe changes are needed, the use of DataPorts
> instead of Properties is recommended.
I personally don't recommend that.
If it is configuration parameters (i.e. mostly static but needs to be
changed every once in a while), then use properties. If it is a dynamic
value (i.e. sensor reading, commands, ...) then use ports.
Ports are tricky to use for configuration since they are intrinsically
asynchronous.
runtime calibration of attributes/properties via a GUI
On Fri, 9 Mar 2012, Sylvain Joyeux wrote:
> On 03/09/2012 10:41 AM, Ruben Smits wrote:
>>> Tools like dSpace, Mathworks xPC target or even labview permit
>>> on-the-fly changing of values. Is there no way to do this with Orocos/Rock?
>>
>> If on-the-fly thread-safe changes are needed, the use of DataPorts
>> instead of Properties is recommended.
> I personally don't recommend that.
>
> If it is configuration parameters (i.e. mostly static but needs to be
> changed every once in a while), then use properties. If it is a dynamic
> value (i.e. sensor reading, commands, ...) then use ports.
>
> Ports are tricky to use for configuration since they are intrinsically
> asynchronous.
Indeed. And that's why we want to clearly put these two complementary but
distinct use cases of "changing values at runtime" into two different "C"s
in the BRICS Component Model:
- Configuration (of property values) _must_ be done in a state in which the
configured component can be accessed in atomic way. "Atomic" even means
more than "synchronous": the configuration can consists of many
synchronous calls that all have to be done 'at the same time', or not at
all.
- Adaptation (of behaviour-changing values) _must_ be a provided
functionality of a Computational component that implements this
functionality, and in that case it is to be done via a Port.
> Sylvain Joyeux (Dr.Ing.)
Herman
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
runtime calibration of attributes/properties via a GUI
On 03/09/2012 10:41 AM, Ruben Smits wrote:
> On Fri, Mar 9, 2012 at 10:37 AM, Sagar Behere<sagar [dot] behere [..] ...> wrote:
>> On 03/09/2012 09:53 AM, Sylvain Joyeux wrote:
>>> I have one single question: are you using typegen to wrap your types ?
>>> If it is not the case, then you should ;-)
>>
>> The system isn't implemented yet, but I guess typegen will _have_ to be
>> used in order to make the datatypes not-opaque. (From what I've seen
>> during previous orocos fiddling, unless the data-types are standard int,
>> string, float etc., they will show up as unknown_t, unless typegen is used.)
>>
>>> If it is the case, I'm working at making sure that Rock's tooling works
>>> fine with "plain" orocos components (orocos components that use typegen
>>> but not orogen). I would strongly suggest that you have a look at Rock's
>>> tooling in this context:
>>
>> This looks interesting. Perhaps we can think of using Rock instead. Is
>> Rock LGPL or with a runtime exception like Orocos?
>>
>>> You *do* have to remember, though, that changing properties is not
>>> thread-safe. It's best to have a stop/cleanup/configure/start cycle when
>>> doing so.
>>
>> Hmm.. If the task needs to be stopped every time a property is changed,
>> then properties don't seem to be a good way to implement calibration
>> data. For example, if we are in a moving truck and calibrating a
>> speed-vs-braking_torque curve, it won't be nice (or even safe) to stop
>> the controller every time a value needs to be changed.
>>
>> Tools like dSpace, Mathworks xPC target or even labview permit
>> on-the-fly changing of values. Is there no way to do this with Orocos/Rock?
>
> If on-the-fly thread-safe changes are needed, the use of DataPorts
> instead of Properties is recommended.
Could you say how DataPorts could be used for this? As I see it, if you
have two TCs A and B, then you could use a DataPort to connect them and
exchange data. But if I want to change the values in a vector in TC B,
how would a DataPort help? Are you suggesting that all variables that
need to be calibrated should be supplied to the TC from another TC? And
if so, how should they be changed in a thread-safe way at runtime in the
supplier TC?
Thanks in advance.
/Sagar
runtime calibration of attributes/properties via a GUI
2012/3/9 Sagar Behere <sagar [dot] behere [..] ...>:
> On 03/09/2012 10:41 AM, Ruben Smits wrote:
>> On Fri, Mar 9, 2012 at 10:37 AM, Sagar Behere<sagar [dot] behere [..] ...> wrote:
>>> On 03/09/2012 09:53 AM, Sylvain Joyeux wrote:
>>>> I have one single question: are you using typegen to wrap your types ?
>>>> If it is not the case, then you should ;-)
>>>
>>> The system isn't implemented yet, but I guess typegen will _have_ to be
>>> used in order to make the datatypes not-opaque. (From what I've seen
>>> during previous orocos fiddling, unless the data-types are standard int,
>>> string, float etc., they will show up as unknown_t, unless typegen is used.)
>>>
>>>> If it is the case, I'm working at making sure that Rock's tooling works
>>>> fine with "plain" orocos components (orocos components that use typegen
>>>> but not orogen). I would strongly suggest that you have a look at Rock's
>>>> tooling in this context:
>>>
>>> This looks interesting. Perhaps we can think of using Rock instead. Is
>>> Rock LGPL or with a runtime exception like Orocos?
>>>
>>>> You *do* have to remember, though, that changing properties is not
>>>> thread-safe. It's best to have a stop/cleanup/configure/start cycle when
>>>> doing so.
>>>
>>> Hmm.. If the task needs to be stopped every time a property is changed,
>>> then properties don't seem to be a good way to implement calibration
>>> data. For example, if we are in a moving truck and calibrating a
>>> speed-vs-braking_torque curve, it won't be nice (or even safe) to stop
>>> the controller every time a value needs to be changed.
>>>
>>> Tools like dSpace, Mathworks xPC target or even labview permit
>>> on-the-fly changing of values. Is there no way to do this with Orocos/Rock?
>>
>> If on-the-fly thread-safe changes are needed, the use of DataPorts
>> instead of Properties is recommended.
>
> Could you say how DataPorts could be used for this? As I see it, if you
> have two TCs A and B, then you could use a DataPort to connect them and
> exchange data. But if I want to change the values in a vector in TC B,
> how would a DataPort help? Are you suggesting that all variables that
> need to be calibrated should be supplied to the TC from another TC? And
> if so, how should they be changed in a thread-safe way at runtime in the
> supplier TC?
>
Yes, you may by choice choose either :
_ send the entire vector even with unchanged values
_ separate the vector in different simple ports and change only the
interesting value. Then you may reconstruct the vector at the
beginning of your update hook if your internal computation needs it.
> Thanks in advance.
>
> /Sagar
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users