Hi, I’m just collecting info on how you’re solving some simple status pages running locally on robots that would show some basic information like battery status, driver status, sensor health etc. But nothing fancy like camera streaming, teleoperation and such. No cloud, everything local!
The use-case is just being able to quickly connect to a robot AP and see the status of important things. This can of course be done via rqt or remote desktop, but a status webpage is much more accessible from phones, tablets etc.
I’ve seen statically generated pages with autoreload (easiest to implement, but very custom).
I guess some people have something on top of rosbridge/RobotWebTools, right? But I haven’t found much info about this.
If on top of that you want to do more, incl. calling services, you can use the ROS Tool capability:
Note that we strongly believe that "robots should be clients not servers"™. Many robotics companies start by putting web servers on their robots, and you are right that that’s better than remote desktop or Rqt. But once you have 5+ robots you’ll find that it becomes cumbersome jumping between them, finding some being offline, and pushing updates and configuration. You also can’t easily aggregate data from multiple robots – and don’t get me started about firewalls and VPNs.
In the Transitive framework robots are clients connecting to the cloud and the cloud aggregates and caches all data. This way you can always see your robots’ latest data, even if stale, and you can change configuration and they will “pick it up” when they come back online.
I’ve played with several but not used any of them in the end. I use foxglove which is very nice. But having something hosted on the robot itself that doesn’t require software install or any magic would be nice. And even add a small lcd display on the robot itself so you can glance at it and read its mind.
Here are some links that I came across in my travels that might fit the bill. Note I haven’t tried them recently so they may not be current anymore.
YMMV / FWIW
Best,
Pito
Boston Robot Hackers &&
Comp. Sci Faculty, Brandeis University (Emeritus)
I know about Transitive and I know it’s not for us. Others might find it useful, though.
In our case (research university), I know we will never have a fleet of our research robots. There’s usually one, or at most a few of each. And we don’t need any “overarching” performance metrics in the cloud, because the meaning of performance is not definable for us (it changes with each experiment).
Plus, we do outdoor robots. We don’t have connectivity all the time. Sometimes, the robot is connected. Sometimes, our phones/PCs are connected. Occasionally, both are. But it’s not the most frequent case.
That’s what the local self-hosted option is for, either on an edge device (e.g., your laptop), or on the robot itself. One way or another you will need to host something on your robot or laptop and that something will include at least a web server.
Back in 2003, before ROS, we, at RWTH Aachen, spent a lot of time on the robotic middle-ware, just like most robotics groups at universities did at the time. ROS made it possible to focus this time instead on the actual robotic research challenges rather than the plumbing. Transitive is trying to do the same for needs like the one you describe: for managing robots during operation, no matter the environment. You might think that it’s a bit more complicated and heavier to set up than one simple web-server, and it is (although it’s all automated using docker-compose). That’s what people thought about ROS initially as well, but in the long-term it pays off!
There’s Lichtblick which is Foxglove fork before they went private, developed by BMW (I guess they use it internally)
I also like rclnodejs, I made some simple teleop and buttons with it, it’s pretty nice. Maybe I can share some code if you are interested.
Basically this runs as nodejs backend and then you can serve some interactive website with websockets.
Then I also like Vizanti just for nav2 and also teleop on phone, but there are some quirks.
OMG! Self-hosted almost-Foxglove! How come people don’t talk about it more? =)
Is there a practical difference between rclnodejs and rosbridge? I guess, in the end, both create a WebSocket-based backend to which you can connect any frontend with a small JS client library, right?
They are completely different things. rclnodejs is the node.js version of rclpy/rclcpp, i.e., a node.js client for ROS2 (like rosnodejs is for ROS1). You can use it to build ROS nodes in node.js directly – although I believe rclnodejs actually wraps rclcpp (unlike rosnodejs which “speaks” XMLRPC and ROSTCP/ROSUDP directly).
It’s what we use in @transitive-sdk/utils-ros (Documentation), to provide an (almost) unified interface for ROS1 (using rosnodejs) and ROS2. That package, in turn, is what we use in all our ROS capabilities, incl. the above Health Monitoring and ROS Tool.
Yes, rclnodejs is built on top of rcl library, providing JavaScript language binding, just like rclpy and rclcpp, and rcl uses the rmw interface to talk to the underlying DDS middleware, that’s how different language clients of ROS2 work mostly.
rosbridge, as it’s so called, can bridge the data received from websocket (frontend) to ROS2 and it’s backed by a real ROS2 client (rclpy), finally, you can leverage frontend JavaScript library, like roslib, to access to ROS2 system.
If you build a simple web page that only pub/sub specific topics, I prefer using rclnodejs directly and sending the data through websocket in JSON to browser which brings small overhead, like this Electron demo.
If you are building a complex web app and hope it could be extendable, then roslib is good choice.
Yeah, this looks definitely interesting. However, does it have the web UI? In Getting Started — ros2_medkit Documentation they link to something, but it seems to be more SOVD developer-oriented…
And no, I don’t count Foxglove, because self-hosted costs… who knows what 