4 ms·

Why is building robots so much more expensive than software ? Software is complex. The main tools to create software cheaper are abstraction and reuse. Can't

by petra 8y ago

Why is building robots so much more expensive than software ? Software is complex. The main tools to create software cheaper are abstraction and reuse. Can't those be available to new robotics startups ? Is building a robot from standard components possible ? or using some sort of software based mechanical/robotic design tool, similar to the procedural modelling 3d graphic designers are starting to use ?

SwellJoe 8y ago
"Software is complex. The main tools to create software cheaper are abstraction and reuse." 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.
yingw787 8y ago
I don't work in robotics, but from my electrical engineering degree, I could hazard a guess: - 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.
- jchallis 8y ago
  What is an enterprise Karen?
  - yingw787 8y ago
    So this is a Karen: "44. mother of three. blonde. owns a volvo. annoying as hell. wears acrylics 24/7. currently at your workplace speaking to your manager." https://www.urbandictionary.com/define.php?term=karen https://www.urbandictionary.com/define.php?term=karen I used "enterprise Karen" as a corporate personification of "Karen".
matthewmacleod 8y ago
It's pretty straightforward – building a robot is like building a complex bit of software, except you have to build the complex software and a whole robot too :) 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!)
RcouF1uZ4gsC 8y ago
Another big issue that complicates stuff is safety. In general, most software bugs don't have the ability to cause serious physical harm to a human. A bug in the robot software can cause physical harm (depending on the size and function of the robot, of course). Because of this, the software also is more expensive to write.

by petra 8y ago

SwellJoe 8y ago

"Software is complex. The main tools to create software cheaper are abstraction and reuse." 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.

yingw787 8y ago

I don't work in robotics, but from my electrical engineering degree, I could hazard a guess: - 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.

jchallis 8y ago
What is an enterprise Karen?
- yingw787 8y ago
  So this is a Karen: "44. mother of three. blonde. owns a volvo. annoying as hell. wears acrylics 24/7. currently at your workplace speaking to your manager." https://www.urbandictionary.com/define.php?term=karen https://www.urbandictionary.com/define.php?term=karen I used "enterprise Karen" as a corporate personification of "Karen".

matthewmacleod 8y ago

It's pretty straightforward – building a robot is like building a complex bit of software, except you have to build the complex software and a whole robot too :) 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!)

RcouF1uZ4gsC 8y ago

Another big issue that complicates stuff is safety. In general, most software bugs don't have the ability to cause serious physical harm to a human. A bug in the robot software can cause physical harm (depending on the size and function of the robot, of course). Because of this, the software also is more expensive to write.