[ros-users] [Ros-developers] Draft REP: Informational Distance Measurements

[Tully Foote]

+1

The transition seems fine.  I suggest that a wiki page with all
released packages that use one of these datatypes be setup in a table
and people can do an audit of each one and note that the package has
been checked, and possibly ticketed if things need to be fixed.  With
several people checking it should go relatively quickly.  Maybe also a
space to share useful grep commands.

Tully

On Tue, Nov 1, 2011 at 8:21 PM, Eric Perko <wisesage5001 at gmail.com> wrote:
> +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 at 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 at 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 at 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 at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-developers
>>>>
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>



-- 
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827