Reachy Mini tightens its robot OS image

Pollen Robotics released Reachy Mini OS v0.2.7 on June 17 in the official repository for the system image used by its open source Reachy Mini robot. The note is brief, but it locks down two useful points for an embedded machine: the Linux kernel is pinned to version 6.18.33, and the image now uses the reachy-mini package at version 1.8.3. For a robot, that is not merely routine software housekeeping. The operating system connects motors, camera, audio, networking and Python libraries, which means it decides how easily developers can turn code into physical behavior.

The more interesting signal appears when this latest release is read alongside the earlier entries on the same official release page. Reachy Mini OS v0.2.4, published on June 10, already addressed several operational details: clearer OS image names, Bluetooth support through WirePlumber and BlueZ, an updated camera and media stack using GStreamer and libcamera, system-wide Git LFS for uv-managed installs, and narrowly scoped passwordless sudo for the pollen user. These are practical changes rather than headline features. Bluetooth can support audio peripherals, the camera stack shapes perception experiments, and Git LFS matters when models or large assets live outside the regular Git objects.

Reachy Mini sits in a useful part of the robotics landscape. It is less dramatic than an industrial humanoid, but more approachable as a platform for learning, prototyping and embodied AI experiments. A stable system image reduces the gap between a software idea and observable robot behavior. If a media library is wrong, if a camera is exposed inconsistently, or if a health check holds motor resources while testing, developers feel it immediately. The v0.2.4 notes specifically mention a fix to reachyminios_check, which now releases media and motor resources before running tests on Reachy Mini 150.

The point is not that Reachy Mini has acquired a spectacular new capability overnight. It is that Pollen Robotics is doing the infrastructure work that makes an open robot usable over time: pinning the kernel, aligning application packages, clarifying image variants, and improving camera, audio and installation paths. For schools, labs and advanced hobbyists, these quiet layers often decide whether a robot becomes a daily tool or remains a fragile demo. Open source robotics advances through algorithms and models, but it also advances through release notes like this, where the embedded system becomes predictable enough for users to focus on the behaviors they want to build.