Thanks for the reply > The teleop requirements for different robots tend to be a little > different, so there isn't a unified teleop node (either joystick or > keyboard) for all robots. Usually what happens is what you're doing: > take the most similar teleop node you can find and adapt it to your > circumstances. If someone were to take the time to develop > sufficiently parameterizable teleop nodes (probably one for joystick > and one for keyboard), it would be a great service to the community. Then a good starting point would be to start a list of requirements. At least for differential wheels robots, there surely aren't that many differences... > This behavior is not ideal, but then, keyboard teleop isn't ideal. Agree, but it's very convenient: we usually follow the robot with a laptop connect via ethernet to debug and monitor. We don't want to be carrying a joystick as well... Brice On Thu, May 26, 2011 at 5:23 AM, Brian Gerkey wrote: > hi Brice, > > The teleop requirements for different robots tend to be a little > different, so there isn't a unified teleop node (either joystick or > keyboard) for all robots.  Usually what happens is what you're doing: > take the most similar teleop node you can find and adapt it to your > circumstances.  If someone were to take the time to develop > sufficiently parameterizable teleop nodes (probably one for joystick > and one for keyboard), it would be a great service to the community. > > As to sending zero velocity, you want to do this in two places: > > (1) In the driver (the node that's talking to the motors), there > should be a watchdog that will halt (or limp, as appropriate) the > motors if a fresh command hasn't been received within a certain period > of time (depends on the robot, but often a couple 100s of ms). > (2) In the teleop node, there should be a watchdog that sends zero > velocities if there hasn't been fresh input from the user within a > certain period of time. > > The watchdog in (1) is essential, regardless of whether you want to > teleop the robot.  You need to know that the robot will stop if nobody > has very recently told it to go. > > The watchdog in (2) is also important, but less so than (1).  Btw, you > can figure out when to send zero velocities from a console-based > program without Xlib by noticing that it's been a while since you > received a new character.  The downside of this approach is an initial > stutter when holding down a key: the first keypress generates one > character, which gets the robot moving; then there's a delay, during > which the robot stops; then the keyboard's repeat mode engages and you > get a stream of characters, which gets the robot moving continuously. > This behavior is not ideal, but then, keyboard teleop isn't ideal. > >        brian. > > > On Tue, May 24, 2011 at 9:44 PM, brice rebsamen > wrote: >> I am looking for a way to remote control my robot >> - for quick testing of the base control drivers >> - for data collection >> - to return the robot to the storage area without having to carry it >> - etc. >> >> The only code I could find was the teleop_turtle_key.cpp. I adapted it >> to my robot (i.e. changed a few names, and converted from >> turtle::Velocity msg to geometry_msgs::Twist) and it works. However, >> it has a problem: there is no way to set the velocity to 0 (I could >> introduce an extra key to stop though). This is due to the nature of >> the code: it does not handle key press and key release events. This >> also means that it cannot move and turn at the same time. >> >> I have written a code to do that. It relies on Xlib. It opens a small >> X window and get the key events from there. It works fine. I could >> port it to ROS and make it available. >> >> But I wanted to know what was already there. I cannot believe nobody >> has done this before. >> >> Regards >> Brice >> _______________________________________________ >> 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 >