Glossary

Fictionlab > Glossary > GPIO

GPIO

GPIO – definition

GPIO stands for General-Purpose Input/Output. It is a configurable digital interface provided by a processor, single-board computer, microcontroller, or carrier board. A GPIO line can usually be configured as a digital input or output. Depending on the hardware, it can also expose functions such as interrupts, internal pull-up or pull-down resistors, alternate peripheral modes, and hardware PWM.

In mobile robotics, GPIO is commonly used for low-level integration tasks that do not require a dedicated fieldbus or high-bandwidth interface. Typical examples include reading the status of an emergency-stop circuit, monitoring a limit switch, enabling a motor-controller accessory, triggering a sensor, controlling a relay through a suitable driver circuit, or reading a digital output from an external module.

GPIO is not a universal electrical standard. The voltage level, current capability, connector pinout, software API, and available protections depend on the compute platform. On Raspberry Pi computers, including units commonly used as the embedded compute platform in Leo Rover configurations, GPIO logic levels are 3.3 V. Raspberry Pi documentation states that GPIO pins are not 5 V tolerant. A 5 V signal connected directly to a 3.3 V GPIO input can damage the processor.

GPIO in UGV architecture

On a UGV, GPIO normally complements higher-level communication interfaces such as USB, Ethernet, CAN, UART, or I2C. It is appropriate for discrete signals. It is not intended for transmitting LiDAR scans, camera images, wheel odometry, or other high-rate sensor streams.

A GPIO line can represent a binary state:

logical state = 0  - low voltage level
logical state = 1  - high voltage level

Common mobile-robotics uses include the following:

  • Reading a bumper, reed switch, enclosure switch, or external interlock input.
  • Sending a trigger pulse to a compatible camera, strobe, or data logger.
  • Controlling an opto-isolated relay module through a transistor or dedicated driver.
  • Selecting an operating mode on an external sensor or motor-controller accessory.
  • Capturing pulse edges from a low-rate encoder, provided that timing requirements are compatible with Linux scheduling.

GPIO should not be used as a direct power output for motors, solenoids, lamps, relays, or high-current payloads. These loads require a driver stage. A typical design uses a transistor or MOSFET, a flyback diode for inductive loads, separate load power, and a common reference ground where required by the interface design.

GPIO on Raspberry Pi-based compute units

The GPIO signals on the Raspberry Pi 40-pin header use 3.3 V logic. Raspberry Pi publishes the pinout and electrical guidance for its 40-pin header in its official documentation. Physical header pin numbers are different from BCM GPIO numbers. For example, a software library may identify a line as GPIO17, while the corresponding physical header position is pin 11. Integration documentation must always state which numbering scheme is used.

Parameter Typical Raspberry Pi context Integration consequence
Logic level 3.3 V GPIO Do not connect 5 V digital outputs directly.
Pin numbering BCM line number or physical header pin State the scheme in code and wiring diagrams.
Input state High, low, or undefined when floating Use pull-up or pull-down resistors for stable idle states.
Output load Limited-current logic-level signaling Use an external driver for relays and actuators.

Before wiring GPIO on Leo Rover, verify the specific compute unit, carrier board, exposed connectors, and pin availability in the current Leo Rover documentation. GPIO availability can differ between hardware revisions and installed accessories. A GPIO pin reserved for I2C, SPI, UART, or another peripheral must not be reassigned without checking the platform configuration.

GPIO access in ROS 2

ROS 2 does not define a standard GPIO message type, GPIO driver package, or REP that abstracts all GPIO hardware. GPIO access is normally implemented below ROS 2 through an operating-system API or a board-specific library. A ROS 2 node then publishes the resulting state or exposes a service for output control.

On modern Linux systems, the GPIO character-device interface is commonly used through libgpiod. GPIO chips are exposed as devices such as /dev/gpiochip0. The command-line tools can inspect line availability before a ROS 2 node claims a line.

gpioinfo
gpiodetect

A practical ROS 2 design maps hardware signals to semantically named topics. For example, an input node can publish a debounced interlock-switch state as std_msgs/msg/Bool. An output node can subscribe to a command topic, but it should implement a defined startup state and fail-safe behavior if the ROS graph, power supply, or node process stops.

gpio_status_node:
  ros__parameters:
    chip: "/dev/gpiochip0"
    line_offset: 17
    active_low: true
    debounce_ms: 20
    topic_name: "/external_interlock_input"

The parameter names above are application-defined. They are not part of a ROS 2 standard interface. The GPIO chip number and line offset are platform-dependent and must be verified on the target system; a character-device line offset is not universally equivalent to a Raspberry Pi BCM GPIO number. For a production robot, document the electrical polarity, pull resistor configuration, expected state during startup, and behavior after a process restart.

GPIO limitations for autonomous mobile robots

GPIO is useful for discrete integration, but Linux user-space GPIO timing is not deterministic. Scheduler latency, CPU load, driver behavior, and process scheduling can affect edge handling and output timing. This limitation matters when generating precise pulse trains, reading fast encoders, or implementing safety-critical control.

For deterministic motor control, high-rate encoders, robust distributed I/O, or safety-related functions, use an appropriate dedicated controller or bus interface. A microcontroller, CAN-based I/O module, safety controller, or motor controller can handle time-critical logic independently from the ROS 2 computer. ROS 2 can then exchange higher-level commands and status information.

Leo Rover uses differential drive and supports ROS 2 on supported compute configurations, but GPIO alone does not provide autonomous navigation. Navigation requires the relevant sensor stack, robot state estimation, transforms, costmaps, and a navigation system such as Nav2. GPIO may support peripheral functions within that system, such as an external start signal or sensor trigger.

Raph Rover can accommodate larger payload-oriented integrations. For a larger outdoor UGV, GPIO is still best treated as a local digital interface. Weather exposure, cable length, electromagnetic interference, connector retention, grounding, and voltage conversion must be addressed in the electrical design.

Normative and technical references

The following sources define or document the interfaces most relevant to GPIO integration on ROS-based mobile robots:

See also