chfritz

Almost none of these problems scream "robots to the rescue". Monitoring: more drop cams. Meal prep: delivery services. Cleaning: sporadic visits by cleaner. Med monitoring: IoT pill boxes. Calling 911: pendant buttons. All these things already exist. Don't get me wrong. I'm bullish on robots -- I've been working in this space for nearly 10 years now. But one has to look very critically at problems and whether robots are indeed the best solution. Homes are still very difficult for robots to navigate, even humanoids.

This is actually not a new trend. RaaS -- robotics-as-a-service -- is over ten years old by now. I believe it was pioneered or at least made popular by several of the Willow Garage spin-outs, incl. Savioke and Fetch Robotics, and it, of course, aligns very well with the trend towards b2b services instead of goods. The latter being, of course, even older with GE's power-by-the-hour for leased jet engines, and Xerox' print services.

Sorry to ask the obvious: why not just print the caricatures using a regular printer instead?

This is cool. Any reason you used three.js directly from react instead of react-three?

what is this? an AI agent soliciting work on HN?

This title is so wrong. First? RoboCup, the international robotic soccer league was founded in 1997! I've myself participated in "autonomous AI robot football" matches back in 2002-2004. And these tournaments happen every year at the world-cup level plus many local events like the German Open.

Looks great, but is there an English version of that page?

2024? how is this news?

Of course, security/safety would be a problem, too, but it's usually decided after the primary decision of "do I even want this".

I'm with blinkbat: show me a task these robots can actually do! Humanoids are just not useful yet. Dishes? nah, these robots are not water proof. Vacuum? nah, wrong form factor. Dusting? definitely not worth $1,000 a month. Cooking? again, not water-proof and they can't do it either. Tidying up? again not worth the money. Folding laundry? maybe! but still very difficult for them and again, price would need to come down a lot.

congrats!

"California safety regulations currently require operators to be "stationed" at the controls."

This is NOT a huge burden. Any robotics company operating a fleet today will have someone watching almost all the time in one form or another anyways. So this really just becomes a matter of interpreting what "the controls" means. The regulation seem to omit any mention of "on the device/vehicle" so these controls can clearly be remote. It also doesn't seem to specify a 1:1 ratio of operators to devices. So if there is one operator, e.g., at the air-conditioned HQ of the robotics vendor, at the "controls" of twenty tractors that are operating in the field which the operator can see remotely using low-latency video-streaming and which he can stop instantly with the press of a button, then that might already be all that is required. It certainly is logically.

You may also want to share it on https://discourse.ros.org.

Thanks for sharing! Very illustrative and easy to follow.

How long did it take to train it on that example you show?

Dup of https://news.ycombinator.com/item?id=44126753

Ancient news. And they were hardly the only ones putting UV-C lamps on robots. See https://luminrobotics.com/companies/ for a partial (and outdated) collection.

> "A key challenge of deploying learned VMPs is their lack of interpretability in failure cases," Amazon’s researchers observe in the Pick robot paper. "While it is often easy to fix a simple bug or improve algorithmic limitations of heuristic approaches, VMPs have to be re-trained or fine-tuned to learn about failures while maintaining their previous performance."

Exactly! This has been the issue with ML and especially NN based approaches for a long time. Really disappointing that we still haven't solved this problem. It's a real limitation.

2023? News?

> By the end of 2025, more than half of the humanoid robots sold in the United States will be to consumers.

You can't be serious! There are currently ZERO applications of humanoids for consumers and these robots still cost more than a car. They also represent a significant risk to humans, esp. little ones, simply because they still fall over sometimes.

That's one side of the 'more' inequality. On the other is an industry currently flooded by VC money trying to make humanoids work. Clearly they will be the ones buying most of the inventory.

Love the idea. However, there is no guarantee that the no-upload will not change. Which begs a question: wouldn't it be great if browsers provided a guaranteed "offline only" mode? Since they don't, I personally would prefer downloading this app as a standalone electron (or similar) app, or a docker container where I could disable Internet access.

