Chapter 04 · Production C++, Linux, and deterministic timing
Today in the field story
One problem, then the next
The Night-Shift Sensor Gateway reaches Linux and receives permission denied on its simulated serial endpoint. Inspect process identity, device-node owner and group, stable attributes, listener, interface, address, and port before changing anything. Draft the narrow udev rule and semantic name the deployment needs; never replace diagnosis with permanent root execution or a world-writable device.
- Why now
A correct program cannot communicate when operating-system identity and endpoint ownership are wrong.
- Ignore today
Ignore powered sensors and production network exposure; use a spare or simulated endpoint.
- Unlocks next
A least-privilege, repeatable device and network bring-up contract.
Understand
Build the physical picture first
Linux is the building manager between your program and the hardware: it knows which process is asking, which doorway represents the device, what permissions that doorway has, and where network packets must go.
A running program is a process with an identity, open resources, memory, environment, and process ID. Multiple processes may try to use the same serial or camera device, so first discover what is running and who owns the handle instead of restarting randomly. Linux exposes many devices as special files under /dev. Opening /dev/ttyUSB0 is not reading an ordinary text file; it asks a kernel driver to communicate with a device. A failure can therefore come from absence, driver binding, a competing process, permissions, configuration, cabling, power, or the device itself.
Linux checks the user and group of the process against the owner, group, and mode of the device node. Running the whole robot program with sudo may make one permission symptom disappear, but it gives broad power, hides the deployment rule, changes the environment, and can create root-owned files. Prefer the narrow permission the device needs. udev receives kernel device events and matches rules against attributes. A rule can assign an appropriate group and create a stable symlink such as /dev/robot_lidar, avoiding the mistake of assuming the first discovered USB device will always be ttyUSB0.
A network path has layers that must be checked separately. An interface must be up; each machine needs the intended address and subnet or a route; name resolution may map a hostname; a server process must listen on the expected transport and port; firewalls must permit the traffic; and the application protocols must agree. A successful ping only demonstrates one kind of reachability when ICMP is allowed. It does not prove that a TCP server is listening, that UDP multicast crosses the network, that the process has permission, or that request bytes have the expected format.
Bring-up should produce a small evidence chain. Record the exact physical identifier, kernel or udev attributes, stable device path, process user and groups, device-node permissions, process holding the device, interface and address, intended endpoint, and one application-level exchange. Make one change at a time and remove temporary broad permissions. For powered equipment, keep actuators disabled while diagnosing communication and follow the hardware's isolation procedure; finding a device is not permission to move it.
Words you need
Name each idea precisely
- Process
A running program instance with its own identity, resources, address space, and process ID.
Physical example:A driver process holds a serial device open while a separate monitoring process reads its published health.
- Device node
A special file, usually under
/dev, through which a process communicates with a kernel-managed device.Physical example:/dev/ttyUSB0can represent a USB-to-serial adapter, not a stored file of bytes.- udev rule
A rule matched against device-event attributes that can set metadata, permissions, or stable symlinks.
Physical example:A vendor-and-serial-specific rule creates
/dev/robot_encoderfor the intended adapter.- Network interface
A software-visible connection point, such as Ethernet, Wi-Fi, or loopback, that carries network traffic.
Physical example:The robot's Ethernet interface has a static address on the control subnet.
- Port
A transport-level number used with an address and protocol to direct traffic to a listening application.
Physical example:A telemetry server listens on one TCP port while discovery may use a separate UDP multicast flow.
Math, one line at a time
Work through today’s relationship
Prerequisite rescue · optionalRates, deadlines, jitter, and memory budgets
Hardware-facing software must finish work predictably before its deadline.
- f
- loop frequencyUnit: hertz (Hz)
- T = 1/f
- time available for one loopUnit: seconds (s)
- jitter
- variation around the expected timingUnit: milliseconds (ms)
For a 100 Hz control loop, T = 1/100 s.
Convert: 0.01 s = 10 ms per cycle.
If work sometimes takes 13 ms, it misses the 10 ms deadline by 3 ms; measure the distribution, not only the average.
This is a strict rendering or audio-processing budget, except a missed robot deadline can destabilize an actuator.
How much time does a 50 Hz loop have per cycle?
1/50 s = 0.02 s = 20 ms.
A sensor has period
For lost pings out of ,
Diagnose a serial sensor that says permission denied
The device exists at /dev/ttyUSB0; the application works under sudo but fails as the normal robot-service user.
Keep actuators disabled and record the exact error, service identity, device path, and connection state.
Inspect device ownership and mode, then list the service user's group membership instead of changing permissions immediately.
Inspect udev attributes that uniquely identify the intended adapter, including vendor, product, and serial where available.
Draft a narrow rule that assigns the intended access group and creates
/dev/robot_sensor; avoid world-writable mode.Reload and trigger rules or reconnect the unpowered test device, then verify the symlink and permissions.
Run as the real service identity, prove one valid application-level read, and verify a wrong user remains denied.
The deployed identity accesses only the intended device through a stable name without broad root privileges.
A permission fix is complete only when identity, device matching, least privilege, and the actual protocol exchange are all verified.
Physical examples
Where this appears in real life
Two identical USB adapters swap order
After a reboot, the lidar adapter appears second and receives ttyUSB1, while software still opens ttyUSB0 and talks to another board.
Match stable physical attributes and create a meaningful symlink instead of encoding discovery order.
Reachable robot, closed application door
The robot answers ping, but the telemetry client times out because the service listens only on loopback or on a different port.
Interface reachability and application reachability are different claims that need different evidence.
Hands-on exercise
Make the idea observable
Use a spare unpowered USB serial adapter, or simulate the investigation with an ordinary file and a documented mock attribute list; do not loosen global machine permissions.
Record the current user, groups, process list, and the chosen path's owner, group, and mode.
If a real spare device is present, inspect its udev properties; otherwise write the vendor, product, and serial fields your rule would require.
Draft a rule that creates a semantic symlink and assigns a specific access group, but do not install it machine-wide for the simulation.
Draw the network path from robot process through interface, address, transport, port, and client process.
For a loopback-only toy server, verify separately that the process is listening and that one application request receives the expected reply.
Write a symptom table for missing device, permission denied, busy device, no route, connection refused, timeout, and bad application response.
Similar user-visible failures occur at different layers, while each inspection answers only one bounded question.
Your evidence identifies the process identity, stable device rule, least-privilege decision, network endpoint, and one application-level success without using a world-writable device or permanent root execution.
Build today
Create a Linux C++ sensor→filter→controller pipeline with device permissions, bounded timing, tests, CI, structured logs, and deterministic replay.
Evidence to save
DONE when the integrated “Linux processes, device permissions, udev, and robot networking” path is observable, cancelable, and leaves the prior baseline reproducible.
Common mistakes
Catch the wrong mental model
Making the device world-writable or running every node as root.
Match the intended device precisely and grant a dedicated service identity only the required group or rule-based access.
Hard-coding /dev/ttyUSB0 as the physical sensor identity.
Discovery order can change; use stable attributes and a semantic udev symlink for the intended device.
Treating a successful ping as proof that the robotics application communicates.
Also verify interface binding, transport, port, firewall, listener, protocol compatibility, and one valid application exchange.
Job connection
How this becomes employable evidence
Commission a USB sensor and an edge-to-fleet network service using stable naming, least privilege, layer-by-layer diagnostics, and a repeatable bring-up record.
Relevant target roles
- Robotics Application / ROS 2 Integration Engineer
- Robotics Deployment, Integration & Validation Engineer
- Robotics Software Engineer — ROS 2 / AMR
- Robot Fleet Backend / Platform Engineer
Chapter 04 interview drill
Interview questions: Linux processes, device permissions, udev, and robot networking
Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.
Primary interview scenario
A sensor works with sudo and the robot responds to ping, but the deployed service gets no data. Give an evidence-first diagnosis that separates identity, device ownership, competing processes, interface, port, and protocol.
Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.
Technical follow-up questions
Q1Why can a program work under sudo yet still be incorrectly deployed?
Root bypasses the intended least-privilege identity and may hide a missing group or udev rule while changing environment and file ownership.
Q2What makes `/dev/robot_lidar` safer than assuming `/dev/ttyUSB0`?
A correctly written udev rule can tie the semantic name to stable device attributes instead of changeable discovery order.
Q3What does connection refused usually tell you that a timeout does not?
It usually indicates the destination was reached but no service accepted that endpoint, while a timeout may occur earlier or be caused by filtering, routing, loss, or a silent application.