Building an Interactive Exhibition Kiosk on Raspberry Pi

They had a problem: their kids’ interactive exhibit—a custom-built arcade machine—kept dying. The original contractor had used a consumer-grade Android tablet glued to a wooden frame, and it was overheating, crashing, and generally failing after three months of heavy use.

They needed a replacement. Something durable, maintainable, and fast enough to run a physics-based puzzle game without lag. They also wanted the ability to update content remotely, since the exhibit was scheduled to rotate every six months.

We proposed a Raspberry Pi-based solution. Specifically, the Raspberry Pi 4 Model B with 4GB of RAM. Here’s why:

For an interactive kiosk, you need a full operating system. An Arduino or ESP32 can handle sensor input and LED strips, but rendering a 1080p game with touch input and audio requires a proper Linux environment. The Pi 4 gives us that.

We paired it with:

- A 10.1-inch capacitive touchscreen (HDMI + USB)

- A custom arcade button panel with a USB encoder board (the kind used in DIY fight sticks)

- A small 5W amplifier and two speakers

- A solid-state relay for controlling the ambient LED lighting around the cabinet

- A 32GB industrial-grade microSD card

The whole thing draws about 7W under load. That’s nothing. The museum’s old tablet setup was pulling 15W and still thermal throttling.

The client’s core requirement was that the machine boots straight into the game. No desktop, no cursor, no chance for a kid to accidentally open a terminal and delete something.

We used Raspberry Pi OS Lite (Debian Bookworm) and stripped it down further. No X server, no desktop environment. The game runs directly on the framebuffer via SDL2.

For the game itself, we wrote a custom Python application using Pygame. It’s not the most performant tool for 3D, but for a 2D puzzle game with sprite animations, it’s more than adequate. We hit a steady 60 FPS at 1080p with vsync enabled. If we needed more juice, we’d have moved to C++ with SDL2 directly, but we didn’t need to.

The arcade buttons map to keyboard events via the USB encoder. We configured them as arrow keys plus a single “action” button. Simple, reliable, and easy to debug.

Museums have a habit of losing power. Either a janitor trips over a cable, or a curious kid yanks the plug. A standard Pi setup will corrupt the SD card if it loses power mid-write.

We mitigated this in two ways:

1. Read-only root filesystem. We mounted the root partition as read-only. The game writes its high scores to a tmpfs (RAM), and we flush them to disk only on a clean shutdown triggered by a GPIO button hidden in the cabinet.

2. A UPS HAT. We used a small uninterruptible power supply HAT with a 18650 battery. It gives the Pi about 30 seconds of runtime after power loss, which is enough to trigger a clean shutdown via a Python script watching the power status.

Since deployment, we’ve had zero SD card corruptions. That’s over nine months of continuous operation, 10 hours a day.

The museum wanted to change the game content every quarter. Shipping a technician to the UK from India every time wasn’t practical. We needed a way to push updates remotely.

We set up a simple update mechanism using MQTT and rsync. Here’s how it works:

- The Pi runs a lightweight MQTT client that subscribes to a topic like `museum/exhibit1/updates`.

- When we publish a “new build ready” message, the Pi downloads a compressed archive from our server via HTTPS, verifies its checksum, and swaps out the game assets in a staging directory.

- It then reboots into the new version. If the checksum fails, it rolls back to the previous build automatically.

The entire process takes about 90 seconds from publish to reboot. The museum staff don’t need to do anything. We also added a watchdog timer — if the game process doesn’t start within 30 seconds of boot, the Pi reboots again. If it fails three times, it falls back to a recovery partition with a basic diagnostic screen.

The off-the-shelf parts were fine, but the wiring was a mess. A bunch of jumper cables and a breadboard isn’t acceptable inside a cabinet that gets bumped and shaken by children.

We designed a small custom PCB that mounts directly on top of the Pi’s GPIO header. It handles:

- Level shifting for the button inputs

- The relay driver for the LED strips

- A proper power management circuit for the UPS HAT

- A connector for the touchscreen’s backlight control

We laid it out in KiCad, ordered a batch of 50 boards from JLCPCB, and assembled them in-house. The cost per board was about $4 in components. It took our hardware engineer two days to design and test. The result is a single, clean assembly that’s easy to service — if a button dies, you replace the button, not the board.

A few things surprised us during the project:

Touchscreen calibration is still a pain. Capacitive touchscreens on Pi sometimes drift, especially after temperature changes. We ended up writing a small calibration routine that runs at boot and uses a fixed-point mapping file. It’s not perfect, but it’s good enough for the museum’s use case.

Thermal management matters more than you think. The Pi 4 runs hot in a sealed wooden cabinet. We added a small 40mm fan controlled by a thermistor circuit, and the CPU stays around 55°C under load. Without it, we saw thermal throttling within 20 minutes.

Testing with real kids is non-negotiable. Our initial button layout looked fine on paper, but kids with small hands struggled to reach the action button. We revised the cabinet design based on feedback from a trial run at a local school. That meant a quick 3D print of a new button bezel and a re-cut of the acrylic panel. Cost us a day, saved us a headache.

The exhibit has been running for nine months with zero downtime. The museum staff love that they don’t have to touch it. We love that we can push updates from our office in Pune without flying anywhere.

The total hardware cost per unit was around $250. The old tablet setup was probably cheaper upfront, but it failed twice in six months, and each repair visit cost more than the hardware itself.

If you’re building an interactive installation that needs to survive public use, a Raspberry Pi with a custom carrier board and a read-only filesystem is a solid, boring, reliable choice. Boring is good in this context. No one wants an arcade machine software that crashes mid-game.

We’re now working on a second unit for the same museum, this time with a multi-touch table. Same Pi 4, same update pipeline, different peripherals. The architecture scales.