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 > > 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