[ros-users] Wiki documentation for twist_mux package

Fri May 8 11:37:52 UTC 2015

My bad; I have been using ROS since electric and I have never heard about
rosindex. And of course I never added tags to any of my packages, and I
guess I'm not the only one.
And without tags, is not easy to recognize the package you want to use, as
all are listed together. Maybe it should be encouraged the use of these
tags, as an extension of the new package tutorial
<http://wiki.ros.org/action/fullsearch/ROS/Tutorials/CreatingPackage?action=fullsearch&context=180&value=linkto%3A%22ROS%2FTutorials%2FCreatingPackage%22>.
To deal with tags semantics, there can be a list of "recommended" tags.
Just an idea....

Btw, Jonathan, congratulations  for your project. Is a cool idea and can be
very helpful if everybody gets to know it.

2015-05-07 22:06 GMT+02:00 Jonathan Bohren <jonathan.bohren at gmail.com>:

> http://rosindex.github.io was a holiday project of mine to try to solve
> some of these issues.
>
> Since early January, I haven't dumped a lot of time into it, but it still
> has a lot of potential. I also haven't regenerated the index for a while
> now. It'd be great if one or more other True Believers wanted to help me
> develop and maintain it!
>
> -j
>
> On Thu, May 7, 2015 at 11:22 AM G.A. vd. Hoorn - 3ME via ros-users <
> ros-users at lists.ros.org> wrote:
>
>> On 07/05/15 17:16, Jorge Santos Simón via ros-users wrote:
>> > 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
>>
>> Isn't that what rosindex [1] is supposed to be? Provided pkgs add
>> correct tags to their manifests [2]?
>>
>> The issue with tagging / category systems is always: who curates / comes
>> up with the tags / categories.
>>
>> What is a 'logical' tag for me isn't necessarily obvious to others, and
>> vice versa.
>>
>>
>> Gijs
>>
>>
>> [1] http://rosindex.github.io/
>> [2] http://rosindex.github.io/contribute/metadata/#metadata-elements
>>
>> >
>> > 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
>> >>
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > 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/20150508/82d7278e/attachment.html>