Easy wireless control for your homemade robot!

Controlling a homemade robot can be an incredibly rewarding experience, yet navigating with a keyboard often feels clunky and imprecise. The limitations of coarse control, being tethered to your development machine, and the need to keep a terminal window open quickly detract from the joy of remote operation. Fortunately, there’s a much more intuitive and comfortable solution: leveraging gamepads for advanced wireless robot control through ROS 2.

This article builds upon the foundational concepts introduced in the video above, diving deeper into how you can transform your robot control experience. We’ll explore the nuances of teleoperation, detail the process of integrating various gamepads with ROS 2, and discuss effective strategies for receiving crucial feedback from your robotic companion.

Understanding Teleoperation: Bridging Distances in Robotics

At its core, teleoperation means “distant operation” or remote control. Think of it like television (distant vision) or telephone (distant voice), but for controlling physical objects from afar. This method stands in stark contrast to autonomous operation, where a robot executes tasks independently after receiving initial instructions.

While the ultimate goal for many robotics projects is autonomy, human control remains indispensable, especially during development, testing, and in scenarios requiring precise human intervention. A robust teleoperation system typically involves two key components: sending command signals (like velocity instructions) to the robot and receiving real-time feedback from it.

The Case for Gamepads in Robot Control

The keyboard-based ‘Teleop Twist Keyboard’ might serve as a basic starting point, but its practical limitations quickly become apparent. Gamepads, however, are purpose-built for directing virtual objects in motion, making them a natural fit for controlling physical robots. Their ergonomic design, multiple buttons, and analog axes offer a significantly more comfortable and nuanced control experience.

Most gamepads fall into three main categories, each with distinct advantages. Wired gamepads via USB offer reliable, low-latency connections without worrying about battery life. Wireless gamepads with a USB dongle provide freedom of movement while generally maintaining good performance, often operating on dedicated frequencies for minimal interference. Lastly, Bluetooth wireless gamepads offer broad compatibility with modern devices and fewer physical connections, though they can sometimes introduce slightly more latency or connectivity quirks depending on the environment.

When choosing a gamepad, personal preference plays a significant role. Some users prefer the symmetrical stick layout of PlayStation-style controllers, while others find Xbox-style controllers with their offset sticks more comfortable for extended use. The key is to select one that feels natural in your hands and offers sufficient buttons and axes for your robot’s intended functions. For instance, a basic controller that “works out of the box with ROS” can be an excellent starting point for beginners, even if it lacks premium features.

Connecting Your Gamepad to ROS 2 on Linux

The process of setting up a gamepad for robot control in ROS 2 begins with ensuring your Linux system recognizes the device. While Windows has a long history of gaming-focused peripheral support, Linux offers solid, continuously improving support for joysticks and gamepads, partly thanks to initiatives like Valve’s efforts in PC gaming.

Before integrating with ROS, it’s crucial to verify Linux detection. Tools like `evtest` provide a low-level view of input events, showing raw data as you press buttons and move axes. For example, running `evtest` and selecting your device (often identified by a number like ’19’) will display real-time input. This direct feedback confirms that your operating system can indeed “see” your gamepad.

For a more visual confirmation, `jstest` and `jstest-gtk` offer graphical interfaces to test joystick functionality. While these tools might utilize older Linux joystick drivers, they still provide an excellent visual representation of axis movements and button presses. Installing these utilities is straightforward via your system’s package manager, typically using a command like `sudo apt install joystick jstest-gtk evtest`.

The ROS 2 `joy` Package: Translating Input to Data

Once Linux recognizes your gamepad, the next step is to get this input into ROS 2. The standard method involves the `joy` package, which provides a node designed to interface with Linux joystick drivers. This node, often named `joy_node`, publishes a stream of data on a topic, typically `/joy`, of type `sensor_msgs/Joy`.

