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
>