
Welcome to this detailed walk-through where we'll be exploring the process of interfacing a Logitech F310 Wired Gamepad Controller with ROS Melodic, using a Thinkpad T530 running on Ubuntu 18.04 and ROS Melodic. While this guide isn't specific to the Thinkpad T530, I'd like to clarify that your system's accelerometer might affect the representation of joystick devices.
Let's understand the basic principle first: when you plug in a joystick to your system, the operating system recognizes it via device drivers - software that mediates the interaction between your system and hardware devices. In the case of ROS, the `joy` package interfaces with these drivers to access joystick data.
The Basics: ROS and the 'joy' Library
The Robot Operating System (ROS) is a toolbox of sorts for software developers, offering an array of libraries and tools to assist in creating robot applications. When it comes to game controllers like the Logitech F310, a commonly utilized library is `joy`. This specific ROS library interfaces with the joystick drivers of the host operating system and transforms raw joystick data into standard ROS messages.
Before starting the interfacing process, you need to have the `ros-joy` package installed. This can be done with the following command:
sudo apt-get install ros-melodic-joy
Step-by-Step Guide
1. Controller Setup
Begin by plugging the Logitech F310 controller into an available USB port on your Thinkpad T530. To ensure your system recognizes the controller, use the command:
ls /dev/input/
This command lists all devices in the `/dev/input/` directory of your Linux system. Linux treats everything - including hardware devices - as files or directories. Therefore, they are depicted as special files in the `/dev/` directory. In this context, the `/dev/input/` directory holds files symbolizing input devices such as keyboards, mice, and joysticks.
The output will display something akin to `js0` or `js1`, which represents the joystick devices. Bear in mind, if your system has an accelerometer, it might sometimes be identified as a joystick device.
2. Testing the Joystick
Before incorporating the joystick with ROS, it's crucial to ensure its functionality. This can be done with the `jstest` command:
jstest /dev/input/js0
Now, interact with your controller by pressing buttons or moving sticks; if the joystick is working, you will notice the output values changing in response. This test uses the `jstest` utility, a component of the `joystick` package in Ubuntu, which lets you examine joystick inputs directly in the console. `/dev/input/js0` denotes the device file representing the first joystick connected to your system.
3. Running the ROS Joystick Node
Now that we've verified our joystick's functioning, we can move onto using ROS to read the joystick inputs. We'll employ the `joy` package for this purpose, which acts as a liaison between joystick devices and ROS, converting inputs into ROS messages.
Kick-start the process by launching the ROS master server with the `roscore` command in a new terminal:
roscore
The `roscore` command starts the ROS master server - an essential component of any ROS system, acting as a central registry for ROS nodes to discover each other and communicate effectively.
Next, in a separate terminal, run the `joy_node` in the `joy` package:
rosrun joy joy_node
`rosrun` is a command to initiate a node from a given package. The `joy_node` publishes joystick messages on the `joy` topic.
4. Viewing Joystick Messages
You can inspect the messages being published on the `joy` topic using the `rostopic` command:
rostopic echo joy
The `rostopic` command is a handy ROS command-line tool used to fetch information about ROS topics. As you interact with the controller, you should see messages being printed to the terminal. These messages encapsulate all the data from the joystick, including the state of each button and axis.
Note: If you encounter permission errors when trying to access the joystick, add your user to the `input` group using the following command:
sudo usermod -a -G input $USER
The `sudo` command enables the execution of the following command with superuser (root) privileges. The `usermod` command is used to alter user account settings. After running this command, you should logout and log back in for the changes to take effect.
Congratulations! Now, you should be able to read inputs from the Logitech F310 Wired Gamepad Controller using ROS. These inputs can be utilized to operate your ROV or other robotic systems. Keep in mind that the ROS `joy` package provides a standard ROS message interface, meaning you can use these messages in the same manner as you would use any other ROS messages.
5. General Information
Now, I'm new to ROS, and it took me a while to have some concepts settle in into my head, if that's the case with you, the following section is for you:
roscore/master:
`roscore` is essentially the backbone of any ROS-based system. When you execute the `roscore` command, you start up the ROS Master, which provides naming and registration services to the rest of the nodes in the system. It tracks publishers and subscribers to topics as well as services. The role of the ROS Master is to enable individual ROS nodes to locate one another. Once these nodes have located each other via the ROS Master, they communicate with each other peer-to-peer.
To illustrate this with an analogy, imagine the ROS system as a city where different nodes are buildings. Each building (node) offers unique services and communicates with other buildings. The ROS Master works like the city's information center or Maps rather, guiding the buildings to locate one another and exchange information effectively.
Just as you would refer to a GPS service or city guide to find the best pizza place in a city you're not familiar with, ROS nodes refer to the ROS Master to determine who they should communicate with. After finding each other through the ROS Master, the nodes can share information directly - similar to you directly going to the pizza place once you know its location.
In the case of publishers and subscribers, think of a publisher as a radio station broadcasting on a specific frequency (the topic). Any radio (subscriber) tuned to that frequency (subscribed to that topic) can receive the broadcast (messages). The ROS Master's job is akin to a radio directory service, enabling radios and stations to find out about each other.
It's important to remember that `roscore` should always be running during a ROS session. Without it, nodes wouldn't be able to locate each other or communicate. Therefore, it's typically the first command you run when starting a ROS session.
`joy` as Package and Topic:
Yes, it can be confusing that `joy` is both the name of a package and a topic. This is an example of a ROS convention.
Package: In ROS, a package can be seen as a project or a workspace containing nodes, libraries, and more. In this context, `joy` is a package that provides joy_node - a node that reads from a joystick device and publishes sensor_msgs/Joy messages.
Topic: A topic is a named bus over which nodes exchange messages. In our scenario, `joy` is also a topic on which joystick data (as sensor_msgs/Joy messages) is published.
Keep in mind that despite having the same name, they are entirely different entities in ROS architecture. The `joy` package is the software that reads the joystick inputs and publishes them, while the `joy` topic is the channel over which the data is communicated to other nodes.
Device Drivers and ROS Messages:
Device drivers allow your operating system to interact with hardware peripherals, like the Logitech F310 controller. It communicates with the device and provides an interface for the operating system to use. In our case, we are not dealing directly with the driver, but through a ROS Node (`joy_node`) that communicates with it.
The data the driver collects from the joystick is translated into ROS messages. Each message has a predefined structure dictated by its message type. The `sensor_msgs/Joy` message, for example, is composed of the current state of all buttons and axes on the joystick. ROS messages are the standard method for different nodes to exchange data, whether that data is joystick input, sensor data, actuator commands, or anything else.
These messages are then published on the `joy` topic. Any node in the ROS network that needs joystick data can simply subscribe to the `joy` topic and use that data for its purposes.
This mechanism allows for a decoupled system where hardware interfacing is abstracted away from the logic of your robotic application. This way, whether you're controlling a robotic arm, a rover, or a drone, the joystick control logic stays the same; all you have to change is how the subscribed data is utilized.
Hope you've managed to successfully interface your controller, and also learnt something new along the way. Constructive criticism and correction of typos is always welcomed, and if you run into any issues, know that you're not alone, I'm around to help. Just let me know!
Comments