> Food delivery companies as well seemed to be testing out robots that would bring your food to you albeit in a more sidewalk bound way<p>Former delivery robot startup cofounder (Robby Technologies) here. To be honest hardware was by far the most time-consuming thing. I wanted to spend 80%+ of our engineering time and funds on software but it turned out that we ended up spending 80%+ of the time dealing with electromechanical issues, supply chain issues, bad USB cables, motor controller issues, shitty crimping jobs, thermal management, plastic breakage, bad PCBs, bad BMS, bad lithium cells, snapping drive belts, malfunctioning locks, malfunctioning cameras, manufacturer-mislabeled motor wires, sensors that didn't meet specs, antenna placement and RF interference, and lots more. Then there was the operational overhead of figuring out how to charge, move, and store all of them, and how to get things in/out of them when businesses weren't willing to walk from the store to the sidewalk to drop something in a robot, and the customers weren't always willing to come outside to grab their stuff. Then there were robots that got stuck in potholes and the like, and had to be rescued by driving out to them. All that while trying to scale up manufacturing, which never really happened beyond a certain scale. Guess how much time we had left for writing autonomous software.<p>The thing is, autonomous driving, especially on the sidewalk is actually <i>much</i> easier than the hardware problem of figuring out how to design, build, and scale a new type of vehicle from scratch. The main issue is we, and likely all the other companies, were stuck in a hellhole of hardware problems that <i>something</i> was always "on fire" hardware-wise.<p>In retrospect I see the companies that went to the roads instead of the sidewalks had it slightly easier on the hardware side: they could just buy a reliable car and mod it, and get to work on software. Safety-wise, of course, they have it much harder, it's a trade-off.