ROS transport and latching

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.

Should I submit this somewhere?

Regards,
Miguel

AttachmentSize
rtt_ros_integration_latching.patch746 bytes

ROS transport and latching

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.

Sylvain

ROS transport and latching

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?

Miguel.

> Sylvain

ROS transport and latching

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

> 2013/1/25 Sylvain Joyeux <sylvain [dot] joyeux [..] ... <javascript:;>>:
> > 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

ROS transport and latching

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.
- connect a ROS node that listens to that topic.
- set the communication policy to a "buffer loss" that is the one you like.

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.

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

Herman

ROS transport and latching

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.

ROS transport and latching

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

ROS transport and latching

2013/1/25 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> 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.

I think we're on the same train here. I'm not handling communication
issues from the FSM itself, but from the lua component which executes
the FSM instead. That's how the events are meant to be delivered to
the rest of the Orocos system according to the example I posted from
the LuaCookbook [1]. The only thing I changed from the code in that
example is using a function that writes to a data port using
'std_msgs/String' type instead of using 'string' type, which is what
the callback generated by 'rfsm_rtt.gen_write_fqn(fqn_out)' does.

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

I have to admit, though, that sometimes I find it difficult to figure
out the 'good design' solutions. Is there any better place to discuss
this kind of matters than this list? E.g., is there some mailing-list
or forum related to the BRICS project?

>
>> 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.

This, I think, is solved by Sylvain's comment and the (new) patch I proposed.

>
>> Thanks for your comments anyways, and I will gladly accept to be
>> corrected should I be speaking nonsense. :)
>
>
> The same holds for me! :-)
>

I'm glad ;)

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

Miguel.

ROS transport and latching

On Fri, 25 Jan 2013, Miguel Prada wrote:

> 2013/1/25 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> 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.
>
> I think we're on the same train here. I'm not handling communication
> issues from the FSM itself, but from the lua component which executes
> the FSM instead.
Ok! _That_ is ok with me :-) But then one should have some kind of "code
generation" tool, to keep the FSM part of the Lua script (i.e., the part
that does not use the at_entry and _at_exit calls) decoupled from the
"software container" part (i.e., the part that is responsible for
scheduling, "logging" etc). Unfortunately this kind of tooling does not yet
exist, as far as I know.

> That's how the events are meant to be delivered to
> the rest of the Orocos system according to the example I posted from
> the LuaCookbook [1]. The only thing I changed from the code in that
> example is using a function that writes to a data port using
> 'std_msgs/String' type instead of using 'string' type, which is what
> the callback generated by 'rfsm_rtt.gen_write_fqn(fqn_out)' does.
>
> [1] http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc51
>
> I have to admit, though, that sometimes I find it difficult to figure
> out the 'good design' solutions. Is there any better place to discuss
> this kind of matters than this list? E.g., is there some mailing-list
> or forum related to the BRICS project?

An internal one only. Here
<https://groups.google.com/forum/?hl=en&fromgroups#!forum/ras-tcsoft>
is a possible new alternative. A large subset of the people involved will
join at workshops around this theme in Leuven (Feb 11) and Lyon (at the ERF
on March 20th). The goal is to create something "sustainable" about
MDE-based robot software 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.
>
> This, I think, is solved by Sylvain's comment and the (new) patch I proposed.

I think indeed that I agree with Sylvain.

Heran

ROS transport and latching

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.