+1

I think the proposed transition plan is adequate as long as it's easy for people to discover. I suggest making sure that this change is in the Fuerte release notes/announcement so that users have some measure of forewarning.

- Eric

On Tue, Nov 1, 2011 at 11:14 PM, Patrick Mihelich <mihelich@willowgarage.com> wrote:
Let's try to revive this discussion...

+1 from me on the proposed spec.

The transition plan sounds adequate to me, perhaps even overkill. But I'm not a user of LaserScan or Range, just PointCloud2, which already uses NaN and Inf.

Cheers,
Patrick 


On Fri, Oct 14, 2011 at 12:53 PM, Ken Conley <kwc@willowgarage.com> wrote:
This has been assigned number 117 and is viewable here:

http://www.ros.org/reps/rep-0117.html

cheers,
Ken

On Thu, Oct 13, 2011 at 8:28 PM, Chad Rockey <chadrockey@gmail.com> wrote:
There is a need to communicate special values within the distance measurement sensor messages (Laserscan, Range, PointClouds).  In this REP, I propose using the standard floating point values of -Inf, NaN, and +Inf to represent more information within the current messages.  Previous discussion is available on our wiki page (http://www.ros.org/wiki/fuerte/Planning/Drivers) and in ticket #4367 (https://code.ros.org/trac/ros-pkg/ticket/4367).

Attached is my first draft of this REP.  The Drivers SIG has reviewed this REP, and we now seek community input.  Our main concern with this REP is transition strategy.  We wish to provide minimal disruption with this change (no message migration, minimal client code changes); however, in certain cases NaNs may propagate through systems.  Our primary concern is how to adequately prepare the community for this change.

To mitigate transition problems, we propose to add a node, nodelet, and library that will clean the target messages of NaNs and Infinities and revert the new measurements to the legacy 'max_range + 1' behavior.  This tool would only be supported for one release and removed for the Groovy release.

Thank you for your feedback.

 - Chad

_______________________________________________
ros-developers mailing list
ros-developers@code.ros.org
https://code.ros.org/mailman/listinfo/ros-developers

_______________________________________________
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



_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users