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

[brice rebsamen]

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 <gerkey at willowgarage.com> 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
> <brice.rebsamen at gmail.com> 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 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
>