[ros-users] Wiki documentation for twist_mux package
Jorge Santos Simón
jsantossimon at gmail.com
Thu May 7 15:16:40 UTC 2015
Same happen again some days ago, with a new driver for DepthSense DS325 3D
Camera.
Maybe we need some short of index of packages organized by category... no
idea if something like this exists
2015-04-06 14:56 GMT+02:00 Mike Purvis via ros-users <
ros-users at lists.ros.org>:
> Agree, but I think teleop and muxers in particular are a bit of a special
> case. They're so easy to write, and are a decent learning opportunity, so a
> lot of them get created by novices in the learning process, and then
> unwittingly made available as "universal" or "generic".
>
> If you're integrating a robot and need either of these services, I
> encourage you to check out the ros-teleop org on github
> <https://github.com/ros-teleop>.
>
> Even within the org, there's slight repetition, but the basic idea is that
> joy_teleop and key_teleop are python-implemented and very flexible, able to
> publish *any* message based on configuration from a yaml file, whereas
> teleop_twist_joy is specifically for publishing twist messages, and is C++
> implemented, intended to be able to easily compile into a larger "base
> robot" node.
>
> The twist_mux package does what it says on the tin, and is similarly easy
> to embed into another process.
>
> M.
>
> On 5 April 2015 at 22:48, Daniel Stonier via ros-users <
> ros-users at lists.ros.org> wrote:
>
>>
>> Seems to be rather alot of parallelisation happening these days.
>>
>> I understand that it takes time to collaborate and that natural selection
>> from multiple implementations are also a way of evolving the code available
>> in our robotic community, but I do believe at least some preliminary
>> discussion and collaboration on software that 90% fits can often get you
>> that last 10% much faster than evolving it entirely yourself. It also
>> rounds out an implementation to be more satisfactory for everyone. Another
>> problem everpresent with ROS software is maintenance - n implementations
>> are of no use long term if maintainers can't keep up with all that they try
>> to maintain.
>>
>> I'd like to encourage people to first look to see what is there, see if
>> something is a 90% fit, discuss and then iterate using the usual fork/pull
>> request cycle where possible.
>>
>> Daniel.
>>
>> On 6 April 2015 at 09:27, Jihoon via ros-users <ros-users at lists.ros.org>
>> wrote:
>>
>>> FYI,
>>>
>>> There has also been another twist mux.
>>> http://wiki.ros.org/yocs_cmd_vel_mux
>>>
>>> Cheers,
>>> Jihoon
>>>
>>>
>>>
>>>
>>> On 2015년 04월 06일 09:19, Enrique Fernández Perdomo via ros-users wrote:
>>>
>>> Hello everyone,
>>>
>>> I've recently and finally added some documentation for the twist_mux
>>> package; although it still can be improved. This package allows to
>>> multiplex geometry_msgs::Twist messages.
>>>
>>> http://wiki.ros.org/twist_mux
>>>
>>> Please, don't hesitate to contact me for any doubt or suggestion.
>>> Note that I've recently updated my e-mail as maintainer, and here I'm
>>> using my personal one. Feel free to reach me which any of them.
>>>
>>> Cheers,
>>> Enrique
>>>
>>>
>>>
>> <http://rnd.yujinrobot.com/>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20150507/8836b35c/attachment.html>
More information about the ros-users
mailing list