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 Advait On Fri, May 27, 2011 at 1:20 PM, Ken Conley 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 > 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 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 >>> 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@code.ros.org >>>> https://code.ros.org/mailman/listinfo/ros-users >>>> >>> >> > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >