October 22, 2020 • 7 min read

Going Beyond Cars with rideOS

The Routing and Optimization APIs from rideOS, as well as the Command Center, are well-known for their support of on-road vehicles performing ridehail and delivery. Did you know they can also bring the same benefits to non-road applications, like pedestrian couriers, mobile warehouse robots, or even futuristic underground mobility pods?

 

Broadening Our Definitions

 

When rideOS got started, we focused on solving one problem: ridehail. So we built products that empower fleets of automobiles on public roads to efficiently pickup and dropoff riders. As our customers’ needs grew, we expanded our focus to support delivery use cases as well. This meant broadening the product definition to empower fleets of automobiles on public roads to efficiently pickup and dropoff anything. Whether transporting people, packages, or meals, our products can power dispatch and bring benefits like higher vehicle utilization, reduced wait times, and smaller fleet sizes.

 

 

This step from supporting just ridehail to supporting ridehail and delivery broadened the definition of the tasks that could be completed by vehicles using our products. It turns out that we can broaden more than just tasks. Below is a more general definition of the products at rideOS.

 

We build products that empower cooperative groups of mobile agents on a connected physical network to efficiently complete localized tasks.

 

Let’s break that down piece by piece:

  • A connected physical network is composed of paths and intersections that are connected to each other.
    • A path is a directed sequence of global coordinates that indicates a valid way to physically move through the network.
    • An intersection is a meeting point of two or more paths, where a decision can be made about which path to follow next.
  • A mobile agent is a person or thing which can move through a network by following the paths defined within. A cooperative group of these can work together to complete a shared set of tasks efficiently.
  • A localized task is a unit of work that a mobile agent can complete by traveling through a sequence of one or more locations on paths within the network.

 

This is intentionally abstract in order to broaden its potential applications. The following examples should help illustrate how these abstract concepts map concretely to a variety of interesting applications.

 

Ridehail

 

As discussed above, ridehail is a use case in which fleets of automobiles pickup and dropoff riders on public roads. Since the public road network is the most common for rideOS use cases, we provide the map data necessary to route on that network. The OpenStreetMap (OSM) data is included with rideOS products out-of-the-box.

 

The visualization below should help identify how ridehail fits into the broad concepts described above. In each of the applications below, you will find a similar visualization to illustrate how it fits into these definitions.

 

 

The user of rideOS just needs to send some input about their fleet of automobiles and the tasks assigned to them. They will call the API to answer questions like: How many vehicles are in each fleet? Where are the vehicles right now? What tasks need to be completed? Where are those tasks located? With this information, rideOS can provide optimal assignments of tasks to vehicles, orderings of those tasks, and estimated time-to-completion for each task.

 

For some special use cases, like ridehail with autonomous vehicles (AVs), the fleet may only be able to use a limited operational domain within the public road network. This can be handled easily within the rideOS products by defining routing constraints through the Map Annotation API.

 

Meal Delivery

 

When rideOS partnered with Alto earlier this year, introducing safe and efficient meal delivery was a priority for staying relevant and profitable during the COVID-19 pandemic. Though this introduced many new operational details for Alto, the existing rideOS products were already able to help. Last-mile delivery is nearly identical to ridehail, with one small change: a different task performed by the vehicle. Instead of transporting people, the service would transport meals.

 

 

The Dispatch API can easily assign tasks to vehicles for arbitrary resources, which can be any kind of person or object. Additionally, the user can tune certain settings for different kinds of tasks. For instance, while a ridehail service may wish to minimize the rider’s wait time and avoid riders sharing a vehicle, a meal delivery service may instead wish to minimize overall driving time and bundle many meals together into a single vehicle. Each of these settings can be configured by the user as needed.

 

Pedestrian Couriers

 

