my bg: I have done a few robotics projects: a warehouse robot and a surgical arm.
About ROS: that's fair, but to be fair, it was an ambitious first attempt that began hmm decades ago? and has some great parts (the 3d simulator, the robot construction, the python interface) and some less great parts (bags). It's a great place to make the next generation from.
Unfortunately, the scope of robot design pain is even larger than TFA! the definition of "robot" is so broad it includes factory robots with hardly any sensor requirements and intelligence, as well as devices with intense vision input, or even large network requirements, micro devices, stationary devices, mobile truck-like things, robotic systems composed of numerous robots, humanoids, etc.
ROS established concepts that pervade robotics. There is no non-ros-like robotics framework. Every _serious_ ROS alternative I've worked with has a similar "Markup as programming" problem because everyone has embraced the "Extensible node" paradigm (aka component based architecture). Configuring a system becomes half the battle. Even Space and DoD have this. I am not convinced ROS saw this coming, or knew about it prior, when they designed their "Operating system". real time embedded systems have a longish history of using message passing between tasks, but still, not convinced.
My top three wishes for ROS are:
* Get better interop with other messaging systems. I can build an entire business on HTTP POST/GET, but I need your very-limited rosmsg definition for this robot, this message archive, this wire definition? (not that I want HTTP but you get it).
* Provide a roadmap for hardening. Ros-mil, ros-space, ros-2, etc all seem like steps in different paths toward the same goal. Tell people to stop trying to use a rosgraph across multiple platforms. Kill ROCOS. Teach the industry to use better tools! We have better distributed systems now.
* Never change. Ironically, the fact that ros is so mushy and accessible means that really-high quality robotics research often is ROS-first. (eth zurich for example!). I'm not sure making it commercializable, hard, and interoperable will accomplish that.
Throughout grad school I used ROS and whether the robot demo worked on the day it was supposed to was essentially a coin flip.
In industry I use protobuf, Hydra for config management, few async processes and god does it make a sea of difference. It seems like other companies are catching up, I see more and more companies avoiding ROS these days!
I've hired a few roboticists and my advice is always the same - if you're a new grad, knowing ROS and having strong C++, ROS, and OpenCV experience will give you a leg up.
After that, the most common things new grads want to work on are path planning or computer vision. These are high-ish demand but usually go to grad students or senior folks. But you can be an excellent candidate by knowing about them and how to integrate and test them. Path planning has several open source libraries and implementations. Do a comparison on several maps. Pull game maps and try em out. Anything. For AI/CV, there's similarly many applications.
The key for non-PhDs is to know the existing stuff well. Even if you're a PhD, you'll spend less than 1% of your time doing anything interesting / researchy, and will mostly be using existing codebases for everything. Very few research-primary positions exist.
How is experience meant to be demonstrated? Do you do a home project and put it at the top of your resume?
Edit: I don't mean to be pedantic; I'm just ~6 years out of touch here. I did a SLAM-in-quadcopter and force-controlled-6dof-arm in undergrad, and those projects are being correctly ignored by hiring managers as "he's since forgotten this stuff" today.
About ROS: that's fair, but to be fair, it was an ambitious first attempt that began hmm decades ago? and has some great parts (the 3d simulator, the robot construction, the python interface) and some less great parts (bags). It's a great place to make the next generation from.
Unfortunately, the scope of robot design pain is even larger than TFA! the definition of "robot" is so broad it includes factory robots with hardly any sensor requirements and intelligence, as well as devices with intense vision input, or even large network requirements, micro devices, stationary devices, mobile truck-like things, robotic systems composed of numerous robots, humanoids, etc.