WO2022150438A1 - Systèmes et procédés d'aménagement d'itinéraire sur des voies piétonnes - Google Patents

Systèmes et procédés d'aménagement d'itinéraire sur des voies piétonnes Download PDF

Info

Publication number
WO2022150438A1
WO2022150438A1 PCT/US2022/011386 US2022011386W WO2022150438A1 WO 2022150438 A1 WO2022150438 A1 WO 2022150438A1 US 2022011386 W US2022011386 W US 2022011386W WO 2022150438 A1 WO2022150438 A1 WO 2022150438A1
Authority
WO
WIPO (PCT)
Prior art keywords
map
sidewalks
representations
routing
roads
Prior art date
Application number
PCT/US2022/011386
Other languages
English (en)
Inventor
Bruce BLAND
Akshay RAVIKUMAR
Patrick Niklaus
Brett BAVAR
Original Assignee
GoBrands, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GoBrands, Inc. filed Critical GoBrands, Inc.
Publication of WO2022150438A1 publication Critical patent/WO2022150438A1/fr

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/38—Electronic maps specially adapted for navigation; Updating thereof
    • G01C21/3804—Creation or updating of map data
    • G01C21/3807—Creation or updating of map data characterised by the type of data
    • G01C21/3815—Road data
    • G01C21/3822—Road feature data, e.g. slope data
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3453—Special cost functions, i.e. other than distance or default speed limit of road segments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"

