Curiosum built a Control Tower interface for Thoro.ai's autonomous warehouse robot fleet using Elixir, Phoenix LiveView, MQTT, and Phoenix PubSub. The system lets operators track robot positions on a live map, monitor telemetry, and summon robots via a Callbox feature, managing hundreds of devices globally. Engineers discuss challenges around initial page state consistency, avoiding MQTT flooding when nobody is watching, routing data to the correct viewers, and ensuring stricter contracts for outgoing commands than incoming telemetry to avoid robots mishandling bad payloads.
Table of contents
Why Phoenix LiveView was a good fit for Thoro.ai's robotics platformChallenges of connecting Phoenix LiveView with real-time robot dataWhy Elixir and Phoenix LiveView work well for robotics systemsQuestions this post answers
How do you prevent flooding MQTT with robot status updates when no one is viewing the dashboard?
In Thoro.ai's Control Tower, built with Elixir and Phoenix LiveView, the system avoids constant status queries by only pulling telemetry over MQTT when a human operator is actively viewing the data, rather than continuously polling regardless of viewership. This keeps LiveView sessions consistent with frequent robot updates while reducing unnecessary MQTT traffic. Teams designing telemetry-heavy real-time UIs can find similar architecture patterns on daily.dev.
Why is Phoenix LiveView a good choice for building operational interfaces connected to physical hardware like robots?
Phoenix LiveView suits hardware-connected operational interfaces because it gives desktop-like responsiveness, simplifies wiring telemetry and commands directly to the UI, supports real-time visualization, and inherits BEAM's high reliability. In Thoro.ai's robot fleet platform, this let a single engineer own full feature packages instead of requiring separate specialist backend and frontend developers. Developers weighing LiveView against separate frontend stacks can track real-world case studies like this on daily.dev.
Why should command payloads sent to a robot have stricter validation than telemetry data coming from it?
Outgoing command payloads to robots need stricter contracts than incoming telemetry because a bad interpretation of incoming data typically just means missing information in the UI, while a mismatched type in an outgoing command can cause the robot to reject it or, worse, mishandle it physically. The portal-to-machine contract is deliberately made stricter than the machine-to-portal one. Engineers building safety-critical hardware interfaces can find related architecture discussions on daily.dev.