Now let’s look at some non-road use cases with more unique properties. A pedestrian courier service, in which employees travel by foot to deliver packages, would not operate on public roads. Instead, the couriers would walk on public sidewalks. These sidewalks often follow the road network, but they sometimes diverge. In fact, some roads have no sidewalks at all. Planning appropriate routes and predicting accurate ETAs requires an understanding of the sidewalk network and the typical courier’s walking speed. Accuracy may even be enhanced by understanding how changes in elevation may slow people down.

 

 

This is no problem for rideOS, because we enable partners to upload any map data into our system. As long as it represents the geometry and connectivity of paths and intersections within a global coordinate system, all of our services can operate fully on the network it defines. We also support customization of routing parameters, like setting a fixed walking speed for ETAs. With a bit more work, we could even leverage the elevation awareness recently introduced for roads.

 

Sidewalk delivery robots are a similar use case. Because most robots have certain operational limitations, it may be useful to apply routing constraints to the sidewalk network. This is also fully supported by rideOS, since our constraints are defined in global coordinates that are not specific to the road network. No matter the network, you can dynamically update constraints to limit operations within that network at any time.

 

As of this writing, sidewalk applications do require that the partner supply their own sidewalk map data. However, it is on our roadmap at rideOS to support the sidewalk network out-of-the-box, just like we do the road network. Please reach out if you would like to know the status of that effort.

 

Mobile Warehouse Robots

 

Now let’s move to an indoor application at a smaller scale. Autonomous mobile robots (AMRs) are becoming a significant component of global warehouse operations. These robots can carry inventory throughout a warehouse, relieving the human work force of the physical burden, freeing them up to handle less automatable tasks.

 

Imagine that an online order has been received and an item must be moved from its storage shelf to a packing area for shipment. A mobile robot may be able to complete this task by driving to pickup at the shelf and dropoff at the packing area. Sound familiar? This is just a smaller-scale, indoor version of goods delivery like the meal delivery case above. Instead of a fleet of automobiles, we have a fleet of robots. Instead of delivering meals, they are delivering warehouse inventory. Instead of operating on the public road network, they are operating on a private warehouse corridor network.

 

 

Just like the sidewalk map above, a map of warehouse corridors can be defined using paths and intersections defined in global coordinates. These are the paths that human warehouse workers and mobile robots would use to navigate the warehouse shelves and stations. By uploading this map to rideOS, the challenges of optimizing a fleet of robots in a large and active warehouse can be handled easily. This could even be used to optimize assignments for human workers who move inventory around in fast and complex warehouse environments. They would just need a rideOS-interfaced app that can let them know where to go next.

 

Finally, just like every other application, routing constraints can be applied dynamically to the corridor network. Perhaps a shelving unit is being replaced, taking up an entire aisle. The user can define constraints which prevent travel in just that specific aisle. Those constraints can quickly propagate to the entire fleet of robots, adjusting plans on the fly.

 

Underground Mobility Pods

 

What about the future of mobility that is still being dreamed up? Industry innovators are actively exploring new mobility solutions, including technologies that utilize the urban skies or the spaces deep underground. No matter how novel, any futuristic transit option built on a connected network can be optimized by rideOS products. Underground mobility pods are just as viable a use case as a taxi fleet or a warehouse.

 

In this case, the network would be a series of tunnels instead of surface roads. Operating on that network would be a fleet of high-speed autonomous mobility pods which pickup and dropoff passengers at underground stations connected to popular spots on the surface.

 

 

It should be clear by now that by ingesting a map of the tunnel network, rideOS can provide all of the same optimizations discussed above and route within the tunnel network with dynamic constraints. If any special optimization parameters or new configurable routing settings were needed, our team at rideOS would be happy to explore those options with the relevant partners. The new settings may end up proving useful for a variety of other use cases as well!

 

Continuing to Expand Our Horizons

 

No one knows for sure what the future will hold for mobility, but rideOS will continue to innovate and provide technology to support the needs of emerging mobility solutions. If you have a unique use case that might fit within the broad concepts described above, please get in touch with us to find out how we could help you improve the efficiency of your operations.