v0.1.3

Highlights

• Resource reservations: one program per device. The servo bus, camera, microphone, speaker and face display are now reserved by whichever program opens them first. A second program — another user's SSH session, a Portal app, a script, the MCP server — fails at once with ResourceBusyError naming the holder's user, app (PALMIMO_APP_ID) and pid, instead of colliding at the OS level. The OS releases a reservation when its holder exits, even on kill -9. See "Resource reservations" in doc/reference/api-reference.md. (#71)
• Shared lock directory /run/lock/palmimo. Every account on the machine and every Portal app takes part; plain Linux needs no setup. Palmimo devices get the directory from the platform bundle (palmimo-image platform version 2), which also lets Portal apps write to it. PALMIMO_LOCK_DIR overrides the location. (#71)
• scripts/diagnose_servos.py reserves the servo bus and reports the holder instead of talking to a bus another program is driving. (#71)

Upgrade notes

• Opening a device another program holds now raises ResourceBusyError. It and ReservationSetupError derive from ReservationError, not RuntimeError, so except RuntimeError no longer swallows contention. HeadCamera.read() / latest() and Microphone.record() raise them too instead of returning (False, None) / None.
• While a program is connected through Palmimo.connect() with a speaker or microphone, those devices cannot be used standalone either; stop that program first.
• The MCP server and the wakeword / teleop examples stop with the holder shown instead of starting compute-only when a device is held elsewhere.
• Servo port leaks on a failed handshake, arming or torque release are fixed: the port is closed.
• Portal apps take part once the official examples move to this release (next examples-v*) and the device runs platform version 2.

Known issues

• Code that opens a device without the SDK — including LeRobot's DynamixelMotorsBus used by the LeRobot plugin scripts — does not take part in reservations.
• Reservations coordinate users; they are not a security boundary. Anyone who can log in can hold a lock.
• On systems where /run/lock is not world-writable (some non-Debian distributions), set PALMIMO_LOCK_DIR to a directory all participating users can write.

Verified with v0.1.3-rc1 from TestPyPI on a Raspberry Pi 5 (Debian 13, Palmimo image with platform version 2): a zip app installed through the Portal took the servo bus inside its app unit, an SSH user's claim failed naming the app, stopping the app released it at once, and the reverse held. On an office robot (Raspberry Pi OS, servos, head camera, ReSpeaker, face display), each device refused a second user with the holder shown and was free right after the holder was SIGKILLed, and Palmimo.connect() failed and rolled back cleanly when any one device was held by another user.

What's Changed

Other changes

• feat(sdk): 0.1.3 — reserve exclusive devices across processes and users by @DoskoiYuta in #71

Full Changelog: v0.1.2...v0.1.3