[iancmceachern]

This same problem exists in the hospital setting on anything with wheels.

They solve it there with "cord pushers". Basically cattle guards for stuff on the floor.

Not every problem needs a complex solution.

I think the brilliance of this project is in its simplicity, particularly in the robot design.

[rapjr9]

Take a look at these pictures:

https://duckduckgo.com/?q=cluttered+old+persons+home&atb=v31...

I was thinking that people who live in an environment like this are most in need of a robot to help them.

[iancmceachern]

Agreed, they could use the help.

The issue I see is that is by far the most challenging corner case. It's not the largest market, but it's the most difficult to capture.

Good business sense would dictate that you should try to capture the largest market, that is simpler to capture first, then go after these more difficult corner cases.

[floydnoel]

these "invented problems" that software engineers (such as myself) find in every project are basically why we can't have nice things. why did software in the 90s run faster than the same functionality in the 2020's? it's this right here.

[ehnto]

I have had good discussions with a colleague about this, where developers lean toward getting roadblocked by all possible engineering problems, they advocate checking to see if there are solutions to the problem that don't require engineering.

In this example, I think they'd suggest communication first then solve the engineering problem later.

Eg: just tell people they need to clear the floor or it can get stuck. People will still want it.

Perhaps the next step is lower touch engineering, ie: beep when it's stuck.

I tend toward engineering stuff, but I have come to realize you can't always afford the engineered solution, and that doesn't have to stop you from delivering stuff.

[bckr]

Coming up with these scenarios is called de-risking and engineers need to do it!

To your point, people own Roombas, which is kinda like this with no arms.