keyan pishdadian

A software engineer's guide to the robotics industry

01 10 2022

I think I speak for many programmers when I say that the field of robotics has a special allure to it. I speculate it was something cultivated from years of ingesting far-fetched sci-fi media where robots play a central role in utopian (The Jetsons) or dystopian (The Terminator) alternate worlds. Or perhaps it has to do the promise that the technology can be (or already has been) generalized to transform many fields including logistics, manufacturing, agriculture, transportation, and medicine. Regardless, I know a lot of people want to learn more about robotics and maybe even find professional work in it. Yet a common sentiment I see from many programmers/software engineers/students is that it is hard to get into the field and they don't know where to start.

While not an expert in the topic, I've spent the better part of 2021 learning more about the fundamentals of robotics and about opportunities in industry. I think I have a decent high level understanding of the space at this point, so it felt appropriate to share some of what I've learned. My goal here is to give some context on why robotics companies are different than your typical software-as-a-service (SaaS) technology company, how roles at these companies are organized, and how a more traditional web-focused software engineer could get involved in the space.

Background

So before discussing the specifics of roles in industry, it is important to take a minute to talk about why robotics companies are so different from typical tech companies. Mostly this boils down to few facts:

These points alone explain why there just is not much investment in robotics relative to SaaS technology companies and why there are correspondingly fewer roles available in this area; these businesses will never have the huge profit margins and infinite scalability that pure software companies have (or claim they will have) and there are much fewer companies with funding. Even Boston Dynamics, which is arguably the most well known robotics company of all time, has changed hands three times and failed to turn meaningful profits for its over 29 years of existence.

These distinguishing features partly explain why software roles in robotics tend to pay much less than similar roles at pure software companies. Though I suspect that this is also because there is more interest from engineers in these opportunities, so there are engineers willing to take pay cuts in order to work on robotics-adjacent problems. Others have explored the topic of salary disparity between companies more than I have (see Dan Luu's great post on this) and there isn't a clear conclusion as to why the disparity exists, but it is worth mentioning that it is there.

Industry

To understand how roles are divided in robotics companies it helps to first consider that unlike a pure software endeavor there is a huge diversity in skills, knowledge, and expertise required to build a robotic system. Robotics is highly interdisciplinary field and software is only a part of the larger system. Because of the interdisciplinary nature of the field, there is much more specialization in robotics software jobs then in web companies. We'll take a look at some rough categories of roles that should align with many companies, with a focus on self-driving car companies in particular. The categories are organized subjectively from easiest to enter as a general software engineer to most difficult.

  1. General software engineering - A huge amount of roles actually focus on work that is similar to most other software engineering jobs. This means things like data infrastructure, machine learning tooling, security, internal tools, build and test systems, developer environments, and performance/optimization. Of course all of these have the overarching context of working on a robotics system, but there isn't too much different here that makes it difficult to transition into this area (save perhaps use of C++, but more on that later).
  2. Simulation - Large robotics systems have a need to create realistic environments to simulate their robot interacting with the real world and observing the effects of real physics without the obvious difficulties of running software in development on real dangerous robots. While some systems use tools like Gazebo, MuJoCo, or PyBullet directly, large companies will usually build their own simulation environments using 3D graphics software and physics engines. For example Unity is used for this purpose, also NVIDIA's Isaac Sim. For someone with a background or interest in games or graphics this can be a great place to try to break into the industry. This subarea also seems much more open to those without advanced degrees or experience in academia.
  3. Motion planning - The problem solved by these components is, given an understanding of the environment and the configuration we want a robot to achieve, what steps need to be taken to get there? This space has a large range of work and uses a lot of classical techniques like vehicle path planning, kinematics computation, and graph search (A*, RRT, etc). Though not trivial, I think it is possible to break into this area with self-study of specific motion planning topics and strong C++ skills, even without an advanced degree. At the same time, there is a lot of research effort on solving planning problems using newer techniques, namely deep learning and reinforcement learning. So at larger companies with more research budget there may be more academically oriented positions that are looking for PhDs and won't be possible to break into directly.
  4. Perception - The goal of a perception system is to perceive and understand the environment around it. Classically this means using techniques like Kalman filtering, particle filtering, and eventually SLAM. Like motion planning, this area is seeing a lot of progress from applying machine learning techniques to solve existing problems better. Much of the work in perception is being done by those with PhDs and is more research oriented than the other areas.
  5. Hardware - I put this last because for most readers this area will be very far from what you already know about. This is really a bunch of different subareas grouped together and I know the least about this area so I'll only briefly mention it. Basically this involves things like the physical computing devices being used, embedded systems programming, physical motors/actuators, camera/radar/LiDAR devices, and even materials engineering like creating better anti-fog coatings for cameras.

Recommendations

  1. Practice C++ - Most robotics is done in C++. Certainly there are areas where Python (data analysis, ML, perception) and even Javascript (internal tools, simulation) are used, but you'll probably need to know some C++ anyways. At the very least expect to do some interviews in C++. Unless you are interviewing for a specific specialized area you'll want to be able to solve typical Leetcode style questions in C++ and know common Standard Template Library (STL) usage. This is very subjective, but my experience has been that C++ specialists (whom you will run into in robotics) tend to use C++ knowledge as a form of gatekeeping so you will do well to start getting more comfortable with the language and the lower level details of programming that it exposes you to.
  2. Understand pub/sub robotic systems architecture - Although it isn't the only architecture used, robotic systems are often based on the publish-subscribe architecture. Understanding this message passing architecture and why it makes sense for robotic systems is useful knowledge that will help in understanding larger systems. One way to gain this knowledge is by learning about the basics of the ROS ecosystem (namely nodes/topics/services) by doing the introductory tutorials. But few companies use ROS itself, so it isn't a requirement to go deep on it unless you end up having to use it for your work.
  3. Align the skills you already have with something above - For most of you this means strengthening your C++ skills then targeting a general software engineering role at a robotics company. Although at first you may be doing standard software engineering work similar to your prior experience, over time you can try to shift the balance from general software engineering and more to robotics. Though ultimately your success in doing this may largely a matter of luck especially in the areas with a more academic bent like perception.

Notes

Thanks to Adam Fishman for helping me learn about robotics and for his edits to this post.

This entry was tagged as robots c++ av ai ml deep learning self-driving