Raspberry Pi

What it is

The Raspberry Pi is a full computer the size of a credit card. Where an Arduino Uno is a microcontroller that runs one program forever, a Pi runs Linux—so it can drive a camera, talk to the network, run ROS 2, and execute your robot code all at once. It is the brain you reach for when a robot needs to think, not just react.

That power is also its trade-off: Linux multitasking makes the Pi worse at the microsecond-precise timing a microcontroller does effortlessly. The two are partners, not rivals.

How it works

The Pi boots an operating system (usually Raspberry Pi OS) from a microSD card, then behaves like any Linux machine. For robotics, the important part is the 40-pin GPIO header: digital inputs and outputs, plus I²C, SPI, and UART buses, that let the Pi read sensors and command hardware. On top of that sit the computer parts—USB, Ethernet, Wi-Fi, and a camera interface—that a microcontroller simply doesn’t have.

A common architecture is a two-brain robot: the Pi handles perception and planning (vision, SLAM, ROS nodes) and hands motor commands down to an Arduino that does the real-time control.

When to use it

Reach for a Pi when the robot needs a computer’s abilities:

• Computer vision — a camera plus OpenCV for detecting markers, objects, or lines.
• ROS 2 — running nodes, topics, and the navigation stack.
• Mapping / SLAM — building and localising in a map.
• Networking — a web dashboard, remote control, or telemetry.

Stick with an Arduino or ESP32 for pure real-time control jobs—they’re cheaper, simpler, and better at precise timing.

Wiring and gotchas

• 3.3 V logic, and not 5 V-tolerant. Feeding a GPIO pin 5 V can damage the Pi. Level-shift signals from 5 V parts (e.g. an HC-05 TX line).
• It still can’t power motors. GPIO drives signals; motor current goes through a driver like the L298N.
• Power is fussy. Give it a stable 5 V at enough current; brown-outs corrupt the SD card and cause random reboots.
• Shut it down cleanly. Yanking power from a running Linux system can corrupt the card—design a safe power-down or use a read-only filesystem.

The 40-pin header, and which pins you can use

The header is 40 pins and only 26 of them are usable GPIO. The rest are power and ground.

Two of those rows regularly cost people an evening.

The UART is the console. Out of the box, GPIO 14/15 carry a Linux login prompt. Wire a GPS module or an Arduino to them and you get login noise instead of data. Free them with sudo raspi-config → Interface Options → Serial Port → login shell: no, hardware serial: yes. On a Pi 3 and later there is a further wrinkle: the good UART is used by Bluetooth by default, and the one on the header is a lesser “mini UART” whose baud rate drifts with the CPU clock. Add dtoverlay=disable-bt to /boot/config.txt to swap them.

Software PWM jitters. Only four pins have hardware PWM. Everything else is generated by the kernel, and the Linux scheduler will interrupt it — which on a servo shows as visible twitching. This is the clearest illustration of what a Pi is bad at.

The timing problem, stated plainly

This is the single most important thing to understand about a Pi in a robot, and it is not a defect — it is what an operating system is.

A microcontroller running loop() executes your code and nothing else, so a 1 ms interval is 1 ms. Linux is time-sharing: the kernel can preempt your process to service a network packet, flush a disk write, or run any of a hundred background tasks.

The consequence is the two-brain architecture, and it is not a compromise but the normal design for a serious robot:

Raspberry Pi                        Microcontroller
- camera, vision                    - encoder counting
- SLAM, path planning       <-->    - PID motor control
- ROS 2 nodes                       - servo timing
- networking, dashboard             - emergency stop
        high-level goals                  hard real time

They talk over USB serial, UART, or I²C, and each does what it is good at. A Pi trying to count encoder edges will miss them; an Arduino trying to run OpenCV cannot.

Powering it, and the SD card problem

Power is where Pi robots fail, and the failure mode is unusually expensive: a brown-out during a write corrupts the SD card, and you lose the whole system image.

Rules that follow from that:

• Never feed motors and a Pi from the same rail. Motor inrush is exactly the transient that corrupts a card.
• Use a switching regulator, not a linear one, if you are dropping from a battery. A linear regulator taking 11.1 V to 5 V at 1 A burns 6 W.
• Watch for the lightning bolt. The Pi displays an under-voltage warning icon and logs it; vcgencmd get_throttled reports it too. Anything non-zero means the supply is inadequate, and it will corrupt a card eventually.
• Shut down cleanly. sudo shutdown -h now before cutting power. A robot that gets switched off with a toggle switch needs either a shutdown button wired to a GPIO, or a read-only root filesystem.

The read-only filesystem is worth serious consideration for a deployed robot: with overlayfs enabled, nothing is ever written to the card during operation, and power can be cut at any moment with no consequence. You lose the ability to save data locally, which is usually a fair trade.

Which model for a robot

For ROS 2 with a camera, 4 GB is the point where things stop being frustrating. RViz, a vision node and a navigation stack together will use more than 1 GB, and a Pi that starts swapping to the SD card becomes unusably slow — and wears the card out.

Two accessories that are not optional in practice: a heatsink or fan (a Pi 4 under sustained load throttles at 80 °C, and a throttled Pi drops frames), and a good quality A2-class microSD card, or better, boot from USB SSD. Card speed is the bottleneck far more often than CPU.

Troubleshooting

Pi or microcontroller?

The honest framing: these are not competitors. A Pi cannot count an encoder reliably and a microcontroller cannot run OpenCV. Almost every capable hobby robot ends up with both, and recognising that early saves a lot of effort spent trying to make one do the other’s job.

If your robot’s whole behaviour fits in one control loop — a line follower, an obstacle-avoider, a maze solver — you do not need a Pi at all, and adding one makes the robot slower to start, more fragile, and harder to debug.