+1 for a warning as well. 

We do all our operation over wifi and this basically forced me to rewrite all the device drivers with roscpp on my systems (in particular axis_camera). 

The bug is even more subtle than that. I can't prove it right now, but I think if you start listening to a Python publisher over wifi, then stop listening, send the robot over a long loop where it loses connectivity, and then start to listen again when the robot is back, you will observe a few seconds of delay in your data. That happens for small data (e.g. compass) or large chunk (e.g. images). 

For images, without moving away, then delay can accumulate slowly: I've done face tracking demos over wifi with a PTZ, it started fine and was basically unusable by the end of the session due to accumulated delays. Restarting the listener would not solve the issue. 

rospy in its current state is now used very very sparsely on my embedded systems. 


On Thu, Mar 6, 2014 at 7:13 PM, Benjamin Charrow <bcharrow@seas.upenn.edu> wrote:
+1 for a warning; I've definitely gotten bitten by this issue when controlling a robot over wifi.

Ben


On Thu, Mar 6, 2014 at 4:20 AM, Paul Mathieu <paul.mathieu@pal-robotics.com> wrote:
Right now, it appears that the default setting is easily broken for a minority of use cases and non-intuitive to debug. And that would be good to amend. Better to have it working everywhere and optimisable for power use cases. 

Adding some notes on the wiki probably won't do much to notify existing users - typically copy/pasting from nearby code what I do.

So back to my earlier question - is setting a queue size expensive in the python implementation? If there isn't a technical weakness there, then I'm all for a) warnings and a migration point sometime in the future - it wouldn't be very costly to mechanically search and destroy all rospy.Publisher instances in a ros workspace. 

I agree with Daniel. Changing the default will break existing code, but if the default is undesirable in a non-negligible amount of cases, then it should be changed.
I would be in favor for a warning in Indigo, and a change of behavior in J-turtle.

Paul 

_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users



_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users




--
Cedric Pradalier