[ros-users] calling a service in rospy without a type

[Ken Conley]

Again, this is being tested/prototyped in rosh (rosh is just a thin
layer on top of rospy). As ROS is feature frozen, there's time to play
around -- feel free to open a feature request ticket. There are
interesting consequences as well as optimizations that rosh is turning
up (e.g. in rosh, you can even omit typing for publisher if a
subscriber exists).

 - Ken

PS Google Protocol Buffers debuted after we had already released ROS.
The thinking then was that they were very similar, but inability to
express arrays of primitives as anything but binary blobs led us to
believe that we would end up implementing the ROS msg IDL inside of
protocol buffers.

On Fri, Jun 18, 2010 at 6:50 PM, Rosen Diankov <rosen.diankov at gmail.com> wrote:
>> ROS messages are strongly typed. It's not really a question of Python
>> favoring duck-typing, because it has to express the type and
>> dependency requirements of what it interfaces with.
>
> the original request was to add a some user transparency to types by
> making the service_class field optional in the ServiceProxy class.
> this is possible because rospy can deduce the ros service type from
> the handshake.
>
> rosen,
>
> PS: it is interesting you mention Google Protocol Buffers; it seems
> that the usage and functionality of ros messages is converging to
> them.
>
>>> There are cases where being able to call a service without knowing its
>>> type could make it robust to the plethora of custom messages created
>>> by ROS users.
>>>
>>> As for overlooking package dependencies, with python this is not a
>>> problem. If the package path is sent with the type, then rospy can
>>> auto-generate the python class without relying on a pre-generated
>>> class to include; and I'm sure you can come up with a caching scheme
>>> to make this quicker the next time around.
>>
>> Google Protocol Buffers do auto-generate the Python class from their
>> description, so it is a possibility. However, the predominant request
>> I get is to make rospy have better performance and less latency. I'm
>> exploring whether or not rosh provides a natural boundary to express
>> these opposing requirements.
>>
>>  - Ken
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>