[ros-users] remote control (kbd / joystick / etc.) (brice rebsamen)

[Ken Conley]

On Fri, May 27, 2011 at 10:45 AM, Advait Jain <advait at cc.gatech.edu> wrote:
> Hi Ken,
>
> I can see these top-level wiki pages being really useful.
>
> How does one decide that a particular subject has the critical mass to
> warrant a top-level page?
>
> For example, I can imagine a page on actuators (similar to what I
> Heart Robotics and others have done for Sensors).
>
> This could include ROS packages to control servos, pan tilt units etc., such as
> http://www.ros.org/wiki/ptu46
> http://www.ros.org/wiki/amtec
> http://www.ros.org/wiki/robotis
> http://www.ros.org/wiki/ax12_controller_core

The Sensors page is a result of I Heart Robotics proposing,
championing, and putting it together.  If you're willing to do the
same for Actuators, it would be a fantastic contribution.

Would you include stock manipulators as well?  Right now manipulators
are indexed on the Robots page, but there may be better overlap with
actuators (e.g. crustcrawler).

 - Ken


>
> Advait
>
>
> On Fri, May 27, 2011 at 1:20 PM, Ken Conley <kwc at willowgarage.com> wrote:
>> Hi Chad,
>>
>> These are good points.  I encourage you to look as several of the new
>> top-level pages the community has added to the wiki in the past year
>> and suggest specific ways/areas they could be improved further.  These
>> pages include:
>>
>> Library/functionalities:
>> http://www.ros.org/wiki/APIs
>>
>> Sensors:
>> http://www.ros.org/wiki/Sensors
>>
>> Robot-specific landing pages:
>> http://www.ros.org/wiki/Robots
>>
>> Tools:
>> http://www.ros.org/wiki/Tools
>>
>> It's really the robot-specific landing pages I'm most excited about
>> and think the community can contribute the most to.  I'm hoping that
>> the pages like:
>>
>> http://www.ros.org/wiki/Robots/NXT
>>
>> will be a place where NXT users can start answering more specific "how
>> do I do X with my robot" questions.
>>
>> One of the reasons we are focused on TurtleBot is it is simply too
>> difficult to provide a generic "here are cool libraries" without
>> understanding what hardware the person is using, i.e. "navigation" has
>> a very different meaning if I have a Create, AscTec quadrotor, or
>> autonomous car.
>>
>> cheers,
>> Ken
>>
>>
>> On Thu, May 26, 2011 at 12:41 PM, Jenkins, Odest Chadwicke
>> <odest_jenkins at brown.edu> wrote:
>>> Hi Ken,
>>>
>>> I think you make a very good point about developing a teleop_mobile
>>> stack.  That would certainly be a welcomed contribution.  I also agree
>>> that asking Willow to take this on is not the best use of time and
>>> effort.
>>>
>>> A larger point I am making is that we are starting to see more
>>> reinvention and refragmentation among the efforts of the ROS
>>> community.  I would attribute this circumstance to the lack of a
>>> global picture of ROS that people (new and established) in ROS can
>>> understand.  We often have to climb up the learning curve by scouring
>>> the more detail-oriented content of the wiki and various repositories.
>>>  This could be a dealbreaker for many types of people we would like to
>>> bring into the ROS community: app-level developers, people who design
>>> systems with usability and value in mind, etc.
>>>
>>> I think the answer to Brice's question (and similar questions) should
>>> be more obvious.  By an order of magnitude, ROS has been a great
>>> contribution to robotics, as an applications-layer protocol, message
>>> structure, and development environment.  However, ROS is still very
>>> far from enabling robots to provide value for real users and app
>>> developers.  More guidance from the ROS leadership as well as
>>> discussion with the current ROS community would help in broadening the
>>> ROS community in the future.
>>>
>>> (Brice, apologies for the threadjacking)
>>>
>>> -Chad
>>>
>>> On Thu, May 26, 2011 at 4:31 PM, Ken Conley <kwc at willowgarage.com> wrote:
>>>> If someone was willing to coordinate/maintain a "teleop_mobile" stack,
>>>> we would happily accept/anoint it.  As Brian notes, the difficulty is
>>>> in ensuring that such a 'general' teleoperation package generically
>>>> controls a variety of robots.  We would not be able to do such a stack
>>>> ourselves (at least for Electric) as our post-ICRA todo list is a bit
>>>> too much right now.
>>>>
>>>> It sounds like there are (at least) two good starting points for
>>>> packages to include.  For keyboard, the stack that Chad mentions:
>>>>
>>>> http://www.ros.org/wiki/teleop_twist_keyboard
>>>>
>>>> And for joystick, we have our teleoperation package we use with the TurtleBot:
>>>>
>>>> http://www.ros.org/wiki/turtlebot_teleop
>>>>
>>>> The joystick case is a bit more difficult as you also have to
>>>> parameterize a bit on the joystick.
>>>>
>>>> Our expectation for a maintainer would be to coordinate the community
>>>> to get good documentation in place, and also coordinate with the
>>>> community to test across multiple robot bases.
>>>>
>>>>  - Ken
>>>>
>>>> On Thu, May 26, 2011 at 9:17 AM, Jenkins, Odest Chadwicke
>>>> <odest_jenkins at brown.edu> wrote:
>>>>> Hi Brice,
>>>>>
>>>>> I believe you are correct in that base movement control has been
>>>>> reinvented several times over in ROS.  We wrote our own a while back,
>>>>> but there are probably other quality movement controllers across the
>>>>> ROS space:
>>>>>
>>>>>  http://www.ros.org/wiki/teleop_twist_keyboard
>>>>>
>>>>> teleop_twist_keyboard was based on the old playerjoy utility from
>>>>> Player, which includes a stop command and has limited handling of key
>>>>> press/release events.  We often use teleop_twist_keyboard for the
>>>>> Create, AR.Drone, and PR2 (as in the following video):
>>>>>
>>>>>  http://www.youtube.com/watch?v=M-9sDNnGtIs
>>>>>
>>>>> I think your post is great reminder that the ROS community could
>>>>> benefit from a clearer organization of packages, messages, and
>>>>> functionality in ROS.  Such a clear organization does not seem likely
>>>>> to happen organically without some guidance from the ROS leadership.
>>>>>
>>>>> -Chad
>>>>> _______________________________________________
>>>>> ros-users mailing list
>>>>> ros-users at code.ros.org
>>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>>
>>>>
>>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>