Why Is It So Hard to Build Profitable Robot Companies?

Here's an interesting fact. Most people think of forklifts as being stronger than people, and that we use them to lift stuff that people can't. That's true. But, what most people don't think about is why it can lift stuff like that. Hydraulic multiplication provides the power to actually do the lifting, but, a human shaped robot with the same hydraulics couldn't. Most forklifts weight about 3x the weight of a car and are mostly filled with lead. The same will go for robots. the form factor of improving human strength doesn't really benefit from changing the strength to weight ratio, it benefits from scaling both.

edit: as context, the average forklift is so heavy that when put on a trailer they exceed the tow rating of 1500-class pickup.

If so, could they not voluntarily do that now, without robots?

There are many companies doing this kind of thing in various environments. Doing it at the scale of a city, like calling an Uber/Lyft, is probably a few years out, at least. Maybe in major cities taking the place of bike couriers it'll come sooner, I dunno.

"Not to mention the legal implications of on-demand bots as drug mules or bomb delivery..."

UPS and FedEx and the USPS have that problem.

Robots have all of the software complexity (more software than most software startups I've been involved in), plus hardware complexity.

Software doesn't have a supply chain to worry about. Software doesn't have to deal with an unknown environmental issue that makes the screen go black, or a vendor that started shipping you a different part while calling it the same part, or a sales pipeline that involves shipping around tens of thousands of dollars worth of hardware and staff to set it up and demo it, etc.

So, a software startup has to solve software problems. A robotics startup has to solve software problems on top of everything else.

"Is building a robot from standard components possible?"

Sure. Most robots in the market are mostly built from standard components with a few custom built bits for personality or to solve specific problems.

"or using some sort of software based mechanical/robotic design tool, similar to the procedural model 3d graphic designers are starting to use?"

Sure, there are tools for designing hardware. Robot companies use those tools.

But, it doesn't make building and shipping out multi-thousand dollar devices as easy/cheap as shipping software.

- Software becomes much harder if you have to interface with hardware. You mess up software, you edit and then recompile/rerun. You mess up hardware, you need to buy a new copy of the hardware. Imagine if every time you wrote a bug or compiled a dependency with a bug, you need to pay $5 to somebody. If somebody else's software caused an error on a piece of critical hardware, your hardware may break too (e.g. car crash). And good hardware costs a ton of money. A Dynamixel servo costs something like $500, for a motor that's maybe 8 inches cubed or less, but if you use a cheap motor from China your precision over time will suck and software-based closed-feedback loops aren't as good as good hardware. So maybe you decide to do simulations, and you write a hardware emulator to load your software on. That costs a lot of money too, and doesn't and never will mimic hardware in all cases.

- Software for robotics is pretty low-level. You may need to write drivers for special hardware you develop, or you may need to rewrite drivers if proprietary drivers don't do the job for some reason. Drivers are if not hard to write, then a long slog to write (I don't write drivers). You need to make sure your software is highly performant, lightweight, and fault-tolerant. Maybe you need a real-time operating system, or you need to fork the Linux kernel and rip out bits and pieces (I heard somewhere SpaceX does this for their avionics, because they didn't want to deal with an RTOS). There is no let-it-crash philosophy. There may be no concurrency abstractions that are performant enough besides threading/locking primitives. There's the added complexity of failover that you plan into your design. You can't live without any of these most likely, because otherwise your customers may not live at all.

- By the time you master all the tools you need to build a successful robotics company, you haven't changed the system, the system has changed you. You accept the truth that good hardware is hard to make, good low-level software is hard to make, and great insurance plans are expensive. You're a Windows guy now because you use SolidWorks to design parts, and you can't be bothered to make a startup to rewrite SolidWorks for Linux because it's hard to get the physics/math background to reproduce even a part of SolidWork's functionality and user experience (which is a lot, CFD/FEA/etc). You deal with manufacturers who are perfectly happy with older tech because it works and because newer stuff always comes with risk. Your customers are enterprise Karens who shatter your roadmaps and don't care about your dreams.

This is a (possibly inaccurate) tasting of why building a hardware company is hard. I have the highest respect for those who do.

A robot platform can be a complex bit of hardware depending of the use case – it might be mobile, in an open/uncontrolled environment, using complex or expensive sensors, needs to be physically robust etc.

Now, many of those can be built from generic components – off-the-shelf controller boards, sensors etc. – but there's a lot of complexity in getting everything to reliably connect to and talk to everything else. Since there are far fewer robotics projects out there than software projects, there are also fewer of those "abstract components" in the first place – and physical requirements can mean it's harder to use them for particular designs.

Then there's the software layer. Again, depending on the use-case, this can be challenging - it can involve combining lots of sensor data, making decisions, planning motion, and so on. There are established algorithms and some reusable tools that can make this easier, but a lot of the magic is specific to individual projects. User interfaces can also be complex – building a reliable conversational UI is a project in itself, and if you're building a robot which interacts with humans, it needs to do this as well as all the robot stuff.

(FWIW I am working at a robotics startup right now, and every day is quite a challenge!)

The mainframe market might be a reasonable predictive model to look at (where there were a handful of dominant players, a few software companies around them, and hordes of service contractors who maintained them and helped companies accomplish their goals with the hardware available), at least until general purpose robots get cheap enough to look more like PCs. They're getting pretty close to that already, though, so maybe we'll skip right over the mainframe stage and right into personal robotics. I dunno. Depends how fast prices come down...I don't think the pricing works the same as PCs, as there is no "Moore's law" equivalent for robotics components. The price trends downward, and performance trends upward, but not at a multiplicative rate.

As it stands for now, though, robots doing complicated things are generally working as a team with computation in the cloud, so the PC "buy it and own it" model can't work. Robots, at least the kind that are doing real work, are purchased or leased as a hardware-plus-service bundle (again, kinda like mainframes).

So I have thought about this a lot, and I even started and failed an ambitious robotics company, and I feel like a good niche product that could make a profitable company is self-cleaning litter boxes.

No, it won't be a multi-billion dollar company (at least not just with that product), but there is definitely a market for this and the current products are underwhelming. And technologically, it is about as approachable an unsolved robotics problem as you can find.

Here's the competition.

https://thewirecutter.com/reviews/best-automatic-cat-litter-...

A truly generic robot is probably several steps away and I think the correct niche for starting to approach that market appliance would be a human-scale (and moving) tele-operated human-shaped robot body. That would be useful for all of the places that humans are expected to navigate and particularly useful for situations involving danger.

You have to look a little higher up the complexity scale, for roles that require low skill but high something else (so humans are hard to find to fill the role). e.g. say you need deliveries in a building, or even at the neighborhood or city-block level. It's repetitive, boring, work that is hard to hire for but can plausibly be done by a robot. It's hard to hire for because it is repetitive, boring, and requires a level of trust and reliability that a low-paying job doesn't really inspire in human workers. Delivery is a huge industry, when you consider all the scales at which delivery takes place (from tube systems and intraoffice mail systems on up to freight on trucks, trains, and boats), which could support dozens of designs of robot, and some of them are probably most usefully shaped like and acting like what we think of when we think "robot".

"Delivery robot" is still pretty special purpose, I guess...you could say it's a dishwasher, but it's a very smart, very expensive, dishwasher. It needs a lot of skills to do the job, and the closer it gets to the human it is delivering to, the more it probably should look like a friendly humanoid(ish) "robot" rather than like a self-driving truck (of varying sizes, based on role). A truck can't navigate elevators and doors, for example.

When Tesla tried to create the world's most automated assembly line for the Model 3, they learned the hard way why Toyota and others have abandoned the idea: complex automated systems are, perhaps necessarily, tightly coupled and complicated. For Tesla, this led to cascading errors and insurmountable "debugging" challenges. Eventually it became evident to Tesla and Musk that, even at first-world prices, human workers were the better buy. [https://www.bloomberg.com/news/articles/2018-04-13/musk-tips...]

When you think about it, the work involved in building software systems may only be economically justifiable right now because computers can perform certain tasks many orders of magnitude more efficiently than humans can. In the physical realm, the differences shrink tremendously (or even reverse), making it far more difficult to compete with human workers.

To your point, in India it is cheaper to have a human being do that work than a machine, much less a robot. It will take a long time for the economics of robots to catch up on really cheap labor in the developing world.

But are these pain points for a sufficient number of people? I can understand robots that could do these tasks would be a godsend for disabled people and the very elderly, but those are small markets. The vast majority of able bodied people just fold their own clothes and do their own laundry. It’s easy and takes minutes. I don’t think I’d even pay $100 for a robot that could fold clothes.

You just ignored that the washing machine itself is a special purpose robot. Same with the dishwasher. Some progress already happened.

Go back a generation or two in the US, or live like the majority of people in the world, and you'd notice that laundry and dishes are very usefully semi-automated today.

The number one blind-spot for robotics projects is ignoring the availability of cheap (and often illegal) immigrant labor in most major locales. Western programmers think of most physical labor as abhorrent but working in a laundry in Western countries is often much better paid and comfortable than the alternatives back home. Plus your children typically have access to much higher education and opportunities.

Whoever develops a robot (or robots) that can perform those tasks is going to be very rich.

There are of course even lower cost robot arms, ~$100 toys, $1000 educational platforms etc. They just don't have the precision or power needed for industrial or research applications.

"Alexa, get me a beer!" Actually, a device or a couple of combined devices which could enable that gracefully might sell pretty well. (Some kind of fridge which can dispense canned beverages as the 2nd device? This could be adapted from vending machines.)

However, specific people producing online media very much are. Many of these media people are effectively social media influencers, so marketing to them, specifically, might be a viable strategy providing access to a larger market. This is a population for whom making silicone impressions of their intimate body parts is just business as usual for producing merch. Products incorporating deep learning data based on their "performances" wouldn't be so big a step.

Possibly.

o_O

In general, I think the hardware business is hard for all the reasons you mention. Or better stated, the hardware business has characteristics that make it difficult to get right the first time (more important in hardware than software, I’d argue) and scale. It’s not inconceivable for a single (or a small team) to build a useful software product that makes money (several successful mobile apps, companies like 37signals, etc.). It’s difficult for me to think of similar hardware analogs (I’d love examples!). This isn’t to say that scaling software—building companies like Google–isn’t incredibly hard. It is. But for a hardware company to even have a chance, it needs a minimum scale threshold from the very get-go (besides all the other things that any business needs – a useful product, luck, etc.).

I used to work for a large aerospace company in the early/mid 2000s, and the products we built were useful, and amazing (hunks of metal weighing tens or even hundreds of thousands of pounds flying in the air transporting people). I was absolutely awestruck by the fact that upcoming companies like Google and Facebook (which were “just websites” in my then-naive worldview) had fewer people, and made way more money than us.

If you showed a modern dish washer to Karel Kapek I bet he would have called it a robot.

I think robot implies complicated actions that are reprogramable to perform a wider array of functions.