Wondering as a codelet, not very tech savvy but I admire the will to that kind of expertise. No bully.

How accurate does autonomous robot software have to be for the deployment of the robot to be viable/profitable? Are there cases where you could have an intermediate range of error-rate where the robot can still be profitable even if you need human workers to monitor for and correct mistakes? I'm sure it's a matter of degree and it varies by the case...
I understand factory robots work because their actuation is rigid and predictable enough that ordinary algorithms work just fine, no "AI" methods needed. Roombas and similar devices are worth selling because some consumers can tolerate their degree of inaccuracy, I guess due to the nature of the task. But to scale autonomous robots in other areas, how low do error-rates have to be for a viable product?

Are recent improvements in virtual AI agents and AI generation/interpretation of videos and 3D models a sign that robots will "soon" have the ability to interact with an active 3D environment accurately enough for commercial viability? How wide is the difficulty gap in that comparison?

>>106031300 (OP)
>how low do error-rates have to be for a viable product?
About tree-fiddy.

>>106031300 (OP)
Every control system will have some degree of inaccuracy and imprecision. The accuracy and precision you can get out of a system must be rigidly planned for to find safety tolerances if human lives could be affected. This is old news, but it never stops being important.
There is no set error rate that makes something specifically viable in general and definitely not one that makes something profitable in general. But there are plenty of robots that are sold at profit today and for the past 70 years that require human monitoring or ocassional intervention.
The update rate of a control system's outputs is often critical and reliant on the update rate of it's inputs + some delay in processing, and so things like Real Time Operating Systems are a must have to even attempt to ensure calculations are always delivered on time, but your software still has to be good, or else the operating system itself won't save you.
3D mapping of an evironment in real time, such as SLAM related algorithms is the sort of thing where alot of compute power is required for sure, and it can allow for some fancy high and medium level decision making opportunities, but you must never forget that the results must get through processing the pipeline on time. A result must be delivered in a cyclic window of time dictated by when that control output is considered useful and acceptable by the designer. Remember you're translating analog world, to digital world, and then often back to analog world. What you do with a robot is totally up to you (and how much money you're willing to spend).
Faster smaller processors, embedded neural net accelerators, mems sensors, cheaper and/or lighter weight or more powerful motors are all great to have these days in service to things that would have been impractical or just too downright expensive for mass consumption in the past.

>>106032825
Roombas don't need to balance on two legs, they can't fall out of the sky (unless somebody throws them out of a building) it needs to do it's motor control rate proportionally to the maximum speed each it's motors can turn. I.e. doesn't need to be particularly fast, and safety is no real concern here, a roomba doesn't have the weight or the power to pose a real threat to humans, but if the step frequency isn't choosen high enough, the roomba might spin it's motor too fast to do acceptable corrections for motor drift leading to the roomba never getting near it's targeted positions, which would be really annoying to the customer. The roomba already maps the envronment, albeit in a 2D way, with a single infrared lidar, which a suitable cheap one can probably be found pretty easily for your consumer product than it used to be. This is so that your roomba can try to understand where it is in relation to obstacles in the room, but I'm guessing everybody sees the roomba bumping into a chair's leg, and that's probably cause it didn't see it through the lidar, because the angular accuracy of the lidar was piss poor. So the robot finds out it hit something by the pressure switch on the front, and switches it's goal from moving forward in a straight line, to turning to maneuver around an obstacle it can't see.
This is acceptable for a roomba. But if you had a giant roomba as big as a person, and it didn't see the person, this would be very very bad. Probably completely unnacceptable.