Definitions

  • the disclosed embodiments relate generally to systems and methods for routing along pedestrian pathways, such as sidewalks and crosswalks.
  • Pedestrians and delivery robots can be routed using road maps, but the provided routes often result in inefficiencies (as discussed below with respect to FIGS. 2A-2B).
  • routing such vehicles using road maps increases the likelihood of the autonomous delivery robots encountering situations for which they are unable to proceed. This situation typically requires intervention by a remote human operator/driver.
  • maps that include sidewalk and crosswalk data (e.g., representations of sidewalks and crosswalks).
  • Some embodiments of the present disclosure solve this problem by adding, to an initial map, one or more sidewalks corresponding to roads in the initial map.
  • a sidewalk is added for each side of each street (or at least those streets for which sidewalk data does not exist).
  • one or more crosswalks are added at intersections.
  • the position and number of crosswalks depend on the geometry of the intersection. For example, three roads that meet at 120 degree angles are treated differently than three roads that meet at a 1' intersection, and both those scenarios are treated differently than a four-way intersection.
  • the updated map is then used to route pedestrians and autonomous vehicles that travel along pedestrian paths.
  • the resulting updated map provides a number of benefits, even if the updated map includes representations of a large number of sidewalks that do not physically exists.
  • some embodiments described herein allow users to submit corrections to the updated map, indicating which sidewalks on the updated map do not physically exists. In fact, it is often far belter to be over- inclusive, assuming the presence of sidewalks and allowing users to submit corrections titan to wait for more detailed sidewalk data to be otherwise generated. For one thing, the process of correction is likely to occur much faster titan the generation of data from scratch.
  • sidewalk and crosswalk data allows users (e.g., fleet managers) to specify sidewalk or crosswalk constraints for a particular area or along a particular route, which can then be factored into a cost model for routing the user’s vehicles.
  • a method includes obtaining a map that includes representations of a plurality of roads within a geographical area.
  • the method further includes updating the map by adding representations of a plurality of sidewalks within the geographical area, including adding, for each road of the plurality of roads within the geographical area, a respective representation of a sidewalk.
  • the method further includes receiving a request to route a trip over sidewalks in the geographical area.
  • the method further includes routing the trip using the updated map.
  • Some embodiments of the present disclosure provide a computer system (e.g., a server system), comprising one or more processors and memory storing one or more programs.
  • the one or more programs store instructions that, when executed by the one or more processors, cause the computer system to perform any of the methods described herein.
  • Some embodiments of the present disclosure provide a non-transitory computer readable storage medium storing instructions that, when executed by a computer system having one or more processors, cause the computer system to perform any of the methods described herein.
  • These embodiments improve routing along pedestrian pathways, such as sidewalks and crosswalks, including routing of autonomous vehicles that travel along pedestrian pathways (e.g., delivery robots).
  • pedestrian pathways e.g., delivery robots.
  • FIG. 1 is a block-diagram of a client-server environment illustrating interaction between a routing server, a fleet manager, and one or more vehicles, in accordance with some embodiments.
  • FIGS. 2A-2B are schematic diagrams illustrating an example in which roadbased vehicles may be routed along a different route from a starting location to an ending location than pedestrians or vehicles traveling along sidewalks, in accordance with some embodiments.
  • FIGS. 3A-3G are schematic diagrams of a process for updating a map to include representations of sidewalks and, optionally, crosswalks, in accordance with some embodiments.
  • FIG. 4 illustrates an example of a map with added representations of sidewalks and crosswalks, in accordance with some embodiments.
  • FIG. 5A-5C illustrate different manners of applying user-specified constraints for routing trips over sidewalks in the geographic area, in accordance with some embodiments.
  • FIG. 6 is a block-diagram illustrating a routing server, in accordance with some embodiments.
  • FIGS. 7A-7B illustrate a method of routing on sidewalks, in accordance with some embodiments.
  • FIG. 1 is a block-diagram of a client-server environment 101 illustrating interaction between a routing system 100, a fleet manager 108, one or more vehicles 110 (e.g., vehicle 110a and vehicle 110b), and a third party 103, in accordance with some embodiments.
  • One or more networks 112 communicably couple the components of the client-server environment 101.
  • the one or more networks 112 include public communication networks, private communication networks, or a combination of both public and private communication networks.
  • the one or more networks 112 can be any network (or combination of networks) such as the Internet, other wide area networks (WAN), local area networks (LAN), virtual private networks (VPN), metropolitan area networks (MAN), peer-to-peer networks, and/or ad-hoc connections.
  • WAN wide area networks
  • LAN local area networks
  • VPN virtual private networks
  • MAN metropolitan area networks
  • peer-to-peer networks peer-to-peer networks, and/or ad-hoc connections.
  • vehicles 110 comprise a fleet of vehicles.
  • the vehicles 110 are autonomous vehicles (e.g., that operate under remote supervision of humans, also referred to as “tele-operators,” such that, i f the autonomous vehicle encounters a situation it cannot handle, a human can remotely assume operation of the autonomous vehicle).
  • the vehicles 110 are robots (e.g., package delivery robots).
  • the vehicles are not configured to hold any human passengers (e.g. the vehicles are configured to operate without any humans locally present).
  • the vehicles 110 are designed to travel along pedestrian passageways (e.g., sidewalks and crosswalks).
  • the vehicles include one or more sensors for navigating locally (e.g., determining the location of a sidewalk or crosswalk and following it, avoiding collisions with objects and pedestrians).
  • the vehicles include one or more processors for receiving data from the one or more sensors and navigating locally, although, alternatively, the processing of the sensor data may be performed by a server system (e.g., fleet manager 108 or another server system).
  • fleet manager 108 manages trip requests for the fleet of vehicles (e.g,, the fleet manager 108 and the vehicles 110 are in a client/server relationship, wherein the fleet manager 108 acts as a server and the vehicles 110 act as clients).
  • the trip requests may be received from the vehicles 110 or from a third party 103 (e.g., individual or organizational customers of the fleet of vehicles).
  • Trip requests typically include an initial location (e.g., a pick-up) and a final location, or destination (e.g., a drop-off)
  • the trip request may include scheduled, on-demand, or queued trip requests.
  • An example of a scheduled trip request is a request to deliver flowers from a florist to a particular place at a particular time.
  • the scheduled trip request may be scheduled days or weeks in advance.
  • An example of an on-demand trip request is a request to deliver a meal from a restaurant to a customer as soon as possible.
  • An example of a queued trip request is a request to deliver a package.
  • the queued trip request may have a deadline (e.g., overnight, three-day, etc.) or priority (e.g., first class) associated with it, but is otherwise not expected at a particular time or in particularly short older (as a meal would be).
  • fleet manager 108 dispatches vehicles 11.0 (e.g., selects and assigns particular vehicles to perform particular trip requests) and provides routes for the vehicles.
  • the routes comprise instructions as to which sidewalks, crosswalks, and paths the vehicle should follow (e.g., the routes do not include instructions for finer navigation, such as locating a sidewalk, avoiding a collision, etc ).
  • the fleet manager 108 outsources the dispatching and routing to routing system 100. To that end, fleet manager 108 acts as a client of routing system 100 and interacts with routing system 100 through routing system 100’s client portal 113 (e g., an application programming interface (API)).
  • API application programming interface
  • fleet manager 108 provides information about the trip requests that it has received, as well as information about the vehicles in the fleet (e.g., the locations of the vehicles 110 in the fleet, there current states, etc.).
  • the fleet manager may apply constraints 115 (e.g., routing constraints) and corrections to updated map 104, as described in greater detail below.
  • the constraints 115 are typically stored in a fleet-specific manner, such that routing system 100 can service many fleets and individualize the constraints for each fleet.
  • Routing constraints may take the form of either absolute constraints (e.g., a prohibition against a vehicle traveling along a particular sidewalk or crosswalk, a type of sidewalk or crosswalk, within a particular geographical area, etc.) or costs (e.g., a cost for traveling along a particular sidewalk, which has the effect of discouraging a route along that particular sidewalk but not prohibiting it).
  • cost-based constraints may be appropriate for a region that requires tele- operator intervention (and thus does not need to be completely avoided).
  • the cost-based constraints comprise a multiplier of an existing cost (e.g., in which the existing cost is based on travel distance, travel time, or any other appropriate factor) Corrections are typically made to updated map 104, which is used for the different fleets.
  • the routing system 100 In order to provide routing servers for vehicles in the fleet of vehicles (e.g., delivery robots), the routing system 100 generates an updated map 104 that has representations of sidewalks and/or crosswalks within a geographical area. To generate the updated map 104, the routing system 100 obtains (e.g., receives) an initial map 102.
  • the initial map 102 is an open-source map (e.g., OpenStreetMap). As such, the initial map may include representations of some sidewalks and crosswalks, but is likely to be quite incomplete.
  • the routing system 100 updates the initial map 102 by adding representations of a plurality of* sidewalks within the geographical area (e.g., adding, for each road within the geographical area, a respective representation of a sidewalk on each side of the road).
  • the routing system 100 further updates the initial map 102 by determining the presence of an intersection between respective roads in the geographic area and adding, to the map, one or more representations of crosswalks corresponding to the intersection.
  • the number of crosswalks that are added for the intersection is based on a heuristic that accounts for the geometry and/or curvature of the roads in the intersection.
  • An autonomous vehicle (AV) routing engine 106 of the routing system 100 uses the updated map 104 to service trip requests from fleet manager 108 (e.g., determine and provide dispatch decisions and routing information to fleet manager 108). To that end, AV routing engine 106 uses an algorithm or a series of algorithms to provide dispatch decisions and routes for the vehicles 110, taking into account the fleet-specific constraints, as well as conventional factors such as the travel distance and travel time for the route. For sidewalkbased autonomous vehicles such as delivery robots, the vehicles 110 are routed over at least some of the sidewalks and/or crosswalks that were added to the updated map 104.
  • FIGS. 2A-2B are schematic diagrams illustrating an example in which road- based vehicles may be routed along a different route from a starting location 202a to an ending location 202b than pedestrians or vehicles traveling along sidewalks, in accordance with some embodiments.
  • Starting location 202a is on the left-side of the street (as observed by vehicle 204) and ending location 202b is on the right side of the street.
  • FIG. 2A illustrates a route 208 from starting location 202a to ending location 202b (e.g., a destination or drop-off location) suitable for a vehicle 204.
  • vehicle 204 is simply routed along road 206 from starting location 202a to ending location 202b.
  • the delivery robot would travel along sidewalk 210a and end up across the street from ending location 202b.
  • the delivery robot may be unable to cross the street, necessitating human intervention (e.g., by a remote human driver).
  • the remote human driver if following safety laws is likely to turn the delivery robot around, direct it all the way back to crosswalk 212 (e.g., the nearest crosswalk), cross the street, and traverse sidewalk 210b.
  • FIG . 2B illustrates a route 214 suitable for a delivery robot 216 (e.g., as well as pedestrians and other non-street-bound traffic).
  • Route 214 is generated using a map that includes representations of sidewalks and crosswalks for the geographical area. As such, route 214 differs from the route 208, which was generated using only representations of roads.
  • route 214 first directs delivery robot 216 to crosswalk 212 so that delivery robot 216 can cross the street, and then directs delivery robot along tidewalk 210b to ending location 202b. This route may not require human intervention because the delivery robot knows how to proceed at each location along the route (e.g., the delivery robot does not reach a location at which it is unsure how to cross the street).
  • FIGS. 2A-2B The scenario shown in FIGS. 2A-2B is just one simplified example.
  • routing on a map that includes representations of sidewalks and/or crosswalks is advantageous compared to routing on a map that includes only representations of roads.
  • Other situations in which it is beneficial to include representations of sidewalks and/or crosswalks include one-way streets (in which pedestrians, delivery robots, and the like, may travel in either direction on either side walk) and situations in which constraints should be applied specifically to the sidewalk and/or crosswalks (e.g., where construction blocks the sidewalk on one tide of the street but does not block the road or the tidewalk on the other tide of the street).
  • FIGS. 3 A-3G are schematic diagrams of a process for updating a map to include representations of sidewalks and, optionally, crosswalks, in accordance with some embodiments.
  • FIG. 3 A illustrates a map 301 that includes representations of a plurality of roads 302 (e.g., representations of roads 302a through 302d).
  • the maps described herein typically take the form of data stored in memory of a server system (e.g., as a data structure, such as a graph, as described below). As such, the maps described herein need not be physically rendered (e.g., displayed to a user).
  • the illustrations (e.g., renderings) of the maps provided in the drawings are merely intended to aid the reader’s understanding of the disclosure.
  • the map 301 is a graph and the representations of roads 302 are edges on the graph. In some embodiments, intersections 303 are represented by nodes on the graph. In some embodiments, the representations of roads 302 comprise representations of lanes within the roads (e.g., the map includes lane-level data). In some embodiments, the representations of roads 302 are representations of segments of roads (e.g., a segment of a road that lies between two intersections). In this example, representation of roads 302a and 302d are representations of segments of 1 st Street, whereas representation of roads 302b and 302c are representations of segments of 5th Avenue. In some circumstances, the representations of roads 302 include unidirectional edges on a graph (e.g., in circumstances in which the representations of roads 302 include lane data or represent a oneway street).
  • map 301 is an initial map 102 (e.g., an open source map, such as OpenStreetMap) obtained from an outside source.
  • map 301 is an intermediate map (e.g., a map on which certain pre-processing steps have already been performed, as described in more detail with reference to FIGS. 3E-3G).
  • FIG. 3B illustrates adding representations of sidewalks 304 to the map 301 (FIG. 3A), in accordance with some embodiments.
  • one or more representations of sidewalks 304 are added.
  • a respective representation of a sidewalk 304 is added for each side of the road.
  • representations of sidewalks 304a and 304b both correspond to representation of road 302a (e.g., correspond to opposite sides of the road); representations of sidewalks 304c and 304d both correspond to representation of road 302b; representations of sidewalks 304e and 304f both correspond to representation of road 302c; and representations of sidewalks 304g and 304h both correspond to representation of road 302d.
  • the representations of sidewalks 304 are bidirectional edges on the graph (e g., representing the fact that pedestrians and delivery robots may generally travel in either direction on either sidewalk).
  • representations of sidewalks 304 are initially co-extensive with (e.g. , having a same length and position parallel to) their corresponding representations of roads 302. Because of the presence of an intersection 306, adding (e.g., generating) representations of sidewalks 304 that are co-extensive with their corresponding representations of roads 302 results in the representations of sidewalks 304 being slightly too long (as indicated by extraneous portion 307). As a result, in some embodiments, the process includes modifying the representations of the sidewalks 304 by removing the extraneous portions.
  • intersection 306 is determined (e.g., by identifying an intersection of representations of sidewalks 304), and the portions of the representations of sidewalks 304 within the intersection are removed (as shown in FIG. 3C).
  • the representations of sidewalks 304 that are added to the map are shorter than the corresponding representations of roads 302.
  • FIG. 3D illustrates an updated map 104, in accordance with some embodiments.
  • Updated map 104 includes a plurality of representations of crosswalks 308 (to avoid visual clutter, only one of the representations of crosswalks 308 is labeled in FIG. 3D).
  • the number of crosswalks added to the updated map 104 is selected in accordance with a heuristic for the intersection.
  • the heuristic for the intersection is based on a geometry of the intersection (e.g., a curvature of one or more roads forming the intersection, whether the intersection is a “T” or a four-way intersection, etc.).
  • Updated map 104 allows non-road-bound traffic to be routed more effectively than it would be using map 301.
  • map 301 there is only one route for a vehicle (e.g., a delivery robot) traveling northbound on 5th Avenue to make a right turn on 1st Street.
  • the vehicle may be responsible for local navigation, in which case the details of navigating the intersection would be left to the vehicle, which may make poor decisions.
  • updated map 104 there are numerous ways to turn right from 5th Avenue onto 1st Street, depending on which side of 5th Avenue the vehicle starts on, which side of 1st Street the vehicle should end up on, etc.
  • updated map 104 allows the routing engine (e.g., AV routing engine 100) to apply different turn constraints and/or costs to different maneuvers through the intersection.
  • Updated map 104 is an example of a pedestrian map (which can be used to route pedestrians as well as other non-road-based traffic, such as delivery robots). As such, the representations of roads 302 (FIG. 3 A) have been removed. In some embodiments, however, updated map 104 includes representations of roads 302, as well as the representations of sidewalks 304 and representations of crosswalks 308, and thus can be used to map road-based and non-road-based traffic. In some embodiments, the various representations (e g., edges) comprising the graph are labeled with attributes indicating their type (e.g., road, sidewalk, crosswalk), so that non-road-based traffic may be routed on nonroads and road-based traffic may be routed on roads.
  • attributes indicating their type
  • representations may be tagged with other pertinent attributes (e.g., surface type, various hazards, suitability for autonomous vehicles) such that costs (e.g., in a cost model) can be associated with the pertinent attributes (e.g., a fleet manager 108 can apply costs to representations with particular attributes).
  • AV routing engine 106 then generates routes in accordance with the cost model.
  • FIGS. 3E-3G illustrate an example of pre-processing operations that are optionally performed on an initial map (e.g., an open source map) before updating the map to include representations of sidewalks and/or crosswalks.
  • an initial map e.g., an open source map
  • the operations described with reference to FIGS. 3E-3G occur before the operations described with reference to FIGS. 3A-3D.
  • the pre-processing operations result in an intermediate map.
  • the intermediate map is not stored for long-term use, but instead is used to create the updated map.
  • map 301 (FIG. 3 A) is an intermediate map, generated in accordance with the pre-processing operations described below.
  • FIG. 3E illustrates an initial map 102.
  • Initial map 102 includes an intersection 303 (between Palm Avenue and Holloway Drive) that includes two nodes and a short edge between the two nodes. The two nodes arise from the fact that one side of Palm Avenue is slightly offset from the other side, making intersection 303 somewhat complex. While this feature of initial map 102 is generally acceptable for routing street-bound vehicles, if the process described with reference to FIGS. 3A-3D were to be applied to the initial map 102 shown in FIG. 3E, the result would be as shown in FIG. 3F, which shows a jumble of overlapping representations of sidewalks and crosswalks. The map shown in FIG. 3F is less than optimal for routing non-street-bound traffic, because of the unnecessarily complex geometry of the intersection. In addition, with the map shown in FIG. 3F, it may not be clear which user-defined constraints to map to which edges and nodes.
  • one or more pre-processing operations are performed on the initial map 102 prior to adding the representations of sidewalks and/or crosswalks (e.g., the representations of sidewalks and/or crosswalks are added to the pre-processed, or intermediate, map).
  • the process includes merging complex intersections (e.g., merging nodes from two or more nodes belonging to a single intersection to produce a single node for the intersection, and eliminating short edges between the merged nodes).
  • the nodes in the road graph e.g., the initial map 102
  • the initial map 102 are within a certain distance of each other (e.g., 6- 7 meters)
  • the nodes are merged by averaging a location of the nodes.
  • the average is a weighted average (e.g., in which the weighting is based on a number of edges connected to each node).
  • the edges from the merged nodes are transformed (e.g., repositioned) to start or end at the merged node.
  • the short edge coupling the merged nodes is removed (e g., not included in the intermediate map).
  • FIG. 3G shows an example of an updated map in which these pre-processing operations have been performed to generate an intermediate map from which the updated map is generated.
  • FIG. 4 illustrates an example of an updated map 104 with added representations of sidewalks and crosswalks, in accordance with some embodiments.
  • two representations of crosswalks 308 are added for each road (e.g., one for the left ride of the road and one for the right side of the road).
  • a representation of a sidewalk 310 corresponding to the end of a road is added for each road that terminates (e.g., as a cul-de-sac).
  • a number and position of representations of crosswalks 308 differ for various intersections 306 (e.g., depending on a heuristic that is based at least in part on the geometry of the intersection and the number of roads in the intersection).
  • FIG. 5A-5C illustrate different manners of applying user-specified constraints for routing trips over sidewalks in the geographic area, in accordance with some embodiments.
  • FIGS. 5A-5C illustrate displayed maps 500.
  • displayed maps 500 are displayed on a graphical user interface provided by client portal 113 (e.g., such that a fleet manager 108 can assign the user-specified constraints).
  • client portal 113 e.g., such that a fleet manager 108 can assign the user-specified constraints.
  • displayed map 500a indicates that a fleet manager has selected an area 502 over which to apply constraints to sidewalks.
  • the graphical user interface has highlighted all of the representations of sidewalks that are at least partially included within the selected area 502.
  • the user can then select a type of constraint to apply to the selected sidewalks (e g., an absolute constraint or a cost to associate with traversal of the sidewalks).
  • FIG 5B illustrates an analogous displayed map 500b, in which the user has selected an area 504 over which to apply constraints to crosswalks within the selected area (e.g., the user can specify what types of representations over which to apply the constraints, such as applying constraints to sidewalks and/or applying constraints to crosswalks).
  • FIG. 5C illustrates displayed map 500c, in which the user has selected a particular route 506 along which to apply constraints (e.g., the user has the option of applying constraints to a particular area or to a particular route).
  • applying user-specified constraints comprises modifying a cost associated with a respective sidewalk or crosswalk (in which the sidewalk or crosswalk is specified/selected by region or path).
  • FIG. 6 is a block-diagram illustrating routing system 100, in accordance with some embodiments.
  • the routing system 100 typically includes one or more central processing units/cores (CPUs) 602, one or more network interfaces 604, memory 606, and one or more communication buses 608 for interconnecting these components.
  • CPUs central processing units/cores
  • network interfaces 604
  • memory 606 memory 606
  • communication buses 608 for interconnecting these components.
  • Memory 606 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices; and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices.
  • Memory 606 optionally includes one or more storage devices remotely located from one or more CPUs 602.
  • Memory 606, or, alternatively, the non-volatile solid-state memory device(s) within memory 606, includes a non-transitray computer-readable storage medium.
  • memory 606. or the non-transitray computer-readable storage medium of memory 606, stores the following programs, modules and data structures, or a subset or superset thereof: • an operating system 610 that includes procedures for handling various basic system services and for performing hardware-dependent tasks;
  • a network communication module 612 that is used for connecting the routing system 100 to other computing devices via one or more network interfaces 604 (wired or wireless) connected to one or more networks 112 (FIG. 1 );
  • server application modules 614 for performing various functions with respect to providing routing and dispatching services
  • the server application modules 614 including, but not limited to, one or more of: o an A V routing engine 106 for executing one or more algorithms to determine routes and estimated times of arrival, and to dispatch vehicles; o a client portal 113 (e.g., an API) for receiving trip requests and vehicle information (e.g., location information) from a fleet manager (e.g., fleet manager 108), as well as constraints and map corrections and updates (such as attributes of particular sidewalks and/or crosswalks);
  • vehicle information e.g., location information
  • constraints and map corrections and updates such as attributes of particular sidewalks and/or crosswalks
  • the one or more server data module(s) 630 include: o an updated map 104 that includes representations of sidewalks and/or crosswalks added by the routing system 100 to a map 102 (FIG.
  • constraints 115 applied to particular sidewalks and/or crosswalks, particular geographic areas, sidewalks and/or crosswalks that meet particular criteria, etc
  • the constraints may be stored as absolute constraints (e.g., a prohibition against a vehicle traversing a particular sidewalk) or as costs (e.g., a costs of a vehicle traversing a particular sidewalk), in which case the constraint saves to discourage but not forbid the AV routing engine 106 from routing a vehicle over the particular sidewalk.
  • different fleets can apply different constraints to their vehicles (and are thus fleet-specific); and o cost model 632 (e.g., fleet-specific cost models) for the geographical area.
  • cost model 632 includes a cost for each sidewalk and crosswalk in updated map 104.
  • cost model 632 includes costs for roads and other features of updated map 104.
  • AV routing engine 106 uses the cost model 632 to generate routes and estimated times of arrival (e.g., generates routes in accordance with the cost model 632 and estimates times of arrival based on the generated routes), and reach dispatching decisions.
  • the routing system 100 includes web or Hypertext Transfer Protocol (HTTP) servers, File Transfer Protocol (FTP) servers, as well as web pages and applications implemented using Common Gateway Interface (CGI) script, PHP Hyper- text Preprocessor (PHP), Active Server Pages (ASP), Hyper Text Markup Language (HTML), Extensible Markup Language (XML), Java, JavaScript, Asynchronous JavaScript and XML (AJA.X), XHP, Javelin, Wireless Universal Resource File (WURFL), and the like.
  • HTTP Hypertext Transfer Protocol
  • FTP File Transfer Protocol
  • CGI Common Gateway Interface
  • PHP PHP Hyper- text Preprocessor
  • ASP Active Server Pages
  • HTML Hyper Text Markup Language
  • XML Extensible Markup Language
  • Java Java
  • JavaScript JavaScript
  • AJA.X Asynchronous JavaScript and XML
  • XHP Javelin
  • WURFL Wireless Universal Resource File
  • Each of the above identified modules stored in memory 606 corresponds to a set of instructions for performing a function described herein.
  • the above identified modules or programs i.e., sets of instructions
  • memory 606 optionally stores a subset or superset of the respective modules and data structures identified above.
  • memory 606 optionally stores additional modules and data structures not described above.
  • FIG. 6 illustrates the routing system 100 in accordance with some embodiments
  • FIG. 6 is intended more as a functional description of the various features that may be present in one or more routing systems than as a structural schematic of the embodiments described herein.
  • items shown separately could be combined and some items could be separated.
  • some items shown separately in FIG. 6 could be implemented on single servers and single items could be implemented by one or more savers.
  • updated map 104 and/or constraints 115 are stored on devices (e.g., external databases) that are accessed by routing system 100.
  • FIGS. 7A-7B illustrate a method of routing on sidewalks, in accordance with some embodiments.
  • Method 700 may be performed (702) at a server system (e.g., routing system 100, FIG. 1 ) having one or more processors and memory storing instructions for execution by the one or more processors.
  • the method 700 is performed by executing instructions stored in the memory (e.g., memory 606, FIG. 6) of the server system
  • the method 700 is performed by a combination of the server system and an electronic device (e.g., a fleet manager 108 and/or vehicles 110, FIG. 1 )
  • the server system obtains (704) a map (e.g., amap 102) that includes representations of a plurality of* roads within a geographical area.
  • the obtained map is an open source map (e g., OpenStreetMap).
  • the map includes sparse or incomplete sidewalk, and/or crosswalk data (e.g., sparse or incomplete representations of sidewalks and/or crosswalks).
  • the map includes no sidewalk and/or crosswalk data.
  • the obtained map is a standard definition map.
  • the server system updates (706) the map by adding (708) representations of a plurality of sidewalks within the geographical area.
  • the plurality of sidewalks include, for each road of the plurality of roads within the geographical area, a respective representation of a sidewalk.
  • the plurality of roads for which sidewalks are added does not include roads of a predefined type (e.g., highways).
  • the plurality of roads for which sidewalks are added does not include roads for which sidewalk data already exists (e.g., recognizing the fact that the map .102 may include sparse sidewalk and/or crosswalk data).
  • updating the map includes storing the representations of the added sidewalks as part of the map.
  • the representations of the added sidewalks are stored with an attribute indicating that their type is “sidewalk.”
  • the obtained map includes a plurality of representations of intersections between roads (e.g., nodes, as shown in FIG. 3E).
  • the server system merges, based on proximity criteria, respective representations of intersections in the obtained map to create an intermediate map.
  • the updating of the map by adding representations of the plurality of sidewalks within the geographical area is performed using the intermediate map (e.g., as described with reference to FIG. 3E-3F).
  • the plurality of representations of roads on the obtained map comprise edges on a graph and the plurality of representations of intersections comprise nodes on the graph.
  • the proximity criteria include a criterion that is met when the representations of intersections are within a predefined geographical distance of one another (e.g., 5-10 meters).
  • merging the representations of intersections in the obtained map includes generating a new representation of the intersection (e.g., a single new node on the intermediate map) that is positioned according to an average position of the merged representations of intersections.
  • the average position is a weighted average (e.g., weighted in accordance with a number of edges connected to each node being merged).
  • the intermediate map does not include the representations of intersections that have been merged (e.g., the intermediate map includes the single new node but not the nodes that were used to create the single new node).
  • merging the representations of intersections includes eliminating (removing) edges between the merged representations of intersections (e.g., eliminating/removing the small edge connecting the two merged nodes).
  • updating the map by adding representations of a plurality of sidewalks within the geographical area includes adding (710), for each road of the plurality of roads within the geographical area, a respective representation of a sidewalk for each side of the road (e.g., adding two sidewalks for each road of the plurality of roads).
  • a position of each added representation of a sidewalk on the map is offset from the corresponding road (e.g., by a predefined distance, such as 20 feet, such that the position of the representation of the sidewalk amounts to an educated guess as to where the sidewalk is likely to be positioned).
  • the map comprises a graph and the representations of the plurality of sidewalks are edges on the graph.
  • the graph includes nodes representing turns (e.g., intersections between sidewalks and/or sidewalks and crosswalks).
  • the representations of the plurality of sidewalks are bidirectional edges on the graph (e.g., a route can include travel along either direction along the edge).
  • updating the map includes determining (712) the presence of an intersection between respective roads of the plurality of roads within the geographic area and adding (714), to the map, a crosswalk corresponding to the intersection.
  • updating the map includes adding (716) a plurality of crosswalks corresponding to the intersection.
  • the plurality of crosswalks comprises a number of crosswalks selected in accordance with a heuristic for the intersection. For example, in some embodiments, four crosswalks are added to a four-way intersection for which the roads meet at substantially right angles (e g., within 10 degrees of right angles), whereas three crosswalks are added to an intersection that forms a “T.”
  • the server system receives (718) a user-specified constraint for routing trips over sidewalks in the geographic area.
  • the user-specified constraints are provided by a user (e.g., fleet manager 108).
  • the user-specified constraints are provided through an API and/or graphical user interface provided by the server system.
  • the user-specified constraints are applied over a user-selected area (e.g., as shown in FIG. 5 A and SB).
  • the user-specified constraints are applied along a particular path (e.g., as shown in FIG. 5C).
  • the user-specified constraints are applied to edges or nodes of the graph having a particular attribute.
  • the attribute is a type, such as “sidewalk” or “crosswalk.” Staled another way, the user can applied user- specified constraints to all sidewalks within a particular area, or all crosswalks within a particular area, or all sidewalks along a particular route, or all crosswalks along a particular route.
  • the attribute is a surface roughness, incline, or other property of the sidewalk and/or crosswalk.
  • the user-specified constraints are absolute constraints (e.g., that prevent routing along the edges and/or nodes to which the constraints apply).
  • the user-specified constraints are cost-based constraints (e.g., that apply a cost, or a multiplier of an existing cost, to routing along the edges and/or nodes to which the constraints apply). Cost-based constraints have the effect of discouraging, but not prohibiting, routing along the edges and/or nodes to which the constraints apply.
  • constraints are appropriate in a wide variety of circumstances, such as where routing through a geographical area presents an acceptable-level of risk (e.g., to a delivery robot) or is likely to require human intervention from a tele-operator (e.g., in the case of human-supervised autonomous vehicles).
  • the server system generates (720) a cost model for the geographical area.
  • the cost model includes a cost for each of the pl urality of sidewalks. In some embodiments, one or more of the costs is based at least in part on a user-specified constraint, as described above.
  • the server system receives (722) a request to route a trip over sidewalks in the geographical area.
  • the trip includes a starting location and an ending location (e.g., a destination).
  • the request to route the trip also includes a request to dispatch a vehicle in a fleet of vehicles (e.g.. determine, based on location and state information for vehicles in the fleet of vehicles, which vehicle to dispatch and to provide a route for the dispatched vehicle).
  • the request to route a trip is a request to route a vehicle.
  • the vehicle is an autonomous vehicle.
  • the vehicle is a robot (e.g., a delivery robot).
  • an autonomous vehicle is one that, is capable of operating autonomously at least in some circumstances.
  • local navigation e.g., finding a sidewalk, avoiding pedestrians
  • the autonomous vehicles described herein are supervised remotely by a tele-operator, such that, when an autonomous vehicle encounters a situation that it cannot handle, the tele-operator may intervene to direct the autonomous vehicle.
  • Method 700 reduces the need for human intervention by reducing the likelihood that an autonomous vehicle encounters such a situation (e.g., reducing the likelihood that an autonomous vehicle ends up on the wrong side of the street, unable to cross, as described with respect to FIGS. 2A-2B).
  • the server system routes (724) the trip using the updated map.
  • the system routes the trip using a routing algorithm (e.g., Dijkstra’s algorithm).
  • the trip is routed (726) using the updated map based on the user- specified constraints.
  • the trip is routed (728) using the updated map based on the costs of respective sidewalks traversed during the route. For example, the server system routes the trip using the “shortest path” between the starting location and the ending location (along the edges and nodes in the graph), where the “length” of each edge is based on the cost of the edge (which may, in turn, be based on the travel distance and travel time, as well as any user-specified or other constraints).
  • the trip is routed (730) over the crosswalk.
  • the server system receives (732) a user-specified indication that a respective sidewalk added to the map does not exist In response to receiving the user-specified indication that the respective sidewalk added to the map does not exist the server system removes (734) the respective sidewalk from the map. [0064] In some embodiments, after routing the trip, the server system receives data from the vehicle indicating attributes of the added representations of sidewalks and/or crosswalks.
  • the vehicle 110 includes attitude and/or accelerometer sensors, which can be used to establish attributes of sidewalks and/or crosswalks, e.g., incline and surface roughness, respectively.
  • the vehicles provide this sensor data (e.g., without user intervention) to the server system, which determines the attributes and applies the attributes to the corresponding representations of sidewalks and/or crosswalks.
  • the server system is then able to route subsequent trips using costs and/or constraints associated with these attributes (e.g., user-specified costs, such as a constraint not to travel over sidewalks for which the surface is too poor, as indicated by the surface roughness).
  • the disclosed embodiments allow for better routing, not just because of the situations described with respect to FIG. 2A-2B, but also because inclusion of sidewalks and crosswalks on the map allows attributes of these sidewalks and crosswalks to be obtained much more readily (as compared to waiting for someone to add the crosswalks in their attributes to an open source map). While these embodiments may add representations of sidewalks and crosswalks that do not physically exists, these problems are likely to be corrected much more quickly than waiting for generation of accurate data via open source maps.
  • first means “first,” “second,” etc.
  • second means “first,” “second,” etc.
  • first vehicle could be termed a second vehicle
  • first vehicle which changing the meaning of the description, so long as all occurrences of the “first vehicle” are renamed consistently and all occurrences of the second vehicle are renamed consistently.
  • the first vehicle and the second vehicle are both vehicles, but they are not the same vehicle (e.g., the second vehicle is an additional vehicle).
  • the phrase “if it is determined (that a stated condition precedent is true)” or “if (a stated condition precedent is true)” or “when (a stated condition precedent is true)” is, optionally, construed to mean “upon determining” or “in response to determining” or “in accordance with a determination” or “upon detecting” or “in response to detecting” that the stated condition precedent is true, depending on the context.

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Resources & Organizations (AREA)
  • Automation & Control Theory (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Traffic Control Systems (AREA)

Abstract

L'invention concerne des systèmes et des procédés d'aménagement d'itinéraire sur des trottoirs. Le procédé consiste à obtenir une carte qui comprend des représentations d'une pluralité de routes dans une zone géographique. Le procédé consiste en outre à mettre à jour la carte en ajoutant des représentations d'une pluralité de trottoirs à l'intérieur de la zone géographique, y compris ajouter, pour chaque route de la pluralité de routes à l'intérieur de la zone géographique, une représentation respective d'un trottoir. Le procédé consiste également à recevoir une demande d'aménagement d'un itinéraire sur des trottoirs dans la zone géographique. Le procédé consiste en outre à aménager l'itinéraire à l'aide de la carte mise à jour.
PCT/US2022/011386 2021-01-08 2022-01-06 Systèmes et procédés d'aménagement d'itinéraire sur des voies piétonnes WO2022150438A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163135416P 2021-01-08 2021-01-08
US63/135,416 2021-01-08

Publications (1)

Publication Number Publication Date
WO2022150438A1 true WO2022150438A1 (fr) 2022-07-14

Family

ID=82358323

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/011386 WO2022150438A1 (fr) 2021-01-08 2022-01-06 Systèmes et procédés d'aménagement d'itinéraire sur des voies piétonnes

Country Status (1)

Country Link
WO (1) WO2022150438A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6208934B1 (en) * 1999-01-19 2001-03-27 Navigation Technologies Corp. Method and system for providing walking instructions with route guidance in a navigation program
US20110246055A1 (en) * 2010-03-30 2011-10-06 Huck Arnulf F Method of operating a navigation system to provide a pedestrian route
US8090532B2 (en) * 2007-12-14 2012-01-03 Microsoft Corporation Pedestrian route production

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6208934B1 (en) * 1999-01-19 2001-03-27 Navigation Technologies Corp. Method and system for providing walking instructions with route guidance in a navigation program
US8090532B2 (en) * 2007-12-14 2012-01-03 Microsoft Corporation Pedestrian route production
US20110246055A1 (en) * 2010-03-30 2011-10-06 Huck Arnulf F Method of operating a navigation system to provide a pedestrian route

Similar Documents

Publication Publication Date Title
US11415427B2 (en) Providing traffic warnings to a user based on return journey
US11884293B2 (en) Operator assistance for autonomous vehicles
JP7344120B2 (ja) 軌道生成および実行アーキテクチャ
US10429195B2 (en) Method, apparatus, and computer program product for generation of a route using time and space
US8214142B2 (en) System and method for efficient routing on a network in the presence of multiple-edge restrictions and other constraints
US20210103286A1 (en) Systems and methods for adaptive path planning
US8121749B1 (en) System for integrating dynamically observed and static information for route planning in a graph based planner
US11396307B2 (en) Method and system for context-aware decision making of an autonomous agent
US20100274430A1 (en) Detection of topological structure from sensor data with application to autonomous driving in semi-structured environments
US20220326030A1 (en) Systems and methods of generating composite routing maps
CN112444263B (zh) 全局路径规划方法及装置
KR20200130736A (ko) 주차 루트들을 생성하기 위한 방법들 및 시스템들
CN109491378A (zh) 自动驾驶车辆的基于道路分段的路线引导系统
EP4174440A1 (fr) Planification de trajet sensible à l'environnement pour un véhicule autonome utilisant une recherche dynamique de taille de pas
WO2022052856A1 (fr) Procédé et appareil de traitement de données basés sur un véhicule, ordinateur et support d'enregistrement
US11260875B2 (en) Systems and methods for road surface dependent motion planning
JP7211605B2 (ja) 地形を考慮したルート計画
WO2022150438A1 (fr) Systèmes et procédés d'aménagement d'itinéraire sur des voies piétonnes
CN116772850A (zh) 基于数字孪生的智慧园区导航方法、装置、设备及存储介质
WO2021242416A1 (fr) Systèmes et procédés de traduction de contraintes de routage en une carte
WO2023282997A1 (fr) Acheminement de véhicule à sélection dynamique de bifurcations à travers un trafic opposé
US20220065638A1 (en) Joint routing of transportation services for autonomous vehicles
Petti et al. Prediction of road users behaviour and dynamic motion control in ROS

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22737083

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22737083

Country of ref document: EP

Kind code of ref document: A1