Almost definitely 100% teleoperated -- the robot might move between places autonomously, but all the manipulation tasks, i.e., the actual cleaning, is not something anyone yet knows how to do autonomously reliably. And that's OK. However I'd like to know whether the data you gather from these cleanings is shared with other companies (who would be willing to pay a lot of money for it in order to train their own physical AI models).
Looking at X Ai's Figure parcel sorting live-stream, the current robots seem way too clumsy to even pick up an object, I doubt they are precise enough to do scrubbing.
What a silly idea. Technology moves 20x faster than the legislature. There is no point in even trying this. By the time any suggestions would get implemented and (all?) signs replaced, they would already no longer be necessary -- like, 15 years past being necessary.
Just throwing a hypothetical in case we hit an algorithmic plateau of three nines of safety and have to start optimizing other parts of the stack. No idea is silly imo :)
Makes a lot of sense, and seems better executed than AWS's pathetic RoboMaker attempt 8 years ago or whenever that was.
Was looking for the team but there is no linkedin link on your page.
The problem is not that there is no standard -- there is, it's called ROS. The problem is that manufacturers are not interested in opening their robots up to that degree.
Also, REST is a terrible idea for interacting with robots. REST is call-response based. But with Robots a pub/sub (like ROS or MQTT) or a blackboard data architecture (like what we used in Transitive Robotics) is much more efficient and natural.
On ROS being the standard — you're right that ROS exists,
but adoption outside research/academia is still fragmented.
Boston Dynamics, Universal Robots, and most industrial arms
don't natively speak ROS — teams still write glue code.
RoboAPI is trying to be that glue as a managed layer rather
than a DIY problem.
On REST being wrong for robots — completely agree on the
pub/sub point. REST is the entry point for developer
familiarity but RoboAPI already has WebSocket streaming for
telemetry. The next step is moving commands to pub/sub too.
Interesting that you mention Transitive Robotics — the
blackboard pattern is something I've been thinking about
for the fleet layer.
What would the ideal architecture look like from your
experience? MQTT for commands, WebSocket for telemetry,
REST only for configuration?
Foxglove is not the only name in town. There are many, Transitive Robotics, the company I'm building is one of them. Different from Foxglove we are much more focused on live-remote monitoring and control, e.g., we have a pretty popular remote teleoperation module: https://transitiverobotics.com/caps/transitive-robotics/remo...
You can find all the other modules we're currently offering here: https://transitiverobotics.com/caps/
The platform itself is and remains open-source.
We are thrilled to announce a new major version of Transitive, the open-source framework for full-stack robotics. Version 2.0 adds significant new integrations and features: storage of historic and time-series data in ClickHouse, visualization in Grafana, and custom alerting via Alertmanager. Some of our capabilities, like the free Health Monitoring capability, already use these features, providing significant added value to robotics companies with growing fleets.
This is absolutely awesome. Thanks for sharing! I would love to chat more with you. For context: we make a remote teleoperation solution for robotics. It's mostly used for mobile robots, but we've been getting a lot of inquiries regarding teleoperation for manipulation, so I've been learning more about this, in particular regarding the question of speed. I really appreciate these results!
reply