Highly recommend if you want to get into robotics you have ROS experience and demos / stories at hand.
Usually people get stuck with ROS in commercial environments either because they inherited it from an academic project (company is a spinoff), or they used ROS for a demo and afterwards never planned with long enough roadmaps to make the cost benefit analysis obvious enough.
There's simply no reason to skip ROS as a student. My advice was not for businesses, whatsoever. And every single ROS replacement I've seen is ROS-like enough that the language ROS defined for all of us is effectively lingua franca.
But the antibodies that are triggered by even mentioning ROS should tell anyone how much it is not a fun thing to learn or work with. But it is a common touchpoint. It's really hard to understand _nearly any_ design decision in robotics software without first understanding why it isn't ROS.
What about buy 2nd hand/use/resell some hardware? I do not know how much cost a Ms in CMU, but sure does bot even compare to 20k.
Sorry maybe I’m a little bit negative, but if you have already one good title, that is more than enough. The problem is I fully subscribe to Stallone[0]
I think a lot of the "I don't see >40y/o swe" is a combo of:
There were more CS/IT grads from 2000 to today (<40 years old) than were ever produced prior to year 2000.
After 40 you tend to move into management, consulting, or just switch careers, b/c SWE pays well.
After 40 you don't work at companies that churn through young devs (so young devs are less likely to work with > 40 y/o)
ROS has some fundamental design flaws, but does integrate most development software from various research areas. In many cases, the sub-projects were abandoned decades ago, and only ROS developers keep these components operational.
The primary mistake most naive academics make is assuming you are dealing with a single problem domain. Robotics is different from simple automation in that it has 4+ different primary concurrent systems that must share state.
There is also the IP issues with parts of projects like OpenCV, and the patent holders (university legal departments) make it nearly impossible to license. i.e. unless you have >$3m to drop on each component... expect to get ignored or sued in a commercial setting.
This is why we can't have nice things, as most FOSS software is perpetually Beta ... Thus, nearly impossible to "clean" and deploy in a commercial setting due to coincidental contamination from the original IP rights holders (not the coder.) =3
I would recommend the masters for the coursework and practical background. A degree from CMU will get you through the pedigree filter at most jobs. I've hired plenty of CMU masters students and have always been happy with them.
Robotics itself does have many of the job archetypes you'd expect from a hardware/software heavy industry.
Regardless of the path, specialization is key. You might be (woefully incompletely) categorized as:
- systems folks (middleware, CUDA, distributed systems, hard C, C++, ROS-like, etc). Even things like CI/CD knowledge as applied to robotics can get you a long way.
- Vision (CNN/DL, but do not stop there. You should also have basic knowledge of tracking, homographies, and the old school CV stuff to make it work well in a system (as opposed to just scoring high on training data))
- Controls (PID and the bigger cousins - this is not my area)
- Tracking (EKF and the bigger cousins - in particular MH-EKF and please don't skimp on batch filters we have enough CPU to do that nowadays)
- Mapping & Prediction (often this is done so poorly that a person who has lots of practice building 2d/3d and semantic maps is a godsend, especially incorporating uncertainty - critically predicting future maps (+5-30s) is an amazing thing to have)
- Planning (99% of planning nowadays is trajectory planning which is kind of "just" figuring out from a map and destination what the signal is over time that goes to the control subsystem. But there's also route planning- where should we go an in what order, activity planning (what are good destinations and in what order), or even multi-agent planning (how do I get a bunch of agents to not just collide when trying to do individual activities))
- Proprioception (Sometimes just called Estimation) you'll want to be an expert in IMUs, Gyros, the EKF filter, using vision signals, magnetic signals, GPS, etc
- Exterioception (more general than Tracking) options are LIDAR, Radar, Bog-Standard Dispartiy, or any other sensor you can think of.
- Simulation - rapidly becoming extremely important or foundational to a good robotics program, especially one built on learning. This often has a lot of overlap with games programming so this can attract a certain type.
Roughly speaking, if you decide you like one of Sim, Controls, Planning (what kind?), Proprioception, Exterioception/mapping, Tracking, or Systems, you should tailor your coursework and projects to match.
Oh and I should mention - once you pick one of these, they are often very different when you are working on wheeled vehicles vs legged ones vs aircraft vs spacecraft vs plain-old-arms/ manipulators. But the skills are transferable so learn strong fundamentals.
Anti-recommendations:
- LLMs. I have heard they are going to be helpful, but are just hype so far. Skip for robotics AFAICT
- UI/UX. Everyone says they are going to invent the easiest-to-use automated system, just as soon as it "works". Spoiler alert, just like Akins laws of spacecraft design, if your system involves building a robot to build some other product, you are defacto a robotics company and will spend all your time making the robot work.
There are very few "Generalist" robotics positions -- you'll be competing with PhDs who are specialists but picked up enough experience doing their PhD to have generalist level skills. You want to be on a specific team doing a specific thing deeply. It's also the most fun to be on a specialized team!
Remember, there are two hard problems in robotics: Perception and Funding. So Simulation, Proprioception, Exterioception, Mapping, Prediction, esp Vision (nowadays) are hugely important to the success of a program. As a planning guy, the rest is "easy".
But, the moment you ship your first product, open your task tracker and add “Epic: Migrate off of ROS to a custom framework”.
Source: I’ve been working full time building a custom ROS replacement for a large company for several years. Results are good.
When robotics moves from the lab to the field, expensive certainty becomes more attractive than cheap flexibility.