Lightberry

Lightberry's clearest strength is that it removes the integration work that normally kills social-robot projects. The hardware is the Lumi — 4 ft 2 in (1.3 m), with documented joints, sensors, battery and onboard compute — and it ships pre-installed on Unitree hardware. A buyer interacts from day one rather than spending months wiring servos to a language model. The software layer is split deliberately: local software for responsiveness, a cloud agent for conversation and perception, an operating system, and an extension model for adding capability. That split is what makes on-device processing for low latency and continuous learning from human interaction compatible with each other. Customization is the actual product differentiator. Personality, behavior, appearance and functionality are all editable, which is what separates a companion from a kiosk. For retail, hospitality or a museum floor, you can give Lumi a voice and a set of answers that match the venue, then use OTA software updates to revise it without touching the unit. Pilot one in a single store, then push the same personality to a fleet through multi-robot fleet management — that is a realistic rollout path for a small operator. The weaknesses are worth stating plainly. First, the public documentation is thin. The docs site is an introduction with three sections — Hardware, Software, Customization — and the deeper pages are not substantiated by what we could reach. No underlying AI model names are documented, so you cannot verify model-level behavior, accuracy or latency claims before buying. Deployment details, connectivity requirements beyond the existence of a cloud agent, and hardware compatibility are similarly unspecified. Second, the architecture is cloud-dependent by design. Organizations that need fully on-premise, offline inference — regulated environments, sites with poor connectivity — should treat that as a blocker, not an inconvenience. Third, the platform sits on Unitree hardware, so your upgrade path and your robot's physical capabilities are tied to a supplier you do not control. Fourth, developers who want full control over low-level motion will hit the abstraction layer fast; the extension model lets you add functionality, not rewrite the locomotion stack. Where it fits: consumers who want a social companion at home, businesses putting an interactive robot in front of customers, educators using a robot for engagement, and roboticists who want social AI without building it. Where it does not: buyers who need a utilitarian machine, teams with strict data-residency rules about sending interaction data to a third-party cloud, and anyone treating this as a general-purpose robotics development platform. Ask for a live demo of the specific personality and behaviors you plan to deploy before committing — the documentation will not answer that for you.