All of these parameters are looked up by the publisher plugin. I assume the
master is running on the robot. The two options are:
1. Run image_rotate on the robot, subscribing to raw image_rect_color. Run
other node on the desktop, subscribing to compressed rotated image.
2. Run image_rotate on the desktop, subscribing to compressed
image_rect_color. Run other node on the desktop, subscribing to raw rotated
image.
In both cases the compressed publisher is on the robot, so hitting the
master shouldn't be a big deal. Option 2 is probably better just because the
rotated image can be larger than the original, so you might as well send the
original over the network bottleneck.
Of course, profiling should tell more.
Patrick
On Thu, Nov 18, 2010 at 9:41 PM, Blaise Gassend <
blaise@willowgarage.com>wrote:
> On Thu, Nov 18, 2010 at 9:40 PM, Blaise Gassend <blaise@willowgarage.com>
> wrote:
> > Ah, it is indeed probably the overhead of going across the network to
> > the master that is causing the lagginess.
>
> (The access to the parameter server is an access to the master)
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
(text/plain)