The `sensor_msgs/Joy` message essentially contains two arrays: one for button states (booleans) and one for axis values (floats). For instance, if you move a thumbstick, its corresponding axis value in the message will change from -1 to 1. This standardized message format allows other ROS nodes to easily subscribe to the `/joy` topic and interpret the gamepad input.

To identify your gamepad’s device ID and test the `joy_node`, you can use commands like `ros2 run joy joy_enumerate_devices` and `ros2 run joy joy_node`. Once the node is running, echoing the `/joy` topic (`ros2 topic echo /joy`) provides a raw data stream. However, for a more user-friendly interface to determine specific button and axis indices, custom tools like the `joy_tester` mentioned in the video can be invaluable. This helps you quickly map physical controls (e.g., left thumbstick, left bumper) to their corresponding digital indices (e.g., axis 0, axis 1, button 6).

Mapping Gamepad Input to Robot Motion with `teleop_twist_joy`

The raw joystick data from the `/joy` topic needs to be translated into commands your robot understands. For mobile robots, this typically involves a `geometry_msgs/Twist` message, which specifies linear and angular velocities. This is where the `teleop_twist_joy` node comes into play. This powerful ROS 2 package takes the `sensor_msgs/Joy` messages and converts them into `geometry_msgs/Twist` messages, publishing them on a topic like `/cmd_vel`.

Configuring `teleop_twist_joy` involves setting numerous parameters, making launch files and YAML parameter files indispensable. Instead of typing lengthy commands, you can define all settings within a `joystick.yaml` file, which is then loaded by your `joystick.launch.py` launch file. This approach centralizes your configuration, making it easy to manage and adjust.

Key Parameters for Fine-Tuned Control

Within your `joystick.yaml` file, you’ll define parameters under the `teleop_node` section (assuming you’ve explicitly named it as such in your launch file). Here’s a breakdown of crucial settings:

• axis_linear.x and axis_angular.z: These parameters map specific gamepad axes to the robot’s linear X velocity (forward/backward) and angular Z velocity (rotation). For example, setting axis_linear.x: 1 means your robot’s forward/backward motion is controlled by axis 1 of your gamepad’s thumbstick.

• scale_linear.x and scale_angular.z: These values determine the maximum linear and angular speeds when the corresponding axis is pushed to its limit in “regular” mode. The video highlights setting scale_linear.x: 0.5 (0.5 meters per second) and scale_angular.z: 0.5 (0.5 radians per second). These are crucial for safe initial operation and can be adjusted based on your robot’s capabilities and environment.

• scale_linear_turbo.x and scale_angular_turbo.z: For situations requiring faster movement, `teleop_twist_joy` supports a “turbo” mode. Setting these, for example, to 1.0 meter per second and 1.0 radian per second, allows for quick bursts of speed when a dedicated “turbo” button is held. This dual-speed functionality offers both precise fine control and rapid traversal.

• enable_button and enable_turbo_button: These parameters assign specific gamepad buttons to activate regular and turbo control modes. For example, if your left bumper is button 6 and your right bumper is button 7, you would map them accordingly (e.g., enable_button: 6, enable_turbo_button: 7). Holding these buttons enables the respective speed settings.

• require_enable_button: This parameter, typically set to true, implements a “dead man switch.” This critical safety feature ensures that the robot will immediately stop if you release the enable or turbo button. It prevents unintended movements should the controller be dropped or an axis accidentally bumped, significantly enhancing operational safety. While enabled by default, explicitly setting it to `true` reinforces this safety measure.

• deadzone: This parameter, often set around `0.05`, defines a small range around the center of an analog stick where no input is registered. This prevents slight jitters or resting positions of the thumbsticks from causing unwanted robot movement, particularly useful with older or cheaper controllers that might not perfectly return to center.

• auto_repeat_rate: This parameter (defaulting to 20 milliseconds) controls how quickly button press messages are repeated if held down. While less critical for continuous axis control, it can be relevant for discrete button-triggered actions.

