Not in this case. With SpaceX they also need high (de-entry, Mach heating) and low temperature (cryo fuel & oxygen) resistance but in the case of Boom the surface won’t heat enough to need high temp materials.
That said, I’m not sure their choice of materials is the good one for a startup.
In interaction with anything rigid (or even deformable), position control does not mean anything. Force (or torque) control defines the actual physical interaction.
We actually have very cheap and pretty powerful position-controlled actuators (hobby servo motors). Attach any kind of spring and displacement measurement device (potentiometer, hall sensor, optical, LVDT, etc) and voila, instant torque controlled actuator.
You can look up Series Elastic Actuators for more info or use this article as guidance (any spring will do as long as the force range and spring constant is adequate).
Sad to hear, I demoed a system with a Tobii sensor and it performed very well (even with my glasses). We were wondering about the effect of the constant IR blasts (are they continuous or pulsing?), thanks for the input.
I work for a company that makes robot arms for assistive purposes (Kinova) so I have some insight to share.
1st a voice setup with Alexa or similar can really help.
With regards to phone use, some of our users have an attachment to put the phone close to their head and use their nose to "click/select" (they can move their head).
Eye tracking technology is really impressive these days (can be as fast as using a mouse). I've recently demoed a system with a Tobii sensor (https://www.tobii.com/) that was hooked up to a laptop, very impressive when combined with appropriate software (it handles scrolling, keyboard shortcuts, etc in a custom interface). I'm not sure with regards to phone/tablet use how well they integrate.
The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. You tended not to use vast library stacks, you went close to the metal and you coded in languages like Assembler, COBOL or FORTRAN. I/O was often run through specialised co-processors (such as IBM's channel processors) and the terminals could sometimes help too.
I have friends who have been looking after legacy applications for an airline running on Unisys. The core apps for reservation, Cargo booking and weight/balance were written in FORTRAN. In recent times, the front end was written in Java to give web access. They tried to rewrite the core apps but it was impossible to do so and get the performance.
One point I noticed not mentioned yet is that the images used for training are only 64x64! In the original google "grasping" research, the images were 472 × 472, 54 times bigger! I think they are looking for "minimum visual information" required to trigger the required learning. This will help in mobile applications (ie: robotics, smartphones, etc) where processing power is severely limited.
I think this is mainly a "data" challege, how does Udacity plan on gaining an upper hand on this, especially with competitors like Uber and Tesla which gather data exponentially with each new ride/car sold?
In both of those examples likely the blame is on the company and not the worker.
In Joe's case, any aluminium dust may stick on the broom - solution, two seperate 20$ brooms, problem solved. Nevermind aluminum and iron shaving take a significant heat source to trigger, at what part of the factory was this corner cut?
In Roy's case, it is a problem with the process, not with the worker. 1" drill bits get dulled, and are very hard to actually break. Was the jig properly set up? Was Roy involved in setting the process up and understand tolerances and bolt holes (including adding a go/nogo tool if required). These are the questions that need answering before passing the blame onto the minimum wage employee.
That said, I’m not sure their choice of materials is the good one for a startup.