I've put this article together and thought some of the points I'm making might be relevant for you - especially these about remote work and self-employment. If you have any questions or need some tips then feel free to comment here or send me an e-mail (you'll find it in my profile description)
Not a fan of that fake soldier-robot video that keeps popping up on HN. I think it misrepresents the robotics industry and it's horribly violent.
I love the idea of ROS2 but the advice I'm usually giving clients is to only look into it as a part of their R&D and to expect to be very early adopters and therefore most likely needing to fix multiple issues that will inevitably come up.
For the companies that have a single product they are focusing on and that they want to push out of the door as quickly as possible with minimum R&D budget I suggest sticking with ROS Melodic (afaik more package support Melodic than Noetic) but I also recommend them to keep an eye out on ROS2 and switching to it as soon as it makes sense for them.
Right now I'm basing almost all my view on ROS2 on Michael Ferguson's blog (https://www.robotandchisel.com/) and particularly this article: https://www.robotandchisel.com/2020/07/29/five-things-ros2/.
When I will finally start experimenting with ROS2 I'm going to start with Autoware course: https://www.youtube.com/watch?v=XTmlhvlmcf8
About the fake soldier-robot video: I think it's a good satire and I hope we will never get to anything similar to this in real life. As you probably noticed from the article I'm not a fan of military robotics.
1. Why would you? Having a bunch of nodes communicating with each other makes pretty graphs for a dissertation, but if you really just want to get something done, calling a library is much easier than messing with launch files and dealing with message passing and asynchronous behaviour. It brings in a ton of new complexity to solve issues which are only complicated to people who don't know how C++ threads or coordinate systems or other robotics bread and butter work. It reminds me of that quip, "You had a problem and tried to solve it with ROS, now you have 2 problems."
2. ROS is designed as a framework, not a library. This means that it's very hard to pick and choose the pieces you like, rather it is all or nothing. It also ends up with a lot of lock-in, and as a result code written for ROS is very hard to take into another context.
3. A lot of ROS tries to just 'make it work', regardless of if things are only partially configured, misconfigured, etc. If this is a one-off proof of concept then this is fine. If someone dies because things are misconfigured, I want the tools to complain very, very loudly, and preferably not work at all.
4. Unit testing in ROS environments is a pain. It is more oriented around doing simulation, but the simulation is the top level thing. This means something like business logic that depends on the simulation working in a certain way, or on the outputs of the simulation, is hard to verify the correctness of. This is unacceptable in a business environment.
5. Tooling. Why does it need its own package manager, its own build system? It even has its own runtime dependency analysis. Just use CMake, and the OS tools. Please please please. Deployment is such a pain!
Anyways this is just off the top of my head. Consider the later points, and then go back to the first one, of "Why should industry use it?" To me, there isn't sufficient motivation for the added complexity ROS brings.
From a business perspective, ROS is an open framework, which is a plus only if you are in a specific perspective. Many robotics company still think in terms of walled gardens and hope to sell full solutions to clients, not have to support just a module in a complex environment. I would say that what ROS is lacking is a competitive marketing advantage. If ROS was promoting its brand and offering access to clients for companies that support it, it would help a lot its adoption.
In reality, industry generally doesn't care about nominally innovative academic approaches to robotics, or even very much about hedging their lock-in with a vendor-neutral codebase, they just buy something that already works and use the software tools from the hardware vendor.
Source: I went to a ROS conference last year and there was ~nobody using it in industry. The amount of money they were spending on hardware was staggering. I run a robotics company, we don't use ROS.
How did you get started? How did you market yourself in the beginning?
Any tips for a computer scientist with robotics background but who has been working in enterprise software for 8 years?
I started by doing two projects on Upwork while working a full time job, then I decided to quit without any projects lined up and was very lucky to find a long term project on Upwork before my 1 month notice period finished.
Marketing wise at the beginning it was just Upwork. Shortly after I started I tried writing technical posts for my blog (mostly related to ROS and some hardware testing/reviews). Around that time I also started Weekly Robotics newsletter (https://weeklyrobotics.com/) but so far it brought only one client onboard but it's a great way to show potential clients that I'm following what's going on in the industry.
When it comes to tips: I would suggest learning ROS - if you have experience in software it should be quite easy for you but expect some learning curve. Then I would suggest doing some projects like integrating SLAM and obstacle avoidance on a mobile robot, ideally with a physical platform.
If I were you I would treat it as a hobby in the beginning and try to have fun and if you find a niche that truly sparks your interest it might be worth specializing in it.
I've talked to a least one startup who was open to hiring remote workers, their justification being that remote access to robots was important to have setup correctly anyways to help supporting clients without traveling. Are you afraid of your employment opportunities if the consultancy doesn't work out (even though it seems to be doing very well now)?
Geneva is crazy expensive and this is the main reason why I'm moving to Prague in two weeks!
I live in a cheap countryside in Japan, doing remote consulting for deep learning and robotics. Your post was really interesting and I'll look into Upwork and angel.co. So far I have found my project in the old school way: go to events, talk with people, but mostly use pre-existing connections. However, since the pandemic, I try to avoid meetings and the projects are a bit harder to find (I have been blessed in the last few years that projects seemed to find me rather than the opposite)
What kind of events do you participate in? I'm having trouble finding much events here, and the only outlet I know for this purpose is MLT.
Cultivate friends and contacts that's my main advice.
When architecting a system from scratch it's a bit easier since you don't deal with legacy systems at the beginning. Then when doing specifications I tend to divide the system into parts: actuation, sensing, logic. Then depending on the application I try to choose the best systems for doing the job.
For example if the robot is meant to be used in an agricultural context you know you need some kind of global localization (RTK GPS is probably best), usually you will need an IMU as well (this one will depend on the platform, budget etc). Then if you are expecting some occlusion (e.g. treetops) you might start thinking on what will happen to the GPS signal and what other sensors to add.
I do similar considerations for the actuators and software logic, trying to think of all possible scenario in a representative environment. From my experience if the work is fully remote it takes between 30 minutes to 1 hour just to discuss the environment, allowing me then to propose the best systems for the job.
In case of the occlusion - with rtk gps setup you know how good is the quality of your signal and then you can adjust some of your parameters to trust gps less when doing sensor fusion.