Staffing shortages, accelerated e-commerce demand, and the need for contactless service are driving demand for delivery robots. While some robotics developers are focusing on indoor deliveries and others on outdoor operations, Ottonomy Inc. is testing robots for retail and food delivery in both environments.<\/p>\n\n\n\n
Santa Monica, Calif.-based Ottonomy said its autonomous mobile robots (AMRs<\/a>) use proprietary contextual navigation software<\/a> that enables them to navigate both indoors and outdoors. The robots also include multi-layered safety protocols to facilitate safe navigation<\/a> in crowded spaces such as sidewalks and airports.<\/p>\n\n\n\n The company <\/a>claimed that its systems, which are available through a robotics-as-a-service (RaaS) model, can contribute to sustainability and scalability goals.<\/p>\n\n\n\n Ottonomy last month partnered<\/a> with Los Angeles-based CraveUp so that consumers could use CraveUp’s mobile app to order robotic deliveries<\/a> in food courts in California.<\/p>\n\n\n\n \u201cAMRs are mostly focused on constrained environments like warehouses<\/a>,\u201d said Ritukar Vijay<\/a>, CEO of Ottonomy. \u201cWe have experts in both indoor robotics and outdoor autonomous driving. Localization of our delivery robots is not dependent on GPS, so for us, indoors versus outdoors doesn’t make a difference.\u201d<\/p>\n\n\n\n \u201cOttonomy splits mapping in a unique way,\u201d he told Robotics 24\/7<\/em><\/a>. \u201cWe take the geometric map and then add contextual information to it. That’s not the case in most AMRs or self-driving vehicles<\/a>.\u201d<\/p>\n\n\n\n Ottonomy teleoperates its robots for the initial mapping, and then its robots can run autonomously.<\/p>\n\n\n\n \u201cWe use compute at the edge<\/a> for localization and mapping, which are very processor-hungry processes,\u201d Vijay explained. \u201cWe have a proprietary implementation that uses GPUs for visual processing and the rest on serial. We’re also moving planning onto GPUs for smoother trajectories next to people.\u201d<\/p>\n\n\n\n \u201cOn the surface level, that seems easy enough to solve, but for compute for dynamic environments, you need to plan two- to three-digit trajectories,\u201d he added. \u201cWe’re also part of\u00a0NVIDIA<\/a>‘s\u00a0Inception<\/a>\u00a0program for AI startups.\u201d<\/p>\n\n\n\n \u201cThe first MVPs tested our systems November-December of 2020,\u201d said Vijay. \u201cThe robots didn’t have full teleoperation<\/a>, but they had wireless e-stop [emergency stopping]. There was not one instance of needing it.\u201d<\/p>\n\n\n\n \u201cAt the same time, we realized that for safety and regulatory compliance both indoors and outdoors, we need full-fledged monitoring and control,\u201d he noted. \u201cOur network operations console gives an entire view of the fleet and each robot’s journey, including the entire cycle of order to pickup and waiting.\u201d<\/p>\n\n\n\n \u201cIt also provides insights such as the number of orders per hour and analytics,\u201d Vijay said. \u201cWe can see the position of all robots in a live map, but the robot just sends alerts when it needs help. Then it triggers our monitoring system, and teleoperation can kick in.\u201d<\/p>\n\n\n\n \u201cOther delivery robot companies are following an incremental approach, but as with autonomous driving, it’s tricky because the safety driver has to be continuously alert,\u201d he said. \u201cWe’re moving way from that, with autonomous robots that call only when necessary.\u201d<\/p>\n\n\n\n \u201cIf the goal is to be 100% autonomous, you need multiple sensors<\/a>\u20143D lidar<\/a>, cameras<\/a>, and safety sensors,\u201d added Vijay. \u201cIf you’re relying just on deep learning, systems can be 70% to 80% autonomous, but then it’s harder to go back and make changes.\u201d<\/p>\n\n\n\n \u201cBetween 45% and 60% of robotics companies are fully teleoperated and claim they’ll eventually have autonomous functionality,\u201d claimed Vijay. \u201cIf we look ahead two to three years to reach autonomy, it will still take them time to make unit costs. We’re at that point right away, which is a massive difference.\u201d<\/p>\n\n\n\n \u201cThe first difference for outdoor environments is our sensor choices,\u201d Vijay said. \u201cThanks to our fleet management, mapping is decentralized. Five robots can communicate with one another and create or update a map of an area.\u201d<\/p>\n\n\n\n \u201cThe second from a use-case perspective,\u201d he said. \u201cWe’re focusing more on bringing orders from inside a store to curbside. The amount of online digital ordering\u201470% are pickups, and 30% are doorstep delivery, particularly for groceries. We looked at what needs to be solved for both environments, and there are no state regulations for curbside, unlike last-mile deliveries, which could push nationwide scaling years out.\u201d<\/p>\n\n\n\n In addition, Ottonomy’s robots have multiple compartments for greater productivity and sustainability<\/a>. \u201cThey can carry two distinct orders in a single trip, for higher throughput,\u201d said Vijay. \u201cFrom an urban planning perspective, it’s better to have fewer robots delivering more orders.\u201d<\/p>\n\n\n\n \u201cFor example, there might be 75 orders for pizza between 6:00 and 8:00 p.m.,\u201d he said. \u201cYou’d need 75 trips with a standard robot; we can cut it by 50%.\u201d<\/p>\n\n\n\nMapping and processing for dynamic AMRs<\/h4>\n\n\n\n
Ottonomy develops for full autonomy<\/h4>\n\n\n\n
Indoor vs. outdoor operations<\/h4>\n\n\n\n