tl;dr: ROS2-Wifi default setup is not great and gives a bad experience to users without a strong DDS/networking background.
If you don’t know me, I play around with mobile robots over in Navigation2 and related projects. This is a little long-winded because I wanted to be thorough, feel free to skim. The majority of folks involved in ROS2 have been jack of all trades, ROS-specific developers, or large companies with resources. As such, its been unideal but relatively unavoidable that a robotics developer has had to wander deep into the forbidden forest that is DDS to get things to work in ROS2, many times without a guide. Many large companies have this expertise in house and the jack of all trades welcomes the challenge, but this isn’t scalable nor a way to offer an enticing out of box experience to bring people into ROS2. As we enter Foxy, as the next LTS release, and new development is increasingly gearing to ROS2 (as evidenced by ROSCon ROS2 talks continuing to climb), I think its an appropriate juncture to talk about some default behaviors for the average user. This post is about Wifi, but I suspect in the comments below others will bring up complementary painpoints.
Everyone has a different look at what an “average user” is, so I want to outline here my view of an average user from my anicdotal experience:
- Some robotics experience, whether it an undergraduate course or a masters program
- Range of software experience, from basic python scripting to professional C++ development
- Hired/researching planning, cloud, applications, sys admin. Usually some level of Linux-level networking. Being able to: nmcli, ifconfig, setup static IPs, and easy-RSA3 puts you in the top 10%.
To this profile of an average user, ROS should “just work”. You make a publisher for your work, your robot subscribes to it, you install an open-source driver packages to make your robot run. If you’re a mobile robotics person or want ROS2 networked across multiple machines over Wifi, you’re now in for a world of hurt. You’ve heard about this thing called DDS and you think its pretty neat in concept, but now you find that you’re not even getting 15 fps camera feed in rviz on corporate wifi you easily got in ROS1 and you need to fix this by Friday.
It has become evident to me that this is a serious problem recently through a string of emails from users exasperated as ROS2 has been picking up steam from notions that ‘ROS2 is ready’. I knew this was a learning hurdle but it didn’t occur to me how challenging the average user would find setting this up and the things they’d try to work around it. Managing the Navigation2 project and communicating with groups using mobile robotics technology has given me a taste of their experiences trying to get basic demo running over wifi. I have even found groups in large corporations questioning the maturity of ROS2 to be used on any product at all. The concept of going to the DDS layer is not intuitive to users that they can’t “do this through ROS2” in some fashion. I think that’s simply an idea that needs to be dispelled, but it gives you an insight of how other people look at this that haven’t done the dive to “know better”.
Wifi seems to be being treated as an after-thought or a special edge case, rather than the default. Much of the limited documentation you find on this topic blames the router (which doesn’t induce confidence) or provides a long-winded explanation of what’s going on in domain-specific jardon. From the perspective of the average user I describe above: “I don’t care, how fix?”. We should be giving them some configuration to use that “just works”, but moreover, I think support for this should be the default configuration such that the average user never needs to know there’s any other way. If you’re building a product, at some point someone needs to optimize the network. That person isn’t the developer working on robotics demos or development whom currently needs to overcome this struggle in efforts to complete a basic and unrelated task.
This isn’t to say that I think that all robotics applications require this. I venture to assume the industrial manipulator crowd may be less interested in this and autonomous driving doesn’t require Wifi support at all. The question I pose is: Are the DDS vendor’s settings to work on Wifi degrading average performance so poorly for those use-cases that they can’t make basic demos? If not, which I suspect, then this would be an excellent middle-ground solution to make the configurations for Wifi default behavior on all Tier-1 DDS vendors / RMWs. I believe it should be our goal that > 2 sigmas worth of users shouldn’t need to know or care about DDS for their day to day development. At the moment, that’s closer to -1 sigma.