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.