By carefully configuring these parameters, you can create a highly responsive and safe control scheme for your homemade robot. Once configured, a simple `colcon build` and `ros2 launch articubot_one joystick.launch.py` (or your specific launch file) will bring your custom gamepad control to life.

Receiving Feedback: The Other Half of Teleoperation

Effective teleoperation isn’t just about sending commands; it’s equally about receiving clear, timely feedback from your robot. Without knowing what your robot “sees” or where it is, remote control quickly becomes a guessing game, potentially leading to mishaps like driving off a table.

RVis, the powerful ROS visualization tool, is an excellent starting point for visual feedback. It can display various data streams simultaneously, providing a comprehensive overview of your robot’s status and environment.

• Odometry Data: RVis can visualize the robot’s estimated position and orientation based on odometry data. This allows you to track its movement on a virtual plane, guiding it forward, backward, or through turns. However, odometry is prone to drift, meaning its accuracy degrades over time without additional context.

• Camera Feeds: The most natural feedback for human operators is often a live video stream. By adding an image display in RVis and subscribing to your robot’s camera topic (e.g., `/image_raw`), you gain a “robot’s eye view.” It’s important to note that earlier ROS 2 versions, like Foxy, might not natively support compressed images in RVis, leading to choppy or delayed video. In such cases, external tools like RQT Image View, which can handle compressed streams, provide a much smoother and more responsive experience. Optimizing camera frame rates and being aware of Wi-Fi interference (especially in signal-dense environments) are crucial for reliable video streaming.

• Lidar Data: Lidar (Light Detection and Ranging) provides detailed depth information, creating a point cloud map of the robot’s surroundings. Visualizing lidar data in RVis allows you to detect walls, obstacles, and even identify objects or people in front of the robot. While not providing visual context like a camera, lidar is excellent for navigation and obstacle avoidance. Adjusting Quality of Service (QoS) policies in RVis (e.g., changing to “best effort” and depth to “1”) can sometimes improve the reception of lidar messages, especially over less stable network connections.

While RVis is a robust tool, other solutions are emerging to enhance teleoperation feedback. Upcoming advancements include specialized tools for phone or tablet control, which can offer integrated camera feeds and simplified interfaces, and platforms like Foxglove, designed for advanced data visualization and debugging in robotics. These tools promise to make teleoperation even more accessible and powerful for robot builders.

As you continue your robotics journey, mastering teleoperation with gamepads and reliable feedback systems lays a vital foundation. The ability to precisely control your robot and understand its environment remotely is not just for fun; it’s a critical skill that bridges the gap between basic movement and complex autonomous behaviors like SLAM (Simultaneous Localization and Mapping) and navigation with Nav2. Future developments will delve into advanced algorithms, allowing your robot to perceive its world and chase moving targets using its camera as a primary input.

Untethered Control for Your Homemade Robot: Q&A

What is teleoperation in robotics?

Teleoperation means controlling a robot remotely, like using a remote control for a toy car. It’s especially useful for testing homemade robots or when precise human guidance is needed.

Why should I use a gamepad instead of a keyboard to control my robot?

Gamepads offer more comfortable, precise, and nuanced control compared to a keyboard. Their ergonomic design and analog sticks make directing a robot feel more natural and responsive.

How do I get my Linux system to recognize my gamepad for ROS 2?

First, ensure your Linux system detects the gamepad using tools like `evtest` or `jstest-gtk`. These tools confirm your operating system can ‘see’ the device before integrating it with ROS 2.

What does the `teleop_twist_joy` package do in ROS 2?

The `teleop_twist_joy` package translates your gamepad’s button presses and joystick movements into commands your robot understands, like how fast to move or turn. It converts raw gamepad data into standard robot velocity messages.

Why is it important to get feedback from my robot when controlling it remotely?

Feedback is crucial because it lets you know what your robot ‘sees’ and where it is in its environment. This prevents accidents and helps you guide the robot effectively without just guessing.