Interesting to hear your update on Upwork.

Pretty cool!

As I describe before here https://www.linkedin.com/advice/0/heres-how-you-can-stay-ahe..., many roboticists overlook the need for JavaScript in their skill set and tech stack. This is because of the evolution of robotics projects and companies: first you build a prototype and only then do you deploy and scale your fleet. The first part is hard and doesn't require any JS. But the second part is even harder and requires a ton of JS, because without web-tooling you won't be able to operate efficiently. This offers a great opportunity for roboticists to distinguish themselves from others be mastering JS for both the backend (rosnodejs, rclnodejs) and the front-end (React, Transitive Robotics). This sets you apart from both "regular" roboticists and from "pure" web developers.

What I'm trying to say: robotics is a very broad field and your current full-stack skills are needed just as well. And while working on those aspects of the robotics stack you can learn about the rest if you want. But you don't even have to to progress in your career in the robotics industry.

If you want to work on something specific, you can try to build a capability ("full-stack app") on Transitive, the open-source full-stack framework for robotics we've built that works with any robots, esp. ROS ones: https://github.com/transitiverobotics/transitive. Oh and of course learn ROS along the way.

Not new, but still awesome.

> By 2015, the chess program Stockfish could defeat the strongest human-computer partnerships 100% of the time. From that point onward, humans only got in the way. Human-robot partnerships for performing labor will follow exactly the same pattern.

Wow, how convincing -- NOT! Just dogmatic statements with no substance. The comparison might be illustrative but you still need to argue why it has enough parallels. And in this case I think you are way out of wack. Just think of Moravac's paradox -- which doesn't apply in chess, but does in the real-world!

The hard part of robotics are the edge cases. The things that happen 0.1% of the time that will interfere with the automation promised by the robot. Simulation, especially when driven by RL, i.e., based on models learned from data, are extremely bad at predicting these edge cases. In fact, I would argue that if you already knew the edge cases and could simulate them, you wouldn't need to simulate them in first place. Besides that, I doubt that the fidelity of your simulation will even cover that.

Anyone who's worked in robotics for a couple of years knows this and can share anecdotes. My favorite ones are sun reflections on the floor in a specific corridor at a specific customer at a specific time of day and season and direction of travel, that resulted in washing out the pattern projected on the ground by the 3D camera. This is not the kind of stuff you model upfront (unless you already know to worry about reflections, in which there is no need to model and simulate, just account for it in your design). This is only one of many examples.

Is it AI generated, curated?

This is the difference between I(nform) and C(onsult) in RACI matrixes, a great framework to keep in mind as you think about team communications. https://en.wikipedia.org/wiki/Responsibility_assignment_matr...

Pre-seed is mostly raised on the quality of the team. But your team slide barely shows anything that would convince people that you know what you are talking about. The problem you describe (and also the approach) is something a lot of companies are currently working on, so you better have a strong answer to "why us?".

> [Short Term] Outsourcing selling and deployment > We don’t handle deployment ... > [Long Term] Inhouse commercial arm > We are the single POC for the customer

100% wrong! First of all your deployments won't be successful if you don't see them through and micro-manage and monitor them. Secondly, you want to learn first hand how these deployments go and what the issues are. Thirdly, your "partners" will laugh you out of the room if you don't come with very detailed and streamlines instructions for how to deploy, configure, do user training, etc.

> Expanding into adjacent sectors such as construction (£10 trillion, 2023) and agriculture (£10 trillion, 2023)

This shows naivety. These markets are not adjacent to anyone who has been in robotics for more than five years. This statement makes you look stupid. Manipulators (arms) and retrofitting existing farming machinery are two very different subproblem in robotics, with very different stacks and very different deployment models (and even financing models -- agtech is very seasonal). If you want a more adjacent market, look at applications for mobile manipulators (arms on bases).