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


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