Thoughts on 2 Years as a Remote Robotics Consultant
msadowski.github.io
msadowski.github.io
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)
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.
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.
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.
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.
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.
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.
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)?
1) How's the day going? 2) Interesting updates, wins, observations, challenges from that week. 3) What challenges are coming up next week, and how to solve them? 4) What's a proud moment from this week? (We wanted to add a touch of positivity and recognizing successes.) 5) Open discussion - Whatever's on your mind lately, want feedback on, etc.
There's accountability but not strict homework.
Second of all, I am curious to the specific nature of the work that you do 80% of the time.
Do you write software for off-the-shelf robots? Do you add components to off-the-shelf robots? Do you design the components AND write the software?
Is there any design from scratch for things like having a robot that does a very specific task?
Why aren't you starting a Roomba competitor? (You don't have to answer this one...or any of these really, but I am genuinely curious in a way)
* We have a working robot now, and this robot will need to perform very repeatable tasks by driving through waypoints. Let's design a state machine that would do that. * We need to make a system for outdoor mapping using a LiDAR. Can you suggest off the shelf LiDAR and localization system that we could use and then integrate everything in ROS? * My robot has misconfigured local navigation and it's not listening. Could you have a look? * The rangefinder we are using on the drone is not performing well. Can you look through the logs and help us troubleshoot it?
Quite often the work requires me to integrate existing software. ROS (Robot Operating System)is amazing for this, as it has lots of open source packages, where some of them work really well out of the box.
I rarely add anything to off-the shelf robots. Most of my clients are making their own robots and want help with architecting/programming these systems. I don't design any components (I don't have almost any experience with electronics). I can do some simple CAD design if needed but my clients are better of hiring someone for CAD anyway.
I'm not sure what do you mean by robot designs from scratch - if you mean robots that you could build and program yourself then yes, there are plenty! I've listed some of the ones I liked the most in Awesome Weekly Robotics (https://github.com/msadowski/awesome-weekly-robotics).
Currently I don't think I would try to compete with someone like Roomba. It would take huge amount of money to create robots like these at scale for the low price of these units. Also all the electronics need to be certified (at least with a CE mark, but I expect something else would also be needed). Rarely one person can pull something like this off from A to Z.
If I'm ever to start a company I would like to try to grow it organically. If I ever get a really good idea I'll definitely give it a shot.
Humanoid robots sound super difficult. I don't know how many companies might be working on humanoids so I'd advise you to try to look for something relatively broad. For example mobile robots and drones have been working quite well for me, but hardware wise I'd expect them to be much simpler than humanoids.
A portfolio would be a good thing to have, though, thanks for the suggestion!
Really, I can't grasp the absurdity of some people's mind sometimes and wonder about their morality (UpWorks in this case, not yours. Just to be clear.). Not everything that maybe is technically doable is also ethical. If you comply to such practices, I think it will have an impact on your self-esteem and self-respect. Just try to imagine how other fellow hackers, developers or software engineers you admire would think of the idea getting screenshot'ed every other minute in order to control them.
On one occasion I had a client not pay, but thanks to the Upwork protection I got paid quickly and then they resolved it with the client.
If I was doing a similar service as UpWork and wanted to offer a kind of payment protection I'm not sure how I would go about that. I'm thinking maybe something like a code diff week-after-week sent to the client but at the same time not everything can be diffed (especially countless meetings with clients). Would you have some ideas?
As for UpWork it doesn't make it any better (for me) if their payment protection is bound to this kind of screenshot surveillance. If they don't offer a payment protection in every* case, I wonder why they exist in the first place other than talking a good cut from your daily rate and making everything more complicated for both the software contractor and the client.
Also I take projects outside of Upwork, however, I don't get as much traction outside of that platform, and as much as I would like to live off direct contracts it doesn't seem it will happen anytime soon.
There's a fairly large mentality shift between salary work and contract work. When you're salaried, you're supposed to work eight hours yes - on paper. Really it's generally accepted people work 4-6 hours a day, with the rest being filled with lunch break or internet browsing or doing online chores or whatever. There is a tacit understanding between employer and employee about this, so any steps by the employer to monitor daytime computer usage is understandably seen as breaching this understanding in a misguided attempt to get employees to work more hours - or exposing the employee to arbitrary punishment if management wants to selectively undermine them for breaking rules that everyone breaks.
It's different when you're contracted per hour. When you carve out an hour for a client, it's game time. No faffing around on Facebook, no checking financial statements. You do the work. Does this mean you have to work a full 8 hours? Absolutely not. Just do part-time contracts to fill up as many hours as you want to work, then charge more per hour. Your hourly contract rate will be much more (2x or more) your hourly salaried rate anyway. So, since you're actually factually working during the contracted hours, I don't really mind whatever desktop screenshot system they want to use.
On another note: actually working 40 hours a week basically sucks. Let's acknowledge how good a deal we have as full-time tech employees and show solidarity to our brothers & sisters who do full-time shift work. Pushing full-time work down to 32 hours a week or less is a very worthy goal.
Second, there is no correlation between the amount of ASCII chars outputted per hour and the productivity/net gain for the client (at least for the type of work I'm doing for whatever that matters). Sometimes I do have to think hard about a problem for a longer period of time, maybe executing on a few ideas before finally presenting and motivating a solution I came up with for a given problem. That doesn't mean my computer desktop looked _productive_ the whole time. In fact much of the important work maybe even done on a sheet of paper.
> There is a tacit understanding between employer and employee about this, so any steps by the employer to monitor daytime computer usage is understandably seen as breaching this understanding in a misguided attempt to get employees to work more hours - or exposing the employee to arbitrary punishment if management wants to selectively undermine them for breaking rules that everyone breaks.
I think employee monitoring is a lot more common than you think. Especially so outside of tech but I know of some very big tech companies we're all intimately familiar with that record basically everything that happens on their employees computers. Do they actively monitor everyone to see that they're putting in 40 hours a week? Not really. Does HR take a looksie when a manager comes and asks for help firing an employee? What do you think?
Overbilling is not just encouraged, it's even required, at some shops. That kind of culture obviously makes clients want more oversight and documentation.