I'm in agreement regarding more. But I think it also says something about clear messaging and how many people struggle with that. It's actually consistent with YC advice. They say most pitches fail to even convey what the hell they are doing and what problem they are solving. I suspect a language model will get that part across rather well.
Nice idea, but somehow not too much fun when you constantly lose. I think a better game mechanism might be how many correct vs. incorrect ones you can get in a time period.
I'm working on an open-source platform for full-stack robotics (called Transitive) and this is on my roadmap, but I haven't started on that piece yet. Like you I've seen the pain though. Airbotics.io is developing a CI/CD pipeline for robotics and I could imagine they'd be interested in helping build a solution for what you are interested in as well. Would be happy to chat and potentially collaborate.
The robot's manufacturer, of course, if the surgical robot was acting autonomously, i.e., unsupervised, as the title suggests. AI-trained or hard-coded doesn't matter. It's the manufacturer's responsibility to ensure their robots are safe or, when they cannot guarantee safety, abort and ask for help. This does not mean that surgery success has to 100% -- that's a different matter. But in the course of it's operation it shouldn't cause undue harm.
Are you aware that ros service calls are RPCs (not based on pub/sub like actions)? Furthermore, if you use nodelets (http://wiki.ros.org/nodelet) you get zero copy communication between your algorithms. So I actually think that ROS has the facilities to address the needs you describe.
I'd be interested, though, in your suggestions on what a real architecture for robotics looks like in your mind? I still remember the time before ROS, 20 years ago, when each robotics team had to designate a sub-team just for building and maintaining the middleware. That was a waste of time and effort. But you seem to suggest that we go back to that? ROS might not be perfect but it's so much better than anything else that exists. It's also open source and we can all work together to make it better rather than reinventing the wheel each time.
That first audio example just blew my mind! I can't believe I've lived my whole life to learn only now that our ears essentially just pick out all the sine waves in a complicated wave. Thank you!
Interesting. What's your estimate on how much overhead it was to support multiple clouds vs. just settling on one? Any tools/libraries/abstractions you can recommend that makes developing against multiple clouds easier?
"It’s hard for old mate Joe to get re-elected.." -- Glad to see that this was written by a highly objective and professional journalist with no personal political opinions of their own mixed into the narrative ;-)
I don't get it from your web page. What can I connect? Slack, Github, other APIs (like Zapier) -- or is it meant for running code on an existing page (automate front end)? I on purpose did not read your description above so I can give you feedback on the more important piece, your web page.
> Using container orchestration tools like Kubernetes or Nomad is usually an overkill for projects that will do fine with a single-server Docker Compose setup.
