it's actually not that egregiously bad a solution, i've been streaming
stereo images around without much problem. it was a little laggy
during the pr2 workshop with all the other pr2's around but it works
much better now in our lab.
besides, a python process isn't the best place to be doing low latency
vision anyways...
On Jun 21, 2010, at 7:42 PM, Dan Lazewatsky wrote:
> Thanks for the update. I haven't played around with republishing too
> much, but I'll give it a shot again and see how it works.
>
> -Dan
> On Jun 21, 2010, at 6:36 PM, Patrick Mihelich wrote:
>
>> Hi Dan,
>>
>> On Mon, Jun 21, 2010 at 10:29 AM, Dan Lazewatsky <lazewatskyd@cse.wustl.edu
>> > wrote:
>> I was wondering what the status of the python bindings for
>> image_transport is.
>>
>> There hasn't been any serious work on Python bindings for
>> image_transport.
>>
>> They would definitely be nice to have, but actually writing them
>> presents some thorny technical issues. Either you need to write
>> pure-Python analogues of image_transport *and* all plugins, or find
>> a way to wrap the C++ implementation and reuse the existing
>> plugins. The latter approach seems more attractive in terms of code
>> reuse and not increasing the burden on plugin implementers; but it
>> requires changing the plugin interfaces to abstract away explicit
>> use of roscpp (NodeHandle), as that won't play nice with rospy in
>> the same process.
>>
>> In short: this is all possible, just unpleasant and time-consuming.
>> Since dropping in an extra republish node works adequately, I
>> haven't made it a priority.
>>
>> I've been limping along either using C++ or subscribing directly to
>> image messages in python, but it's starting to become a problem. The
>> republish idea on the wiki doesn't seem like a particularly good
>> solution.
>>
>> Sometimes it is actually the best solution! If the image topic is
>> published on machine A and there are multiple subscribers on a
>> machine B, republishing the images in raw format on machine B
>> minimizes both network bandwidth and CPU usage.
>>
>> For the one-to-one case - only one subscriber on the second machine
>> - it's true that spinning up a republish node is an inconvenience
>> and adds a little latency. I'd suggest adding it to your subscriber-
>> side launch file.
>>
>> Cheers,
>> Patrick
>> _______________________________________________
>> 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
(text/plain)