<br><br><div class="gmail_quote">On 16 January 2013 18:11, Piyush <span dir="ltr"><<a href="mailto:piyushk@gmail.com" target="_blank">piyushk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+1 for binding to INADDR_ANY, though I suspect there are a number of<br>
ramifications I am not aware about right now. Thanks for pointing out<br>
your package Bill, it looks like a significant improvement over Thomas<br>
Moulard's original.<br>
<br>
The multimaster approach is designed to handle all the problems you've<br>
mentioned (apart from #4). Daniel and Jihoon from Yujin will be able<br>
to give better and more up to date answers, as it has been a bit of<br>
time since I've helped out with the code.<br></blockquote><div><br></div><div>We've simply been ironing out bugs and polishing it since then. The gateway should make getting things from one place to another much easier, including monitoring. Right now though, we don't do any transport control (i.e. things like compression, or transport hints, or even transport type selection - tcp/udp etc). We were waiting for next gen comms to land and hopefully provide input to that to push it in the right direction, however we'll probably need something before then. </div>
<div><br></div><div>Having talked to the willow group yesterday - they are wanting to land something with better transport control as well. We're also probably going to need it for upcoming milestones in april, so we'll probably quickly move to putting an option in the gateway model to command either direct flips (as they are now), or relayed flips which use relays running on something like zeromq and transport controls doing things like compressing your messages. If you have a big interest in pushing in that direction let me know and we'll up the priority.</div>
<div><br></div><div>Daniel.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - If your only problem is that you have indicator lights over<br>
rosserial - it might be overkill to switch to the multimaster<br>
approach. It will be easier having a regular ros node interfacing with<br>
your microcontroller using a serial library.   You can then run a<br>
single core on the robot.<br>
 - If you are planning on having multiple user machines talk with your<br>
robot, then the multi-master approach is well suited for you. This<br>
approach should also be better in the long run for dealing with wifi<br>
outages.<br>
<br>
If you do use the multi master approach:<br>
 - A single local master + gateway on the robot.<br>
 - The rocon hub can be anywhere. If all of your machines are on the<br>
same network (or in any situation where mDNS/zeroconf/avahi works),<br>
then you should place the hub on machine with the least chance of<br>
network failure. If zeroconf won't work, you'll need it on a machine<br>
with a static IP or a resolvable address.<br>
 - Nothing really changes with multiple users.<br>
<br>
I don't know how well wifi outages have been tested on the gateway<br>
framework as of right now, but it is something that will definitely be<br>
done over the next few months.<br>
<br>
Best,<br>
Piyush<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Jan 16, 2013 at 7:03 AM, Michael Gratton <<a href="mailto:mikeg@cse.unsw.edu.au">mikeg@cse.unsw.edu.au</a>> wrote:<br>
> On 16/01/13 06:57, Bil Morris wrote:<br>
>> I am not sure why the XML RPC server does not support binding to<br>
>> INADDR_ANY instead of a specific ip address.<br>
><br>
> Yeah, this would be great from a systems perspective! Why doesn't it do<br>
> that already?<br>
><br>
>> If the server could be modified to connect to all interfaces and rebind<br>
>> the sockets when the xmlrpc server receives<br>
>> a SIGHUP, then I think you could take something like our upstart scripts<br>
>> [1] and modify them to start ROS on boot and<br>
>> and send SIGHUP to ROS whenever the WiFi interface bounces.<br>
><br>
> IIRC if you listen on any socket, you don't need to re-bind as<br>
> interfaces come and go, so I don't think even sending a signal would<br>
> even be necessary.<br>
><br>
> For people that want a robot to "just work" as soon as you switch it on,<br>
> this would make life much easier.<br>
><br>
> //Mike<br>
><br>
> --<br>
> Michael Gratton <<a href="http://www.cse.unsw.edu.au/~mikeg/" target="_blank">http://www.cse.unsw.edu.au/~mikeg/</a>><br>
> UNSW School of Computer Science and Engineering.<br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> 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>
><br>
_______________________________________________<br>
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><br clear="all"><div><br></div>-- <br>Phone : +82-10-5400-3296 (010-5400-3296)<br>Home: <a href="http://snorriheim.dnsdojo.com/" target="_blank">http://snorriheim.dnsdojo.com/</a><br><div>
Yujin R&D: <a href="http://rnd.yujinrobot.com/" target="_blank">http://rnd.yujinrobot.com/<br></a><br></div>