[sapphireblue]

>The skills for building a robot are quite different from the skills for building "classical" software.

I'd object that on the contrary, arduino and http://www.espruino.com/ require mostly the same skills (plus some basic maker-tier hardware skills which are easy to gain). For example Espruino is programmed in javascript. I have bought ESP8266 boards for 3.5$ each and with espruino firmware that gives me a wifi-enabled computer for IoT or smart home tasks. I have done some simple smart home projects that provide a web interface (hosted on espruino!) to some functionality.

Of course there are robotics specifics - computer vision, motion planning (also forward, inverse kinematics), but these functions in principle could be hidden behind an opaque DOM-like APIs, while being implemented in a very advanced manner (e.g. trained deep learning models for vision, best SLAM algorithms, best planning algorithms). Just like the browser doesn't require you to draw webpages pixel-by-pixel on raw framebuffer and provides you with fonts, block model, events etc.

>For example for classical software one can do correctness proofs/analysis, while for robots one can only do empirical tests or correctness proofs relative to a strongly abstracted world model.

Objection #1: Almost nobody does correctness proofs in application and even in system software (e.g. the linux kernel), and yet these software projects work quite well, for example it is known that SpaceX uses Linux (with various patches) as a platform for its in Dragon and Falcon. In fact correctness proofs are mostly done by hardware companies, for some functional blocks, and maybe by the military. If you are interested in exploring this question further you can read "How did software get so reliable without proof?" by C.A.R. Hoare [1].

Objection #2: Proofs of correctness in logical or probabilistic sense are being done for various real systems by Cyber-Physical Systems community and by Machine Learning community.

>So in other words: Applying their (existing) skills into that direction would not have much value.

I still think that given good blackbox abstractions and familiar API much could be done. We can see beginning of it with maker community, arduinos and espruinos. More should be possible.

>but who of this group is really willing (and can afford) to do so?

Myself !

I think programmers, investors and customers should be less averse to hardware. We could live much more pleasantly if it were true. Underautomated status-quo is daunting.

1. https://www.gwern.net/docs/math/1996-hoare.pdf

[riboflava]

As soon as you have to buy something that takes up physical space, the "skills", or maybe better put the "mindset", becomes quite different. I don't think I can explain it very well. In principle someone who can understand a flow diagram (which is, to only mildly exaggerate, all a circuit diagram is) and master the complexity of getting a web application published online should be able to do what you did with the $3.50 board. They almost certainly could do everything in a short amount of time at a workshop with all the hardware provided and a printout of instructions. But once they're home, without a similar set of instructions for "buy this here, do this, do that, to accomplish this" it's unlikely you're going to see much robotic/smart-home creativity even after a workshop. Meanwhile unlimited complexity and creation can be had in the web app realm without having to leave the comfort of your keyboard, or even having to buy anything.

I just remembered this post which I think helps better capture some of what I'm talking about: https://plusbryan.com/its-just-wood But I think there's something else besides avoiding things that are mysterious. I think it has something to do with the physicality of the thing. At least something else is needed to understand the weird reluctance with working with hardware that a lot of software-only people have, who differently from the general public (who can't even use their computers) are sharp enough to battle with mind blowing complexity and solving mysteries of bugs or how new languages or APIs work every day behind their screens.

[petra]

Abstraction for robots isn't a unique idea(see ROS.org) . And i think it's part of the reason we see growth in robots sold for businesses. But The constraints(cost/size/safety/envirnment complexity) are so much bigger in the home - so probably the tech isn't yet mature enough.