Pyros startup, operation scheme, suggestions.

[dhirajdhule]

I am launching pyros_ros node and pyros_agent together and killing both of them once done with them. But when we pass many topics to the pyros_ros instance it takes some time to initialize.

Going forward I was thinking about a different scheme. pyros_ros node can be started with rest of the ros system and will open a zmp socket with some specific address. Then whenever pyros_client comes up, it can connect to this predefined zmp socket and start communicating with ros system.

Once this is done, any other pyros_cliens even on Lan can talk to pyros_ros node.

Now, there are few unclear things. Whether it is possible to predefine the socket address? Can multiple such clients connect to a single socket? Is there anything in pyros_client which depends on pyros_ros instance apart from sharing the socket address? I hope every communication between them is through pyzmp sockets.

[asmodehn]

I have been thinking about doing it this way as well. It is definitely
possible and the socket address is the only mandatory piece of information
required for communication ( at the moment I get it using the node name... )

One thing that might be tricky with this way of starting pyros, is that now
it implies configuration is same for all clients... if one client needs a
different configuration it gets applied to all...

Whereas currently I can start rostful ( start one pyros_ros node with
config A ) and start celeros ( start another pyros_ros node with config B )

Not sure which approach is the most practical... It would be good to be
able to do both though, at the moment the approach you detail is not easily
possible, and it is certainly something we should improve.

On Oct 18, 2016 3:34 PM, "Dhiraj D" [email protected] wrote:

I am launching pyros_ros node and pyros_agent together and killing both of
them once done with them. But when we pass many topics to the pyros_ros
instance it takes some time to initialize.

Going forward I was thinking about a different scheme. pyros_ros node can
be started with rest of the ros system and will open a zmp socket with some
specific address. Then whenever pyros_client comes up, it can connect to
this predefined zmp socket and start communicating with ros system.

Once this is done, any other pyros_cliens even on Lan can talk to
pyros_ros node.

Now, there are few unclear things. Whether it is possible to predefine the
socket address? Can multiple such clients connect to a single socket? Is
there anything in pyros_client which depends on pyros_ros instance apart
from sharing the socket address? I hope every communication between them is
through pyzmp sockets.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#101, or mute the thread
https://github.com/notifications/unsubscribe-auth/AANgSFVXM-uJCW7Zywis2ZsLoudpCnPwks5q1HZygaJpZM4KZdpV
.

[dhirajdhule]

Yeah, that would be a good feature. The good thing for me is that I need same configuration for all clients, so not a problem for me I guess.
So I will start separating them. But there are few things I don't know how to implement. Say I want to call pyros_ros node from a remote client on Lan, then how do I specify the IP address and all. Could something like this be a good idea?
Also, rostful too in my case needs the same config. So I was thinking if I could start only pyros node and have many clients talk to ros-sytem through it. Do you think this is easy to do given that I need same config for all? Any hint on how should I go about it?

[dhirajdhule]

will be going with multiprocess.manager to add this functionality.

[asmodehn]

Just to sum up our gitter discussion about this topic (plus some extra thought I had in the mean time...) :

Same configuration for all clients usecase means we can start zmp server node / ros-node first, and keep it running. then be able to start clients independently.

This means node discovery needs to work differently than now. So we need to have a central "well known node" that holds the information about available service. Like a "zmp-master"... this needs to be implemented, and we need to use the zmq communication (using zmp socket addresses from https://github.com/asmodehn/pyzmp/blob/master/pyzmp/node.py#L161 ) for transmitting information about node going up, and probably some kind of heartbeat to determine nodes going down...

In the future that node should be made "highly available" to avoid having a single point of failure.

I made an issue in pyzmp to document the implementation of this. This will give us more flexibility in "how we can start pyros".

[asmodehn]

I recently made quite a lot of changes (waiting for merge in #103), and I reduced the time to wait for interfacing topics. Feel free to try it out and send me some feedback if you have some time.

I started also #107 for your main concern about different way to start pyros.