Re: Digest for rosbridge-users@googlegroups.com - 2 Messages in 1 Topic

[Ian Sherman]

Thank you Chad. 

The Github issue is here: https://github.com/RobotWebTools/rosbridge_suite/issues/65

Looking forward to working on this with Russell et. al.

Ian

On Thu, Dec 5, 2013 at 10:44 AM, <rosbrid...@googlegroups.com> wrote:

  Today's Topic Summary

Group: http://groups.google.com/group/rosbridge-users/topics

• Adding subscription IDs to ROSBridge-published messages [2 Updates]

 Adding subscription IDs to ROSBridge-published messages

Ian Sherman <i...@botndolly.com> Dec 04 05:39PM -0800  

I would like the ROSBridge server to return subscription ids along with
messages. This would allow me, on the client side, to associate received
messages with the components that requested the subscription. Then a
component, could, for example, unsubscribe after it receives N messages.
 
After digging into the ROSBridge source I see the following:
 
We have a capabilities.subscribe.Subscription object, which in its own
words "Keeps track of the client's multiple calls to subscribe." When a
client requests a subscription to a topic it has previously subscribed to,
with different parameters or not, the Subscription object associated with
that topic tells the internal.subscribers.SubscriberManager to add a
callback to its internal.subscribers.MultiSubscriber associated with that
topic. The MultiSubscriber will, in turn, add the callback that propagated
its way through thus far to the rospy.Subscriber that actually interacts
with the ROS master.
 
Which brings me to my first question. On line 127 of internal.subscribers
[1] we see the MultiSubscriber maintains a dict of client_ids to single
callback functions. Shouldn't this be a dict of client_ids to lists of
callback functions? In its current implementation, the dict would only keep
track of the most recently added callback. In practice this is invisible at
the moment, since it's actually the rospy.Subscriber that maintains a list
of callbacks, but it could have consequences in the future.
 
The callback that's propagated to rospy.Subscriber is, at its core, the
publish function from the capabilities.subscribe.Subscribe class that has
been curried and wrapped a few times. Somehow, we need to bind the
subscription id to this callback function so the id is actually returned
with the JSON object back to the client. Where should this happen?
 
The subscription ID (aka sid) currently makes it as far as the subscribe
function of the capabilities.subscribe.Subscription object. Unfortunately
all the subscriptions managed by a capabilities.subscribe.Subscription
object share the same callback (wrapped in a
internal.subscription_modifiers.MessageHandler that is responsible for
throttling the callback rate). I suspect that what we really want is the
MessageHandler to maintain a list of callbacks, each with a different sid,
so it can publish to each sid independently.
 
Does anyone have any thoughts on this approach?
Anyone that can explain the thinking behind the current design?
On line 252 of rosbridge_library.capabilities.subscribe I see "# TODO:
fragmentation, proper ids" [2] -- what does "proper ids" refer to?
Does including the sid have implications for fragmentation messages, which
also use the "id" field?
 
One consequence I can see is that the same message with the same frame may
be sent to the client multiple times, once for each sid.
 
To inform the discussion, right now the ROSBridge Protocol reads:
"If a client has multiple subscriptions to the same topic, then messages
are sent at the lowest throttle_rate, with the lowest fragmentation size,
and highest queue_length. It is recommended that the client provides IDs
for its subscriptions, to enable rosbridge to effectively choose the
appropriate fragmentation size and publishing rate."
 
I'm assuming that the second sentence there means that without unique ids,
ROSBridge will clobber the subscription parameters with whatever the most
recent subscription request was, rather than choosing the "lowest common
denominator" of all subscription requests. Because it's not clear how sids
are used otherwise.
 
Many thanks. Happy to move this to a Github issue conversation if that's
preferred.
 
Sincerely,
Ian
 
[1]
https://github.com/RobotWebTools/rosbridge_suite/blob/hydro-devel/rosbridge_library/src/rosbridge_library/internal/subscribers.py#L127
 
[2]
https://github.com/RobotWebTools/rosbridge_suite/blob/hydro-devel/rosbridge_library/src/rosbridge_library/capabilities/subscribe.py#L252
 
--
Ian Sherman
Lead Engineer
 
BOT&DOLLY
150 Mississippi Street San Francisco CA 94107
o. 415.701.9700
www.botndolly.com


 

Chad Jenkins <ode...@gmail.com> Dec 05 11:24AM -0500  

Hi Ian,
 
First, congrats :)
 
Thanks for this bringing this issue forward, and provide very thorough
description. The issue of handling multiple subscriptions has been a topic
of active discussion in the design of rosbridge for some time. So, this
will be a good discussion to have.
 
As you mentioned, it would be helpful move this to an issue on the
rosbridge_suite repo. I expect Russell Toris et al. will have thoughts and
eagerness to move this forward.
 
Chad
___
 
 
 


 

--
You received this message because you are subscribed to the Google Groups "Rosbridge Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rosbridge-use...@googlegroups.com.
To post to this group, send email to rosbrid...@googlegroups.com.
Visit this group at http://groups.google.com/group/rosbridge-users.
For more options, visit https://groups.google.com/groups/opt_out.

--

Ian Sherman

Lead Engineer

BOT&DOLLY

150 Mississippi Street San Francisco CA 94107

o. 415.701.9700

www.botndolly.com