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@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/>