Hi trinighost,

On the technical issue of whether it is possible to communicate with ROS services without calling rospy or ROS native code with a modest amount of code, I can confirm that it is possible (YARP does it).  The service protocol is particularly straightforward.  The XML/RPC API is adequately documented (and can be probed easily), and the connection headers are simple.  Serialization is well documented.  For my purposes, I turned off md5 hashes on types (just send "*" as the hash if I remember correctly) and serialized "by hand" since the provided IDL was a bit too intertwined with the ROS library and build machinery to extricate.

On the strategic issue of whether doing any of this is a good idea, I can't argue with Ken.  But I can confirm that it is possible to load that gun and point it at your foot :-).

Cheers,
Paul

On Wed, Oct 6, 2010 at 12:00 PM, Ken Conley <kwc@willowgarage.com> wrote:
I think several things are being conflated here:

 1. Whether or not something is a node: Being a non-node simply
relates to how much infrastructure a single process starts up. The
difference in code is very little.
 2. Platform independence: rospy is platform independent, save for a
single line PYTHONPATH bootstrapper that doesn't work on Windows
(yet). It's very easy to override this.
 3. "Modest" segment of code: I would look at rospy or roslua. I get
the feeling that they are not as big as you think they are.

I think you'll find that, in implementing the steps you outline, you
will have implemented a nearly complete ROS client library, but by
being non ROS native, it will be more brittle and harder to maintain
in the long run. Similarly, by avoiding a ROS install, you'll jump
through extra hoops to get autogenerated service classes into your
codebase.

 - Ken


On Wed, Oct 6, 2010 at 7:30 AM, trinighost <trinighost@gmail.com> wrote:
>
> If I interpreted this sentence and the spirit of that section properly, the
> service client does not have to be a
> ROS node, and any code which could:
>
> 1) negotiate the XMLRPC handshaking (which seem to conform to some
> standard),
> 2) generate the proper connection header, and
> 3) send and decode serialized messages (over sockets and again apparently
> generated in "a" standard manner)
> ought to be able to communicate with a ROS based service provider.
>
> This should be an avenue available to code which doesn't call rospy or ROS
> native code.
> I'm interested in services which can communicate with ROS services but do
> not require a ROS install, or at least are dependent on a modest, platform
> independent segment of ROS code.
> Did I over simplify what I read?
> --
> View this message in context: http://ros-users.122217.n3.nabble.com/examples-of-non-ROS-service-clients-tp1636253p1642837.html
> Sent from the ROS-Users mailing list archive at Nabble.com.
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users