Op vrijdag 25 januari 2013 schreef Miguel Prada (
miguel [dot] prada [dot] sarasola [..] ...) het volgende:

> 2013/1/25 Sylvain Joyeux <sylvain [dot] joyeux [..] ... > > On 01/25/2013 12:33 PM, Miguel Prada wrote:
> >>
> >> Hi all,
> >>
> >> I'm developing an application with Orocos+ROS, and I've just found out
> >> that the ROS publisher created for the ROS transport does not set the
> >> "latch" option to true. This option makes the last message published
> >> to be stored and sent to new subscribers even after its been
> >> published.
> >
> > The latching should probably be enabled if the 'init' option in the
> > connection policy is set. In non-streaming (i.e. port-to-port
> connections),
> > it controls the same behaviour (send the last known sample to new
> > connectees)
> >
> > In no way should it be set "by default". It is really a case-by-case
> (i.e.
> > policy-driven) thing.
>
> That seems like the best solution for me too. My bad for not knowing
> the options in ConnPolicy properly ;)
>
> The attached patch should do the work then. Should I submit it elsewhere?

Nope, we'll apply it one of these days. Thanks, it's more of a bugfix than a
feature addition imo.

>
> Miguel.
>
> > Sylvain
>

Peter

On Fri, 25 Jan 2013, Miguel Prada wrote:

> 2013/1/25 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Fri, 25 Jan 2013, Miguel Prada wrote:
>>
>>> Hi all,
>>>
>>> I'm developing an application with Orocos+ROS, and I've just found out
>>> that the ROS publisher created for the ROS transport does not set the
>>> "latch" option to true. This option makes the last message published
>>> to be stored and sent to new subscribers even after its been
>>> published.
>>>
>>> The specific situation that raised my attention is as follows. I'm
>>> running a rFSM component in the Orocos side which takes care of some
>>> coordination aspects, and I'm willing to forward its state to the ROS
>>> side. This can be done by using the "post_step_hook_add" function to
>>> call a function at each state machine step, but then the state will
>>> only be publish at certain times (e.g. state changes), instead of
>>> periodically, and ROS components that subscribe to this topic will get
>>> no information on the current state until one of such events occur. If
>>> the publisher's "latch" option would be set to true, the subscriber
>>> would automatically get the last state message published, which is
>>> something I'd find very useful.
>>>
>>> I was wondering if there's a reason for not setting the latching
>>> option, or if it was just left like that by default. If there's no
>>> specific reason, I think setting this option would only entail a minor
>>> change to "rtt_ros_integration" stack shown in the attached patch.
>>
>>
>> While I understand the reasons why you want to do what you want to do, I do
>> not find the suggested solution the right one:
>> - if you want a state machine to make its state public, add a component
>> ("state listener") to the Orocos side of your application, that is
>> subscribed to state change events, and sends them over a data port.
>> - connect that data port to a ROS topic connection.
>
> I can currently do these two steps without a dedicated state listener
> node, by connecting the state change port directly to a ROS topic.
> This only requires me to use a ROS message format for the state change
> port which I don't think it's a big deal.
>
>> - connect a ROS node that listens to that topic.
>> - set the communication policy to a "buffer loss" that is the one you like.
>
> AFAIK, increasing the buffer size in the connection policy is not
> going to help on my scenario. This would ensure that, should state
> changes be published too fast for the ROS publisher to handle them,
> they would be queued up instead of dropped. However the same issue
> would remain where subscribers connected after a message has been
> published would not receive the last message published.
>
>>
>> In this way, you keep the Coordination aspects of the FSM decoupled from
>> the logging, in a reusable way; and the Communication policy configuration
>> decoupled from where the communicated data is created.
>
> I can't see how your approach improves decoupling of the FSM from the
> logging. In any case I need the component running the FSM to write the
> state changes to a data port, either using a 'string' type as shown in
> the examples in [1] or using ROS types (e.g. std_msgs/String). It
> would somehow decouple the component from the ROS ecosystem, but not
> from the logging itself, right?

