Robotics is very niche and the market is dominated by early stage startups (since most of them go out of business a few years in), so salaries are average unless you are working specific jobs for FAANG. Job hoping usually means moving elsewhere, since working close to the hardware makes it much easier, which in turn means having a good picture of what is a competitive salary sometimes is not obvious.
Thanks for the AMA! Do you see a lot of opportunities for people utilizing computer-vision based SLAM (aka Structure from Motion)? I quite like that technique, but it seems too niche to make a consistent career out of it.
SLAM and localization in general are early bottlenecks in mobile robotics solution, unless the core business of the product is localization itself (e.g. waymo, cruise, etc.) it's not uncommon for that to take a back seat during product development later on. In my experience lidar based solutions are more common out there due to their "simplicity" and safety for industrial applications (i.e. PL-rated)
You certainly can work with visual slam in the industry, but the job pool for that is not very big, I would say.
I work for a self driving doing mapping. There are definitely roles out there, more broadly look into other areas of state estimation.
It gets interesting when these systems need to be productionized and scaled. A strong software engineer who can speak the math is invaluable. My first year on the job was basically removing N^2 loops and making 3D visualizations.
Computer vision based SLAM definitely has use cases and you can definitely make money applying it at the right companies to the right set of problems. Building a whole career around a single technique, any technique, probably is probably not gonna work. You need to be broader than that.
how would you recommend a software dev break into the industry over the next 3-5 years? Preferably without going back to university. What sorts of projects are best to focus on initially?
Not the person you asked, but the main qualifications are having a pulse and knowing any of C, C++, and Python. The main obstacle you're going to run into from an educational perspective is that people won't want to hire you for controls-specific roles, but those are a niche within a niche. Interview questions will often involve talking about things like RTOSes, writing a queue in C, handling ISRs, and sending messages on a bus (e.g. CAN/i2c/spi).
Robotics is a broad field and is a confluence of many specialties: mechanical engineering, hardware engineering, software engineering, control, machine learning, computer vision, anything in between is a good entrance.
Coming from software, if you are interested, I would suggest either:
- Backend platform development (Python, C++ as main programming languages with a strong focus on ROS[1]).
- Frontend development (nothing too different from what's out there).
As small projects I would suggest playing with ROS to learn it and getting a running simulation with a simple robot that you can teleoperate, most of the stack already exists, it's just connecting everything together [2].
Another venue is open source contribution [1] to get known within the community and potentially attract interest from companies. ROS has multiple packages, from cloud infrastructure to drivers and simulation, if you see anything there you could contribute to, they will gladly take contributions.
In general robotics greatly benefits of good technologies from other areas, if there is a tool we use you believe could be better or a lack of good tooling in a specific area, it will get noticed.
So this would be my suggested path: learn C++/Python if you're not familiar with, learn ROS and watch which specialties appear more often in robot related jos posts [3]. If you are really invested, maybe go to a robotics conference as ROSCon to meet other enthusiasts, which companies are engaged with the community, etc.
Good luck!
Note: not everything robot related is done in ROS, but it's almost a standard within the field save for a few exceptions.
not everything robot related is done in ROS, but it's almost a standard within the field save for a few exceptions.
In academia, yes. ROS is a piece of middleware for passing messages around, and a standard for talking to it. Funding agencies pushed academic robotics projects to talk to ROS so that results from different projects could interoperate. Which they sort of do. You get a lot of tooling for logging, user interfaces, wiring things up, etc.
Think of it as a solderless breadboard for robotics software.
The final product probably doesn't use it.
I disagree here, usually projects that are not keen on relying on ROS end up re-implementing a lot of the groundwork (shared memory, message distribution, parameter server, logging, etc.), usually they are older products (10 or 15+ years old), where ROS wasn't really a thing and migrating to ROS after implementing their own tailored stack is not worth it.
Ah neat, then I do have an actual question for you. If you're using ROS 2, which version and middleware? And does it work reliably in your application?
I feel like lots of companies have ditched ROS 1 only because of support being cut and cargo culting about how ROS 2 is better for unclear reasons, but in practice it feels anything but production ready to me. Everyone talks big how Zenoh will solve everything, but the thing is a damn prototype and really goes against the whole idea that having a DDS will be somehow better instead of just adding absurd overhead in both CPU and networking.
I'm using ROS 1 Noetic on Ubuntu Focal at my current job.
I've touched ROS 2 back in 2019 during the Crystal Clemmys era but it still felt experimental back then (and I believe still was considered beta), I plan to re-evaluate later this year/early 2025 how stable ROS 2 is now.
ROS 2 is better in some aspects that weren't accounted for back when ROS 1 was developed (which started as research platform), mainly distributed systems (multi-robot environments) and good tech developed elsewhere that the system could benefit from.
My personal take is that there is a lot of hit and miss between versions, no guarantee that what works now will work on the next one due to the decentralized nature of the community and the fact the team developing all this is relatively small. I would love to have a way to do small iterations on my own stack to bring it to the latest and greatest ROS release, but the combo of ROS 2 + major Ubuntu upgrade every 2 years is maybe too much for my own peace of mind.
That makes sense, Noetic is rock solid compared to any ROS 2 release so far imo. I hope that this year's LTS will be more reliable (again with the whole promise of Zenoh rmw) but I remain sceptical since all the major fixes always get backported and Humble is not exactly a beacon of stability.
mainly distributed systems (multi-robot environments) and good tech developed elsewhere that the system could benefit from
Yeah that was the theory anyway, I'm not sure how much of that had really worked out as intended. Automatic discovery without a roscore has proven... unfeasible. Especially over wifi since the required amount of multicasts basically runs a continuous ddos attack and now we're moving back to the same old concept with FastDDS Discovery Server, Zenohd, and the ros2 daemon. Sure the DDS technically has encryption now, but I've yet to hear of anybody using it. Overall it's just a mess.
When you're doing that evaluation, take a good look at python nodes and their performance compared to Noetic. Currently it's bad, like horrendously bad, 30x less efficient in some cases that I've tested. And they've also ported the CLI parts from bash to python so tab autocomplete and parameter fetching take like actual seconds. I just don't know...
Maybe there's lots of systems out there already running on Cyclone or FastRTPS that make it all worthwhile, but I haven't really heard of any such cases.
the combo of ROS 2 + major Ubuntu upgrade every 2 years is maybe too much for my own peace of mind
Yeah 2 years seems a long time, but it never turns out that way. It really pains me to see useful packages made obsolete and unusable again and again for no reason but moving to the next release which usually brings effectively nothing by itself.
Currently it's bad, like horrendously bad, 30x less efficient in some cases that I've tested.
Ouch. Back when I played with it efficiency wasn't even under discussion, as the basics had just gotten there (topic/service/action support), last I paid attention to this matter was during to some performance/inconsistencies of FastDDS (during Foxy, maybe?) from which the default was changed to Cyclone, but I must admit I'm a bit out of the loop.
Yeah 2 years seems a long time, but it never turns out that way. It really pains me to see useful packages made obsolete and unusable again and again for no reason but moving to the next release which usually brings effectively nothing by itself.
Yup. Two years makes sense for cloud, but with hardware involved and a fleet deployed in varying conditions around the world, 2 years to migrate a major version of ROS and Ubuntu is maybe too short (not even considering packages that you depend on that might not be ported at all). I would love to see other distros with longer spans (Alma/RHEL/Debian) becoming 1st class citizens and ROS releases turning into incremental versions running on the same platform until they reach EOL, at "robotics pace" that would be fantastic.
Comments
Robotics is very niche and the market is dominated by early stage startups (since most of them go out of business a few years in), so salaries are average unless you are working specific jobs for FAANG. Job hoping usually means moving elsewhere, since working close to the hardware makes it much easier, which in turn means having a good picture of what is a competitive salary sometimes is not obvious.
source: I work in robotics. AMA.
Thanks for the AMA! Do you see a lot of opportunities for people utilizing computer-vision based SLAM (aka Structure from Motion)? I quite like that technique, but it seems too niche to make a consistent career out of it.
SLAM and localization in general are early bottlenecks in mobile robotics solution, unless the core business of the product is localization itself (e.g. waymo, cruise, etc.) it's not uncommon for that to take a back seat during product development later on. In my experience lidar based solutions are more common out there due to their "simplicity" and safety for industrial applications (i.e. PL-rated)
You certainly can work with visual slam in the industry, but the job pool for that is not very big, I would say.
I work for a self driving doing mapping. There are definitely roles out there, more broadly look into other areas of state estimation.
It gets interesting when these systems need to be productionized and scaled. A strong software engineer who can speak the math is invaluable. My first year on the job was basically removing N^2 loops and making 3D visualizations.
Computer vision based SLAM definitely has use cases and you can definitely make money applying it at the right companies to the right set of problems. Building a whole career around a single technique, any technique, probably is probably not gonna work. You need to be broader than that.
how would you recommend a software dev break into the industry over the next 3-5 years? Preferably without going back to university. What sorts of projects are best to focus on initially?
Not the person you asked, but the main qualifications are having a pulse and knowing any of C, C++, and Python. The main obstacle you're going to run into from an educational perspective is that people won't want to hire you for controls-specific roles, but those are a niche within a niche. Interview questions will often involve talking about things like RTOSes, writing a queue in C, handling ISRs, and sending messages on a bus (e.g. CAN/i2c/spi).
Robotics is a broad field and is a confluence of many specialties: mechanical engineering, hardware engineering, software engineering, control, machine learning, computer vision, anything in between is a good entrance.
Coming from software, if you are interested, I would suggest either:
- Backend platform development (Python, C++ as main programming languages with a strong focus on ROS[1]).
- Frontend development (nothing too different from what's out there).
As small projects I would suggest playing with ROS to learn it and getting a running simulation with a simple robot that you can teleoperate, most of the stack already exists, it's just connecting everything together [2].
Another venue is open source contribution [1] to get known within the community and potentially attract interest from companies. ROS has multiple packages, from cloud infrastructure to drivers and simulation, if you see anything there you could contribute to, they will gladly take contributions.
In general robotics greatly benefits of good technologies from other areas, if there is a tool we use you believe could be better or a lack of good tooling in a specific area, it will get noticed.
So this would be my suggested path: learn C++/Python if you're not familiar with, learn ROS and watch which specialties appear more often in robot related jos posts [3]. If you are really invested, maybe go to a robotics conference as ROSCon to meet other enthusiasts, which companies are engaged with the community, etc.
Good luck!
Note: not everything robot related is done in ROS, but it's almost a standard within the field save for a few exceptions.
[1]: https://www.ros.org/ [2]: http://wiki.ros.org/ROS/Tutorials [3]: https://discourse.ros.org/c/jobs/15
In academia, yes. ROS is a piece of middleware for passing messages around, and a standard for talking to it. Funding agencies pushed academic robotics projects to talk to ROS so that results from different projects could interoperate. Which they sort of do. You get a lot of tooling for logging, user interfaces, wiring things up, etc. Think of it as a solderless breadboard for robotics software. The final product probably doesn't use it.
I disagree here, usually projects that are not keen on relying on ROS end up re-implementing a lot of the groundwork (shared memory, message distribution, parameter server, logging, etc.), usually they are older products (10 or 15+ years old), where ROS wasn't really a thing and migrating to ROS after implementing their own tailored stack is not worth it.
What kind of robotics? It's a pretty wide field.
Mobile robotics, slam/localization and robotics backend.
Ah neat, then I do have an actual question for you. If you're using ROS 2, which version and middleware? And does it work reliably in your application?
I feel like lots of companies have ditched ROS 1 only because of support being cut and cargo culting about how ROS 2 is better for unclear reasons, but in practice it feels anything but production ready to me. Everyone talks big how Zenoh will solve everything, but the thing is a damn prototype and really goes against the whole idea that having a DDS will be somehow better instead of just adding absurd overhead in both CPU and networking.
I'm using ROS 1 Noetic on Ubuntu Focal at my current job.
I've touched ROS 2 back in 2019 during the Crystal Clemmys era but it still felt experimental back then (and I believe still was considered beta), I plan to re-evaluate later this year/early 2025 how stable ROS 2 is now.
ROS 2 is better in some aspects that weren't accounted for back when ROS 1 was developed (which started as research platform), mainly distributed systems (multi-robot environments) and good tech developed elsewhere that the system could benefit from.
My personal take is that there is a lot of hit and miss between versions, no guarantee that what works now will work on the next one due to the decentralized nature of the community and the fact the team developing all this is relatively small. I would love to have a way to do small iterations on my own stack to bring it to the latest and greatest ROS release, but the combo of ROS 2 + major Ubuntu upgrade every 2 years is maybe too much for my own peace of mind.
That makes sense, Noetic is rock solid compared to any ROS 2 release so far imo. I hope that this year's LTS will be more reliable (again with the whole promise of Zenoh rmw) but I remain sceptical since all the major fixes always get backported and Humble is not exactly a beacon of stability.
Yeah that was the theory anyway, I'm not sure how much of that had really worked out as intended. Automatic discovery without a roscore has proven... unfeasible. Especially over wifi since the required amount of multicasts basically runs a continuous ddos attack and now we're moving back to the same old concept with FastDDS Discovery Server, Zenohd, and the ros2 daemon. Sure the DDS technically has encryption now, but I've yet to hear of anybody using it. Overall it's just a mess.
When you're doing that evaluation, take a good look at python nodes and their performance compared to Noetic. Currently it's bad, like horrendously bad, 30x less efficient in some cases that I've tested. And they've also ported the CLI parts from bash to python so tab autocomplete and parameter fetching take like actual seconds. I just don't know...
Maybe there's lots of systems out there already running on Cyclone or FastRTPS that make it all worthwhile, but I haven't really heard of any such cases.
Yeah 2 years seems a long time, but it never turns out that way. It really pains me to see useful packages made obsolete and unusable again and again for no reason but moving to the next release which usually brings effectively nothing by itself.
Ouch. Back when I played with it efficiency wasn't even under discussion, as the basics had just gotten there (topic/service/action support), last I paid attention to this matter was during to some performance/inconsistencies of FastDDS (during Foxy, maybe?) from which the default was changed to Cyclone, but I must admit I'm a bit out of the loop.
Yup. Two years makes sense for cloud, but with hardware involved and a fleet deployed in varying conditions around the world, 2 years to migrate a major version of ROS and Ubuntu is maybe too short (not even considering packages that you depend on that might not be ported at all). I would love to see other distros with longer spans (Alma/RHEL/Debian) becoming 1st class citizens and ROS releases turning into incremental versions running on the same platform until they reach EOL, at "robotics pace" that would be fantastic.