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@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 > . > > 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@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 >> 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 >>> >>> >>> >> >> >> _______________________________________________ >> 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 > >