The decoupling I advocate is as follows:
- let the FSM do its thing, that is, reacting to events and sending out
events, with some simple event logic computations inside;
- let other components interact with the FSM just by sending/receiving
events;
- don't pollute the FSM with Communication issues, let alone Communication
policy issues.
- the only application-level "plugins" that a Coordinating FSM should allow
are event logic processing functions.

In this way, the FSM is completely independent of the software framework in
which is runs, and from the Communication infrastructure or policies.

Your suggestions (if I understood them correctly) are introducing plugin
code into an FSM hook that has nothing to do with its real role,
Coordination. That is not good design.

> Also, the component isn't more coupled to the communication policy
> than before, since the only change would be a default value of the
> communication configuration, which BTW is not accessible for
> configuration in any way.

Then that is an error in the Communication parts of the framework, not to
be "solved" by hacking the Coordination part.

> Thanks for your comments anyways, and I will gladly accept to be
> corrected should I be speaking nonsense. :)

The same holds for me! :-)

>>> Should I submit this somewhere?
>>>
>>> Regards,
>>> Miguel

Herman

Sorry, I forgot the reference...

[1] http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc51

2013/1/25 Miguel Prada <miguel [dot] prada [dot] sarasola [..] ...>:
> 2013/1/25 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Fri, 25 Jan 2013, Miguel Prada wrote:
>>
>>> Hi all,
>>>
>>> I'm developing an application with Orocos+ROS, and I've just found out
>>> that the ROS publisher created for the ROS transport does not set the
>>> "latch" option to true. This option makes the last message published
>>> to be stored and sent to new subscribers even after its been
>>> published.
>>>
>>> The specific situation that raised my attention is as follows. I'm
>>> running a rFSM component in the Orocos side which takes care of some
>>> coordination aspects, and I'm willing to forward its state to the ROS
>>> side. This can be done by using the "post_step_hook_add" function to
>>> call a function at each state machine step, but then the state will
>>> only be publish at certain times (e.g. state changes), instead of
>>> periodically, and ROS components that subscribe to this topic will get
>>> no information on the current state until one of such events occur. If
>>> the publisher's "latch" option would be set to true, the subscriber
>>> would automatically get the last state message published, which is
>>> something I'd find very useful.
>>>
>>> I was wondering if there's a reason for not setting the latching
>>> option, or if it was just left like that by default. If there's no
>>> specific reason, I think setting this option would only entail a minor
>>> change to "rtt_ros_integration" stack shown in the attached patch.
>>
>>
>> While I understand the reasons why you want to do what you want to do, I do
>> not find the suggested solution the right one:
>> - if you want a state machine to make its state public, add a component
>> ("state listener") to the Orocos side of your application, that is
>> subscribed to state change events, and sends them over a data port.
>> - connect that data port to a ROS topic connection.
>
> I can currently do these two steps without a dedicated state listener
> node, by connecting the state change port directly to a ROS topic.
> This only requires me to use a ROS message format for the state change
> port which I don't think it's a big deal.
>
>> - connect a ROS node that listens to that topic.
>> - set the communication policy to a "buffer loss" that is the one you like.
>
> AFAIK, increasing the buffer size in the connection policy is not
> going to help on my scenario. This would ensure that, should state
> changes be published too fast for the ROS publisher to handle them,
> they would be queued up instead of dropped. However the same issue
> would remain where subscribers connected after a message has been
> published would not receive the last message published.
>
>>
>> In this way, you keep the Coordination aspects of the FSM decoupled from
>> the logging, in a reusable way; and the Communication policy configuration
>> decoupled from where the communicated data is created.
>
> I can't see how your approach improves decoupling of the FSM from the
> logging. In any case I need the component running the FSM to write the
> state changes to a data port, either using a 'string' type as shown in
> the examples in [1] or using ROS types (e.g. std_msgs/String). It
> would somehow decouple the component from the ROS ecosystem, but not
> from the logging itself, right?
>
> Also, the component isn't more coupled to the communication policy
> than before, since the only change would be a default value of the
> communication configuration, which BTW is not accessible for
> configuration in any way.
>
> Thanks for your comments anyways, and I will gladly accept to be
> corrected should I be speaking nonsense. :)
>
>>
>>> Should I submit this somewhere?
>>>
>>> Regards,
>>> Miguel
>>
>>
>> Herman
>
> Miguel.