We've got a problem. We are trying to send a single ROS message from a GUI to an Orocos component, but for some reason, the component gets the message twice. And not just one message… basically all of the ROS-connected input ports are receiving multiple copies of messages. We assume there's something broken in our deployment script (which is admittedly complicated) like the port being connected twice…
Is there any way, after things are up and running, to inspect a port or a connection and get a listing of what is connected to what? Something like a rttlib.portstats() but with more info?
--
Dustin Gooding
NASA/JSC Robotics
Phone: 281-483-6453
IM: dgooding [..] ...<xmpp:dgooding [..] ...>
port connection inspection?
On Thu, Dec 13, 2012 at 5:44 PM, Gooding, Dustin R. (JSC-ER411)
<dustin [dot] r [dot] gooding [..] ...> wrote:
> We've got a problem. We are trying to send a single ROS message from a GUI
> to an Orocos component, but for some reason, the component gets the message
> twice. And not just one message… basically all of the ROS-connected input
> ports are receiving multiple copies of messages. We assume there's
> something broken in our deployment script (which is admittedly complicated)
> like the port being connected twice…
>
> Is there any way, after things are up and running, to inspect a port or a
> connection and get a listing of what is connected to what? Something like
> a rttlib.portstats() but with more info?
As Willy said, rtt_dot_service is the answer, but as he said as well,
it's equally 'flat' as component deployment, so it can get big.
There's also an example on how to use the rtt_dot_service in the
youbot exercise:
https://github.com/psoetens/orocos-rtt-examples/tree/rtt-2.0-solution/rt...
( deployment/updater.lua )
Peter
port connection inspection?
2012/12/13 Gooding, Dustin R. (JSC-ER411) <dustin [dot] r [dot] gooding [..] ...>:
> We've got a problem. We are trying to send a single ROS message from a GUI
> to an Orocos component, but for some reason, the component gets the message
> twice. And not just one message… basically all of the ROS-connected input
> ports are receiving multiple copies of messages. We assume there's
> something broken in our deployment script (which is admittedly complicated)
> like the port being connected twice…
>
> Is there any way, after things are up and running, to inspect a port or a
> connection and get a listing of what is connected to what? Something like
> a rttlib.portstats() but with more info?
>
Maybe you could have a look at rtt_dot_service.
It should be available from here :
https://gitorious.org/rtt_dot-service/rtt_dot-service
Here is some link to old threads :
http://www.orocos.org/forum/rtt/rtt-dev/rttdotservice-feedback
http://www.orocos.org/forum/rtt/rtt-dev/bug-819-new-feature-request-grap...
http://www.orocos.org/forum/rtt/rtt-dev/patches-rttdotservice (I don't
know if they were integrated)
But to be honest if you can't manage to see in your complex deployment
script anything, I'm afraid the rtt_dot_service is too "experimental"
(especially about scalability) to help in this case ...
The lack of composition in Orocos is still a pain to handle such
complex deployments.
The deployment is a very important part of the system quality in
complex projects, so if you begin to have problems with your
"admittedly complicated" deployment, I suggest that you kill
complexity in it.
I personnaly did it with working on scalability/standardisation/reusability in:
_ separating your deployment in sub parts that are in a way a
composition of your system (groups of components), or even going to
one component/one script (scalability)
_ having rules like : "components-deployment-scripts are responsible
of connecting their input ports, and only that" (cause you know what
you need, not to what you publish) (standardisation)
_ having some automated connections (this breaks reusabilty thougth)
> --
> Dustin Gooding
> NASA/JSC Robotics
> Phone: 281-483-6453
> IM: dgooding [..] ...
>
>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
port connection inspection?
On 12/13/2012 06:28 PM, Willy Lambert wrote:
> The lack of composition in Orocos is still a pain to handle such
> complex deployments.
*cough* http://rock-robotics.org/master/documentation/system/index.html
*cough*
port connection inspection?
2012/12/14 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 12/13/2012 06:28 PM, Willy Lambert wrote:
>
> The lack of composition in Orocos is still a pain to handle such
> complex deployments.
>
> *cough* http://rock-robotics.org/master/documentation/system/index.html
> *cough*
>
Thanks for pointing. Does this can be ised out of Rock ? on a plain
Orocos install ?
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater 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
> -----------------------------------------------------------------------
port connection inspection?
On 12/14/2012 09:55 AM, Willy Lambert wrote:
> 2012/12/14 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>> On 12/13/2012 06:28 PM, Willy Lambert wrote:
>>
>> The lack of composition in Orocos is still a pain to handle such
>> complex deployments.
>>
>> *cough* http://rock-robotics.org/master/documentation/system/index.html
>> *cough*
>>
> Thanks for pointing. Does this can be ised out of Rock ? on a plain
> Orocos install ?
As I stated in previous email "maybe". There are no major technical
blockers, but there *will* be work involved to make it happen. So that
is a "definitely not out of the box". Now, I personally believe that, if
you do feel a lot of pain with complex system, you will also gain a lot.
YMMV as they say.
The issues:
- orogen task context models. You will need to create one per task you
have written.
- deployment models. The executive currently assumes that all
deployments are oroGen deployments. What would definitely be possible is
to define the deployments in oroGen (along with the task models), but
bypass the execution (i.e. generate the corresponding deployer file to
fit better into the "plain orocos" workflow).
- no defined workflow, and there will not be such a workflow until
somebody using "plain orocos" invests a serious amount of effort to get
it to work.
More to the point, I have *no* plain orocos installs and have *no* plain
orocos workflow. I won't make it happen by myself. I am willing to help
... but cannot do everything.
port connection inspection?
2012/12/14 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 12/14/2012 09:55 AM, Willy Lambert wrote:
>>
>> 2012/12/14 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>>>
>>> On 12/13/2012 06:28 PM, Willy Lambert wrote:
>>>
>>> The lack of composition in Orocos is still a pain to handle such
>>> complex deployments.
>>>
>>> *cough* http://rock-robotics.org/master/documentation/system/index.html
>>> *cough*
>>>
>> Thanks for pointing. Does this can be ised out of Rock ? on a plain
>> Orocos install ?
>
> As I stated in previous email "maybe". There are no major technical
> blockers, but there *will* be work involved to make it happen. So that is a
> "definitely not out of the box".
> Now, I personally believe that, if you do
> feel a lot of pain with complex system, you will also gain a lot. YMMV as
> they say.
>
That was my fear. The problem is that when you are stucked in an
industrial project, to make such an evolution in an existing system,
you have to give technical justifications that your evolution will
give something, with little cost, and little risks...
It's simple to say : "ok, now we will stop to write foolish script
files, we will create a folder structure and have a file per component
and have a input-only-connection rule"
It's difficult to say : "ok, something seems to work from another
framework and we have a risk that we don't know how long it'll take
(and we need new competencies cause new concepts involved)"
Let me know if you can argue something to the one that gives the money
not to choose the first one ...
> The issues:
> - orogen task context models. You will need to create one per task you have
> written.
> - deployment models. The executive currently assumes that all deployments
> are oroGen deployments. What would definitely be possible is to define the
> deployments in oroGen (along with the task models), but bypass the execution
> (i.e. generate the corresponding deployer file to fit better into the "plain
> orocos" workflow).
> - no defined workflow, and there will not be such a workflow until somebody
> using "plain orocos" invests a serious amount of effort to get it to work.
>
> More to the point, I have *no* plain orocos installs and have *no* plain
> orocos workflow. I won't make it happen by myself. I am willing to help ...
> but cannot do everything.
>
of course
>
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater 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
> -----------------------------------------------------------------------
>
port connection inspection?
On Dec 13, 2012, at 11:28 AM, Willy Lambert wrote:
> 2012/12/13 Gooding, Dustin R. (JSC-ER411) <dustin [dot] r [dot] gooding [..] ...>:
>> We've got a problem. We are trying to send a single ROS message from a GUI
>> to an Orocos component, but for some reason, the component gets the message
>> twice. And not just one message… basically all of the ROS-connected input
>> ports are receiving multiple copies of messages. We assume there's
>> something broken in our deployment script (which is admittedly complicated)
>> like the port being connected twice…
>>
>> Is there any way, after things are up and running, to inspect a port or a
>> connection and get a listing of what is connected to what? Something like
>> a rttlib.portstats() but with more info?
>>
>
> Maybe you could have a look at rtt_dot_service.
> It should be available from here :
> https://gitorious.org/rtt_dot-service/rtt_dot-service
>
> Here is some link to old threads :
> http://www.orocos.org/forum/rtt/rtt-dev/rttdotservice-feedback
> http://www.orocos.org/forum/rtt/rtt-dev/bug-819-new-feature-request-grap...
> http://www.orocos.org/forum/rtt/rtt-dev/patches-rttdotservice (I don't
> know if they were integrated)
>
> But to be honest if you can't manage to see in your complex deployment
> script anything, I'm afraid the rtt_dot_service is too "experimental"
> (especially about scalability) to help in this case ...
>
> The lack of composition in Orocos is still a pain to handle such
> complex deployments.
>
>
> The deployment is a very important part of the system quality in
> complex projects, so if you begin to have problems with your
> "admittedly complicated" deployment, I suggest that you kill
> complexity in it.
> I personnaly did it with working on scalability/standardisation/reusability in:
> _ separating your deployment in sub parts that are in a way a
> composition of your system (groups of components), or even going to
> one component/one script (scalability)
> _ having rules like : "components-deployment-scripts are responsible
> of connecting their input ports, and only that" (cause you know what
> you need, not to what you publish) (standardisation)
> _ having some automated connections (this breaks reusabilty thougth)
>
>> --
>> Dustin Gooding
>> NASA/JSC Robotics
Thanks Willy, I'll give it a shot.
Re: our admittedly complicated deployment. It's also admittedly much better that it used to be. The trouble is we're trying to reuse as many components and as many deployment script snippets as possible, but still be able to deploy for the real robot, a Gazebo-simulated robot, and individual joint testbeds. The real robot deployment uses Orocos ports for sensor data, where the simulated robot uses ROS topics. Additionally, full robots (real or simulated) need more components than the testbeds (dynamics, etc). So, it's just messy. And with 6-10 people actively developing on all this, spread across a handful of feature branches on a handful of git repositories… it can be very confusing to track connection bugs, when the ability to inspect connection partners doesn't exist.
-dustin
port connection inspection?
2012/12/13 Gooding, Dustin R. (JSC-ER411) <dustin [dot] r [dot] gooding [..] ...>:
> On Dec 13, 2012, at 11:28 AM, Willy Lambert wrote:
>
>> 2012/12/13 Gooding, Dustin R. (JSC-ER411) <dustin [dot] r [dot] gooding [..] ...>:
>>> We've got a problem. We are trying to send a single ROS message from a GUI
>>> to an Orocos component, but for some reason, the component gets the message
>>> twice. And not just one message… basically all of the ROS-connected input
>>> ports are receiving multiple copies of messages. We assume there's
>>> something broken in our deployment script (which is admittedly complicated)
>>> like the port being connected twice…
>>>
>>> Is there any way, after things are up and running, to inspect a port or a
>>> connection and get a listing of what is connected to what? Something like
>>> a rttlib.portstats() but with more info?
>>>
>>
>> Maybe you could have a look at rtt_dot_service.
>> It should be available from here :
>> https://gitorious.org/rtt_dot-service/rtt_dot-service
>>
>> Here is some link to old threads :
>> http://www.orocos.org/forum/rtt/rtt-dev/rttdotservice-feedback
>> http://www.orocos.org/forum/rtt/rtt-dev/bug-819-new-feature-request-grap...
>> http://www.orocos.org/forum/rtt/rtt-dev/patches-rttdotservice (I don't
>> know if they were integrated)
>>
>> But to be honest if you can't manage to see in your complex deployment
>> script anything, I'm afraid the rtt_dot_service is too "experimental"
>> (especially about scalability) to help in this case ...
>>
>> The lack of composition in Orocos is still a pain to handle such
>> complex deployments.
>>
>>
>> The deployment is a very important part of the system quality in
>> complex projects, so if you begin to have problems with your
>> "admittedly complicated" deployment, I suggest that you kill
>> complexity in it.
>> I personnaly did it with working on scalability/standardisation/reusability in:
>> _ separating your deployment in sub parts that are in a way a
>> composition of your system (groups of components), or even going to
>> one component/one script (scalability)
>> _ having rules like : "components-deployment-scripts are responsible
>> of connecting their input ports, and only that" (cause you know what
>> you need, not to what you publish) (standardisation)
>> _ having some automated connections (this breaks reusabilty thougth)
>>
>>> --
>>> Dustin Gooding
>>> NASA/JSC Robotics
>
> Thanks Willy, I'll give it a shot.
>
> Re: our admittedly complicated deployment. It's also admittedly much better that it used to be. The trouble is we're trying to reuse as many components and as many deployment script snippets as possible, but still be able to deploy for the real robot, a Gazebo-simulated robot, and individual joint testbeds. The real robot deployment uses Orocos ports for sensor data, where the simulated robot uses ROS topics. Additionally, full robots (real or simulated) need more components than the testbeds (dynamics, etc). So, it's just messy. And with 6-10 people actively developing on all this, spread across a handful of feature branches on a handful of git repositories…
Yes I know that ... :D (and it was with cvs which is by far less keen
on merge issues)
If you only allow component to connect their input port in a scaled
script, it should be obvious to find this. The idea is to say all
component connections are done at the same place. It is possible if
you have "one component/one deployment script" and the rule "just
input ports"
Doing anything else has always ended in big mess like this on our project.
But I share the idea that for debugging purposes you need to know who
is connected to who and the Port interface doesn't allow this (is it
true ? I think it's the case cause from modularity point of view you
don't want people to know who is providing datas, you just want to
know that they come).