Files, processes, permissions and networking on a robot

A robot's computer is a shared, connected machine that has to keep working without anyone sitting in front of it. Several programs run at once, some of them must start automatically when the robot is switched on, hardware devices must be accessible to the right programs and not to everyone, and you will usually work on the robot from a laptop over Wi-Fi. This lesson covers the Linux skills that make that possible: users, groups and file permissions; processes and signals; services that start at boot; and the networking you need to log in remotely, copy files and let ROS 2 programs on different computers find each other.

Users, groups and permissions

Linux is a multi-user system. Every file belongs to one user and one group, and carries three sets of permissions: for the owner, for members of the group and for everyone else. Each set says whether that class of user may read the file (r), write to it (w) and execute it (x). For a directory, execute means permission to enter it and reach the files inside. The long listing from ls -l shows these as a ten-character string such as -rwxr-xr--: the first character is the file type (a dash for an ordinary file, d for a directory), followed by three groups of three letters, with a dash wherever a permission is missing.

Permissions are also written as a three-digit octal number, one digit per class, where read counts 4, write 2 and execute 1. So rwx is 4 + 2 + 1 = 7, r-x is 5 and r-- is 4. The common mode 755 means the owner may do everything and others may read and execute; 644 means the owner may read and write and others may only read. The chmod command changes permissions, either with numbers (chmod 755 script.py) or with letters (chmod +x script.py adds execute permission for everyone). The chown command changes the owner and needs sudo.

Permissions matter on robots mainly because of hardware. Device files under /dev belong to groups: on Ubuntu, serial ports usually belong to the dialout group, cameras to the video group and some input devices to the input group. If your program cannot open /dev/ttyUSB0 and reports permission denied, the fix is not to run your robot software as the administrator, which would give every bug the power to damage the system. Instead, add your user to the right group with sudo usermod -aG dialout followed by your user name, then log out and back in so the change takes effect.

Device names can also change: two identical USB serial adapters may swap between ttyUSB0 and ttyUSB1 depending on the order in which they were detected. The usual solution is a udev rule, a small text file in /etc/udev/rules.d that matches a device by its vendor, product or serial number and creates a stable symbolic link, such as /dev/robot_base, with the right group and permissions. Robot manufacturers often supply these rules with their drivers.

Processes and signals

Every running program is a process with a numeric process ID. The ps command lists processes, and top or the friendlier htop shows them live with their processor and memory use. A ROS 2 system is usually many processes, one or more for each group of nodes, so htop is a quick way to spot a node that is stuck in a loop or slowly using up memory. You can run a command in the background by ending it with an ampersand, list background jobs with jobs and bring one back with fg.

Processes are stopped by sending them signals. Pressing Ctrl+C in a terminal sends SIGINT, an interrupt request that a well-written program catches so it can shut down cleanly. The kill command sends SIGTERM by default, a polite request to terminate, and kill -9 sends SIGKILL, which the kernel enforces immediately without giving the program any chance to tidy up. On a robot the difference matters: a driver node that catches SIGINT can command its motors to stop and close its serial port, whereas one killed with SIGKILL may leave a motor controller still executing the last velocity command until a watchdog times out. Use kill -9 only when a process refuses to stop otherwise, and design robots so that hardware stops safely even then.

The last row explains a common frustration. If you start a long-running program over a remote session and then your Wi-Fi drops, the session closes and the program receives SIGHUP and usually stops. A terminal multiplexer such as tmux solves this: it runs your shell inside a session on the robot that survives disconnection, so you can reconnect later and find your programs still running. For anything that must always run, use a service instead.

Starting robot software at boot

A robot that only works after someone types commands is not much of a product. Linux systems start background programs, called services or daemons, with systemd. You describe a service in a short unit file that says what to run, as which user, what it depends on and whether to restart it if it fails. The example below starts a ROS 2 launch file when the robot boots, after the network is up.

[Unit]
Description=Robot bringup
After=network-online.target
Wants=network-online.target

[Service]
User=robot
ExecStart=/bin/bash -c 'source /opt/ros/lyrical/setup.bash && source /home/robot/ros2_ws/install/setup.bash && ros2 launch my_robot bringup.launch.py'
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

After saving the file you run sudo systemctl daemon-reload, then sudo systemctl enable --now robot.service to start it now and at every boot. The command systemctl status robot.service shows whether it is running, and journalctl -u robot.service shows its log output, which is where your node's messages go when there is no terminal. Note that the service runs as an ordinary user and sources both the ROS 2 installation and your own workspace, exactly as you would in a terminal; forgetting either is the most common reason a service works by hand but fails at boot.

Networking basics for robots

Robots are networked machines. A mobile robot usually joins a Wi-Fi network, while a robot arm in a lab may use wired Ethernet. Each network interface has an IP address, shown by ip addr; on a typical home or lab network these look like 192.168.1.42. The hostname, shown by the hostname command, is the computer's name, and many networks let you reach a machine as hostname.local without knowing its address. The ping command sends small packets to another machine and reports the round-trip time, which is the first test whenever two computers cannot talk.

You log in to a robot with SSH, the secure shell, by typing ssh followed by the user and host, as in ssh robot@turtle.local. The first time, SSH asks you to confirm the robot's identity; afterwards it warns you if that identity changes, which protects you from connecting to an impostor. Instead of typing a password every time, create a key pair with ssh-keygen and copy the public key to the robot with ssh-copy-id. You can then disable password logins on the robot entirely, which is much safer for a machine that may sit on shared networks. To copy files, use scp for single files or rsync, which only transfers what has changed and is ideal for keeping a workspace on the robot in step with your laptop.

Robots should be treated as network devices that need security like any other. Change default passwords, keep the system updated, do not expose SSH to the open internet, and remember that anyone who can reach a robot's network may be able to send it commands. ROB-360 returns to robot security in depth.

How ROS 2 finds other computers

ROS 2 programs on different computers find each other automatically. By default ROS 2 uses a middleware standard called DDS, and its implementations announce themselves with multicast discovery messages on the local network, so a node on your laptop can see topics published by a node on the robot without any configuration, as long as both machines are on the same network and use the same ROS 2 distribution. From the Kilted release onward, a different middleware called Zenoh is also fully supported; it uses a small router program instead of multicast, which can work better on large or Wi-Fi networks where multicast is unreliable.

Automatic discovery has a downside in shared spaces such as a university lab: every robot and laptop can see every other one. Two settings control this. The environment variable ROS_DOMAIN_ID gives a group of machines its own number, and only nodes with the same domain ID communicate; the ROS 2 documentation recommends values between 0 and 101. The variable ROS_AUTOMATIC_DISCOVERY_RANGE can limit discovery to the local machine (LOCALHOST), the local network (SUBNET) or turn it off. Set them in .bashrc on every machine in your team so that you do not accidentally drive a classmate's robot.

# on the robot and on your laptop
export ROS_DOMAIN_ID=42
# check the machines can reach each other
ping -c 3 turtle.local
# keep this terminal's nodes on this computer only
export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST

Clocks matter too. ROS 2 messages carry timestamps, and programs such as the transform library in lesson 10 compare timestamps from different computers. If the robot's clock is two seconds off the laptop's, data will look stale or come from the future. Install a time synchronization service such as chrony on every machine and check that their clocks agree to within a few milliseconds.

Calculations like this explain many puzzling robot behaviors. A visualization that works perfectly with the laptop plugged into the robot by cable becomes jerky over Wi-Fi; a teleoperation command arrives late because the same link is saturated by camera data. Measuring and budgeting bandwidth is a habit you will practice again in lesson 5.