<br><br><div class="gmail_quote">On 9 September 2011 02:34, I Heart Robotics <span dir="ltr"><<a href="mailto:iheartrobotics@gmail.com">iheartrobotics@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, 2011-09-09 at 02:09 +0900, Daniel Stonier wrote:<br>
> I got started from that one - thanks for the push in the right<br>
> direction. I was going to contact you about it, but here is as good a<br>
> chance as any :)<br>
><br>
><br>
> I ended up pushing a little further and in some different directions<br>
> though:<br>
><br>
><br>
>       * Permit any ros program to publish services of any type, not<br>
>         just the _ros-master._tcp.<br>
>       * In the same vein, listening for any service type.<br>
<br>
</div>I think of services offered by nodes as being subservices of ROS Master,<br>
but if publishing services is optional I'm not opposed. However, I think<br>
publishing every service by default is unnecessary.<br>
<br>
I think someone needs to officially register the ROS Master service or<br>
whatever ever primary service we decide on.<br>
<br>
>       * Multiple publisher/listener support<br>
<div class="im">>       * Runtime addition of publishers/listeners (sometimes needed to<br>
>         find free ports, then configure - there are other use cases<br>
>         too).<br>
><br>
><br>
> I dropped the python implementation as it couldn't do runtime. The c++<br>
> library had just implemented some threaded poll locking, and that<br>
> ended up working well for runtime additions after the polling loop was<br>
> spun up. In the end, what it resulted in was a package that had:<br>
><br>
><br>
>       * A pure c++ lib that could be used by any program directly<br>
>         (much simpler c++ api than the avahi api).<br>
>       * A ros node with pub/sub req/resp api for adding<br>
>         services/listeners, listing published and discovered services<br>
>         and publishers for new/lost services.<br>
>       * The node can also do static configuration from the param<br>
>         server.<br>
> In most cases I'll just run the node alongside the rest of the ros<br>
> system. If I want the ros master published, I can configure that in<br>
> the yaml, or spin off a small python script to do the job. It can then<br>
> also be used by any other package for any other service.<br>
<br>
</div>This seems reasonable. There was no particular reason it was originally<br>
in Python.<br>
<div class="im"><br>
<br>
> The android jmdns implementation is a bit different, we just kept that<br>
> to a library api as I can't envisage (for the near future) a complex<br>
> system of nodes running on 'droids.<br>
<br>
</div>This makes sense for now.<br>
<div class="im"><br>
> I don't think we'll have any issue moving our zeroconf code out to a<br>
> public server - shall we get together and polish off a zeroconf stack?<br>
<br>
</div>We should probably do an API Review for it since I know Victor over at<br>
Pal Robotics will probably have some input.<br></blockquote><div><br></div><div>That sounds like a good place to start. We have Korean family week next week (much like a western christmas) - I'll push some code onto a public server once that's done and arrange a review. Do you have any objections to it being on github?</div>
<div><br></div><div>Regards,</div><div>Daniel Stonier.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">--<br>
I Heart Robotics<br>
<a href="http://www.iheartrobotics.com" target="_blank">http://www.iheartrobotics.com</a><br>
<3<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br>