The success of ROS depends upon the contributions of thousands of individuals. In honor of our 10-year anniversary, we've decided to shine a light on a few of them.
Name: Tom Moore
Company: Senior Roboticist, Locus Robotics
Favorite Fictional Robot: WALL-E. "I love the bit where he has a cup full of spoons and a cup full of forks, and he's trying to classify a spork as one or the other, and ends up just placing it between the two cups. He also repairs himself using spare parts."
How did you get into robotics?
I was introduced to artificial intelligence, artificial life, and robotics as an undergraduate student. The thing that really got me with robotics was the idea of embodied AI, and the fact that this autonomous agent was moving around in the same world as I was, perceiving and affecting it in the same way (or, in many cases, just running into things). I spent a lot of time with the university's Pioneer 2, watching it drive around our computer science lab and try to generate rudimentary maps using its sonar sensors. When I decided to go to grad school, it was an easy decision as to what my focus would be.
What is your current area of ROS development? On which robot?
In the wider ROS ecosystem, I tend to focus on state estimation, though I like to chip in with occasional PRs to some of the ROS tools. I also am trying to get involved in ROS 2 development. Within Locus, I work within a lot of areas, from state estimation to navigation to the odd bit of ROS build farm maintenance. Our primary platform at Locus is known as the LocusBot, and pretty much all of my time is spent working with it.
What are your favorite and least favorite things about ROS?
If I had to choose just one thing, I think ROS bags are fantastic. The ability to replay live data is absolutely critical for development, especially in scenarios where you are having trouble replicating a bug. As soon as you manage to replicate it while recording, you can rapidly diagnose and fix the problem. My least favorite thing about ROS is that supporting a large number of robots in a multi-robot scenario is a challenge, but that's going to be addressed in ROS 2!
What would you like to change about ROS?
My answer will be a little hypocritical, as it's something of which I am definitely guilty. As ROS has matured and its user base has shifted from academia to industry, I find that most packages are slow to implement significant code changes or accept pull requests, especially those that might cause incompatibilities with older versions. I'm assuming that, as is the case for me, most package maintainers are too busy with their jobs to spend a significant portion of time maintaining packages. This is a good thing, in a way, because it means that those package authors and maintainers are too busy making a living using ROS to devote time to their packages. It can lead to a sense of things getting a bit stale, though. I think more of us need to take the time to bring in new developers and maintainers for our packages.
How would you have do things differently if you didn't have ROS?
Where do I start? When I started working in robotics, every grad student or company seemed to be reinventing the wheel for everything. Worse, this problem would even persist across projects within the same organization. I used to write a lot of monolithic processes whose classes were analogous to ROS nodes. Want to visualize your data? Hack something together quickly using a language with a simple drawing library. Want to replay the data? Too bad! You have to recreate that bug using a live robot and hope that you trigger it this time, and then sift through your insane debugging logs to figure out what's wrong. This wasn't the case everywhere (I worked for one company that had independently developed their own very ROS-like inter-process comms), but I think it was pretty common.
With ROS, I can fire up a powerful visualization tool and instantly see what's happening with the robot, or give it a command to drive somewhere. I can record and replay data to my heart's content. I can distribute my processes and give them very specific roles, and then easily swap out that component for another one as the software matures. It moves the starting line for any serious robotics project ahead by years.
This is part of an ongoing series: ROS Contributor Spotlight
Have your own ROS story to tell? Let us know at comm@openrobotics.org. And be sure to check back when we celebrate the 25th, 50th, and 100-year anniversaries of ROS.
