Worked with ROS in research, industrial, and warehouse spaces for 12 years now, with fleets of hundreds to thousands of robots, tens to hundreds of thousands to

Worked with ROS in research, industrial, and warehouse spaces for 12 years now, with fleets of hundreds to thousands of robots, tens to hundreds of thousands total worldwide. If there's one thing I could convince people of, it's to never use ROS to communicate between hosts. If you want to use ROS for IPC on the same host, fine. That can all be debated but okay. But if you want to communicate to different robots, especially over WiFi, ROS is missing most of what you need, and it's things that roboticists do not need to reinvent as the Web has been grappling with these issues for a lot longer by millions of more developers. - You will have to worry about versioning, either on your terms of when you're inevitably forced to - Even if you don't plan on operating multiple versions in harmony (years later you'll regret believing you could get away with this), you have to deal with the edge effects of when you upgrade them remotely/on-site. - ROS API definitions ("ROS Messages") are defincient. Yes, you really need to support `null` but you also need a whole lot more expessiveness in general. You'll invent your own string-but-actually-json message at some point. - You end up manually dealing with well-trodden problems like compression, authentication, authorization. - Failed comms, reconnecting, retrying, etc. will be a huge pain. I think the simplest question to ask yourself/team is: "Could this be an HTTPS API? Could this be a Websocket? Do we even have the correct skills on the team to answer this question or did we only hire ROS people?"