THE USEFUL PART
- Identify which layer is changing: app, server, SDK or firmware.
- Keep a repeatable baseline task and the observed result.
- Ask about supported recovery; do not assume a downgrade exists.
Identify the change before starting
An update button can refer to several different pieces of a robot system. A desktop application, an onboard service, a development library and motor firmware do different jobs. Before changing a working setup, identify what will change and where the manufacturer documents that change. This guide proposes a recordkeeping method; it does not provide a universal flashing procedure.
Reachy Mini’s troubleshooting documentation distinguishes several software and device problems rather than treating them as one generic failure. That is a useful reading habit for any programmable robot: keep the exact model, connection mode and affected component beside the symptom. Instructions written for another edition can answer a different problem.
Capture a small working baseline
Choose one ordinary task that is safe and allowed by the product’s instructions. Record its input, starting state and expected completion. For a stationary conversation prototype, that might be receiving a synthetic text input and producing the expected response through the selected application. Do not add movement or external actions merely to make the test look impressive.
Write down the installed versions, application settings that matter, host operating system and relevant accessories. Save only configuration that the product supports exporting. Keep credentials out of screenshots and public issue reports. A photo of the robot tells another person very little about the software arrangement that produced the result.
Read the recovery route in advance
Ask what happens if installation stops, the application cannot reconnect or the baseline task no longer works. Find the supported diagnostic and recovery instructions for that component. A factory reset, an application-environment reset and reinstalling a package can have different consequences. Do not treat them as interchangeable guesses.
The cited Reachy Mini troubleshooting page includes paths for bootstrap, application-environment and update problems. Use its current instructions for the matching case rather than commands copied from a different version. This source analysis does not establish that every failure is recoverable, or that a particular older version can safely be installed.
Change one thing and repeat the task
Follow the documented update procedure, including its power and connection requirements. Avoid interrupting a device update to experiment with an unrelated fix. When it finishes, repeat the same baseline task and record the outcome. If other settings changed as part of the update, include them in the comparison rather than attributing everything to the version number.
In a fictional example, an application still starts after an update but no longer receives the selected microphone. The useful report identifies the versions, selected device, reproducible input and observed failure. It does not immediately conclude that the robot’s microphone hardware is broken. Keep the last known working observation alongside the new one.
Make the record easy to hand over
Our proposed card contains configuration before, change requested, documentation reference, exported settings, baseline task, result after and next action. Add the time and a safe diagnostic reference. If the result is uncertain, say so before returning the robot to the intended activity. One successful check supports that task and configuration, not every feature in the system.
Use the SDK-access guide below to decide what a development package actually lets you change. Keep updates and experiments separate in your notes so another person can reconstruct the sequence. Source checked September 20, 2026. No hardware was updated or tested for this article, and no recovery or continued-support guarantee is implied.