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