CN113748316B

CN113748316B - System and method for vehicle telemetry

Info

Publication number: CN113748316B
Application number: CN201880100687.2A
Authority: CN
Inventors: 侯庭波; 项国民
Original assignee: Beijing Voyager Technology Co Ltd
Current assignee: Beijing Voyager Technology Co Ltd
Priority date: 2018-12-26
Filing date: 2018-12-26
Publication date: 2024-01-02
Anticipated expiration: 2038-12-26
Also published as: WO2020139327A1; CN113748316A

Abstract

Techniques for controlling transmission and processing of vehicle telemetry data are disclosed. Route data configured for navigating a vehicle is accessed. Using the route data, telemetry broadcast parameters are generated. The telemetry broadcast parameters are transmitted to the vehicle. A transmission of telemetry data according to the broadcast parameters is received from the vehicle. The received telemetry data is used in generating a simulated environment for the route planning learning engine, simulating the vehicle, verifying the route and map, and/or performing vehicle diagnostics.

Description

System and method for vehicle telemetry

Incorporation by reference of any priority application

Any and all applications claiming foreign or domestic priority in the application data sheet filed with the present application are incorporated herein by reference in accordance with 37 CFR 1.57.

Copyright statement

Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the U.S. patent and trademark office file or records, but otherwise reserves all copyright rights whatsoever.

Technical Field

The invention relates to the technical field of vehicle telemetry, in particular to a system and a method for vehicle telemetry.

Background

Vehicles, such as vehicles for shared travel purposes, vehicles providing driver assistance functions, and/or automated or Autopilot Vehicles (AV), may acquire and process sensor data using an onboard data processing system to perform a variety of functions. For example, the functions may include determining and/or displaying navigation routes, identifying road signs, detecting objects and/or road obstacles, controlling vehicle operation, and/or the like.

An autonomous car will drastically change the way of traffic and simplify it. However, in order for an autonomous vehicle to fully exploit its potential, the autonomous vehicle needs to be able to safely navigate even in dynamically changing environments.

Disclosure of Invention

The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

One aspect of the present disclosure relates to the early generation of alternative routes. According to one aspect, an initial route may be generated for an autonomous vehicle. In addition, one or more alternative routes may be generated corresponding to different nodes on the initial route. One or more alternative routes may be downloaded to the autonomous vehicle along with the initial route. In response to detecting that the environment makes continued use of the initial route at the given route node impossible or disadvantageous, a corresponding alternative route may be identified and selected. The vehicle may then be driven using the alternative route.

Another aspect of the present disclosure relates to the efficient transmission of autonomous vehicle telemetry data, such as vehicle position and sensor data. Such autonomous vehicle telemetry data may be used to perform error correction, diagnostics, route verification, map verification, vehicle simulation, route simulation, and training of route planning learning engines.

Drawings

FIG. 1A illustrates a block diagram of a networked vehicle environment in which one or more vehicles and/or one or more user devices interact with a server via a network, according to one embodiment.

FIG. 1B illustrates a block diagram showing the vehicle of FIG. 1A communicating with one or more other vehicles and/or servers of FIG. 1A, according to one embodiment.

FIG. 1C illustrates a block diagram of an example processing system.

Fig. 2A is an example diagram illustrating an autonomous vehicle encountering an abnormal event.

FIG. 2B is an example diagram illustrating an autonomous vehicle taking an alternative route in response to encountering an abnormal event.

FIG. 3 illustrates an example process of generating an alternative route for an abnormal event.

FIG. 4 illustrates an example process for determining when to pre-generate an alternative route.

FIG. 5 illustrates an example real-time process for determining when to generate a request for an alternative route.

FIG. 6 illustrates an example graph that may be utilized in determining when to generate a request for an alternative route.

FIG. 7 illustrates an example process of transmitting and utilizing autonomous vehicle position and sensor data.

Detailed Description

As mentioned above, in order for an autonomous vehicle to exert its full potential, it is essential that the autonomous vehicle is able to navigate safely even in constantly changing environments and even if such environmental changes may prevent the vehicle from traveling on its planned route. For example, an autonomous vehicle should be able to accommodate sudden road closure, lane congestion, train passage, emergency or police vehicle passage, flooding, and/or other dynamic conditions in a safe manner, yet still enable passengers to reach the originally intended destination.

Conventionally, when a user wishes to be carried to a destination using an autonomous vehicle, the user provides the destination. The vehicle route planning system will plan a travel route from the origin to the destination. However, if the vehicle is unable to follow the planned travel route from the starting location to the destination (e.g., due to an accident or street congestion), the vehicle may request that a new route be generated. However, depending on the particular situation, delays in waiting for new routes to be generated in response to route interruptions may lead to unsafe conditions or missed opportunities to take the most efficient new routes. Alternatively, if the autonomous vehicle is unable to follow the planned travel route, the vehicle simply considers stopping and/or requires the human to take over the driving of the autonomous vehicle in a conventional manner.

Disclosed herein are methods and systems for dynamically adapting routing to dynamically changing environments using pre-generated alternative routes. As will be described, an initial route may be generated for an autonomous vehicle. Further, one or more alternative routes may be generated corresponding to different points on the initial route. One or more alternative routes may be downloaded to the autonomous vehicle along with the initial route. In response to detecting that the environment makes continued use of the initial route at the given route point impossible or disadvantageous, a corresponding alternative route may be identified and selected. The vehicle may then be driven using the corresponding alternative route.

Furthermore, to enhance safe and efficient operation of an autonomous vehicle, it is useful to be able to collect and analyze telemetry data from a large number of actual operating autonomous vehicles. Such data may be used to identify and correct vehicle errors or malfunctions, verify map data, and/or improve future routing of an autonomous vehicle. Accordingly, disclosed herein are methods and systems for transmitting and utilizing autonomous vehicle position and sensor data for error correction, diagnosis, verification, simulation, and training of a route planning learning engine.

Detailed descriptions and examples of systems and methods according to one or more illustrative embodiments of the present disclosure may be found in the section entitled "safe route planning for autonomous vehicles and autonomous vehicle telemetry" and the section entitled "example embodiments" and fig. 1C-7 herein. Again, the components and functions for safe route planning and autonomous vehicle telemetry may be configured and/or incorporated into the networked vehicle environment 100 described herein in fig. 1A-1B.

The various embodiments described herein are closely related to, can be implemented by, and are dependent upon, computer technology. For example, generating alternative routes described herein with reference to various embodiments and using such alternative routes in response to sensor data when controlling an autonomous vehicle cannot reasonably be performed alone by a human without the computer technology upon which they are implemented. Similarly, the efficient broadcasting of autonomous vehicle telemetry data, as well as the use of such telemetry data for component fault detection, vehicle simulation, route planning simulation, and other uses described herein with reference to various embodiments, cannot be reasonably performed alone by humans without implementing the computer technology upon which they are based.

Networked vehicle environment

FIG. 1A illustrates a block diagram of a networked vehicle environment 100 in which one or more vehicles 120 and/or one or more user devices 102 interact with a server 130 via a network 110, according to one embodiment. For example, the vehicle 120 may be equipped to provide travel sharing and/or other location-based services to assist the driver in controlling vehicle operation (e.g., via a variety of driver assistance features such as adaptive and/or conventional cruise control, adaptive headlamp control, antilock braking, automatic parking, night vision, blind spot monitoring, crashworthiness, crosswind stabilization, driver fatigue detection, driver monitoring systems, emergency driver assistance, intersection assistance, hill descent control, intelligent speed adaptation, lane centering, lane departure warning, front, rear and/or side parking sensors, pedestrian detection, rain sensors, look-around systems, tire pressure monitors, traffic sign recognition, steering assistance, false road driving warnings, traffic condition cues, etc.) and/or to fully control vehicle operation. Thus, the vehicle 120 may be a conventional gasoline, natural gas, biofuel, electricity, hydrogen, etc. vehicle configured to provide shared travel and/or other location-based services, a vehicle providing driver assistance functionality (e.g., one or more of the driver assistance features described herein), or an automated or Autonomous Vehicle (AV). The vehicle 120 may be a car, truck, minibus, bus, motorcycle, scooter, bicycle, and/or any other motor vehicle.

The server 130 may communicate with the vehicle 120 to obtain vehicle data, such as route data, sensor data, awareness data, vehicle 120 control data, vehicle 120 component failure and/or failure data, and the like. Server 130 may process and store these vehicle data for use in other operations performed by server 130 and/or another computing system (not shown). Such operations may include running a diagnostic model to identify vehicle 120 operational problems (e.g., causes of vehicle 120 navigation errors, abnormal sensor readings, unidentified objects, vehicle 120 component failures, etc.); running a model to simulate the performance of the vehicle 120 given a set of variables; identifying objects that are not identifiable by the vehicle 120, generating control instructions that, when executed by the vehicle 120, cause the vehicle 120 to travel and/or move in some manner along a specified path; and/or the like.

The server 130 may also transmit data to the vehicle 120. For example, the server 130 may transmit map data, firmware and/or software updates, vehicle 120 control instructions, identification of objects that have not been identified by the vehicle 120, passenger access information, traffic data, and/or the like.

In addition to communicating with one or more vehicles 120, the server 130 can also communicate with one or more user devices 102. In particular, the server 130 may provide web services to enable users to request location-based services (e.g., shipping services, such as shared travel services) through applications running on the user device 102. For example, the user device 102 may correspond to a computing device, such as a smart phone, tablet, notebook, smartwatch, or any other device that may communicate with the server 130 over the network 110. In this embodiment, the user device 102 executes an application, such as a mobile application, which may be used by a user operating the user device 102 to interact with the server 130. For example, the user device 102 may communicate with the server 130 to provide location data and/or queries to the server 130, receive map-related data and/or directions from the server 130, and/or the like.

Server 130 may process the request and/or other data received from user device 102 to identify a service provider (e.g., a driver of vehicle 120) to provide the requested service to the user. Further, the server 130 may receive data, such as user travel access or destination data, user location query data, etc., based on which the server 130 identifies areas, addresses, and/or other locations associated with various users. The server 130 may then use the identified location to provide a direction to the service provider and/or user pointing to the determined access location.

An application running on the user device 102 may be created and/or manufactured by the same entity responsible for the server 130. Alternatively, the application running on the user device 102 may be a third party application that includes features (e.g., an application programming interface or a software development kit) that enable communication with the server 130.

For brevity and ease of explanation, one server 130 is illustrated in FIG. 1A. However, it should be appreciated that server 130 may be a single computing device or may comprise a plurality of different computing devices logically or physically grouped together to operate collectively as a server system. The components of server 130 may be implemented in dedicated hardware (e.g., a server computing device having one or more ASICs) without software, or may be implemented as a combination of hardware and software. In addition, the modules and components of server 130 may be combined on one server computing device or separated or grouped separately on several server computing devices. In some embodiments, server 130 may include more or fewer components than shown in FIG. 1A.

Network 110 includes any wired network, wireless network, or combination thereof. For example, the network 110 may be a personal area network, a local area network, a wide area network, an over-the-air network (e.g., a network for broadcast or television), a cable network, a satellite network, a cellular telephone network, or a combination thereof. As another example, the network 110 may be a publicly accessible network linking networks, possibly run by various different parties, such as the internet. In some embodiments, the network 110 may be a private or semi-private network, such as a corporate or university intranet. The network 110 may include one or more wireless networks, such as those used in the global system for mobile communications (GSM) networks, code Division Multiple Access (CDMA) networks, long Term Evolution (LTE) networks, or any other type of wireless network. The network 110 may use protocols and components for communicating via the internet or any other of the networks described above. For example, protocols used by network 110 may include hypertext transfer protocol (HTTP), hypertext transfer security protocol (HTTPs), message Queue Telemetry Transport (MQTT), constrained application protocol (CoAP), and the like. Protocols and components for communicating via the internet or any other type of communication network described above are well known to those skilled in the art and will not be described in detail herein.

The server 130 may include a navigation unit 140, a vehicle data processing unit 145, and a data store 150. The navigation unit 140 may assist in location-based services. For example, the navigation unit 140 may assist a user (also referred to herein as a "driver") in transporting another user (also referred to herein as a "rider") and/or an object (e.g., food, parcel, etc.) from a first location (also referred to herein as a "pickup location") to a second location (also referred to herein as a "destination location"). The navigation unit 140 may assist in achieving user and/or object transport by providing maps and/or navigation instructions to applications running on the driver's user device 102, to applications running on the lift's user device 102, and/or to navigation systems running on the vehicle 120.

As an example, the navigation unit 140 may include a matching service (not shown) that pairs a lift person requesting a journey from the pick-up location to the destination location with a driver capable of completing the journey. The matching service may interact with an application running on the user device 102 of the lift and/or an application running on the user device 102 of the driver to establish the lift's journey and/or to process the payments made to the driver by the lift.

The navigation unit 140 may also communicate with an application running on the driver's user device 102 during the journey to obtain journey location information from the user device 102 (e.g., via a Global Positioning System (GPS) component coupled to and/or embedded in the user device 102) and provide navigation directions to the application, which aids the driver in driving from the current location to the destination location. The navigation unit 140 may also indicate a plurality of different geographic locations or points of interest to the driver, whether or not the driver is on a lift.

The vehicle data processing unit 145 may be configured to support driver assistance features of the vehicle 120 and/or to support autonomous driving. For example, the vehicle data processing unit 145 may generate and/or transmit map data to the vehicle 120, run a diagnostic model to identify operational problems with the vehicle 120, run a model to simulate the performance of the vehicle 120 given a set of variables, use the vehicle data provided by the vehicle 120 to identify objects and transmit an identification of the objects to the vehicle 120, generate and/or transmit vehicle 120 control instructions and/or type operations to the vehicle 120.

The data store 150 may store various types of data used by the navigation unit 140, the vehicle data processing unit 145, the user device 102, and/or the vehicle 120. For example, the data store 150 may store user data 152, map data 154, search data 156, and log data 158.

The user data 152 may include information concerning some or all users of the location-based service, such as drivers and lift-ers. The information may include, for example, a user name, password, name, address, billing information, data associated with previous trips taken by or serviced by the user, user rating information, user loyalty program information, and/or the like.

Map data 154 may include high-resolution (HD) maps generated from sensors (e.g., light detection and ranging (LiDAR) sensors, radio detection and ranging (RADAR) sensors, infrared cameras, visible light cameras, stereo cameras, inertial Measurement Units (IMUs), etc.), satellite images, optical Character Recognition (OCR) performed on captured street images (e.g., identifying street names, identifying street sign words, identifying point of interest names, etc.), etc.; information for calculating a route; information for presenting a two-dimensional (2D) and/or three-dimensional (3D) graphical map; and/or the like. For example, the map data 154 may include elements: such as the layout of streets and intersections, bridges (e.g., including information about the height and/or width of bridges on the streets), exit ramps, buildings, parking lot entrances and exits (e.g., including information about the height and/or width of vehicle entrances and/or exits), locations of guideboards and stop lights, emergency turnouts, points of interest (e.g., parks, restaurants, gas stations, attractions, landmarks, etc., and associated names), road markings (e.g., centerline markings separating opposite lanes, lane markings, parking lines, left turn guidance lines, right turn guidance lines, crosswalks, bus lane markings, bike lane markings, safety island markings, pavement words, highway exits and entrance markings, etc.), curbs, railway lines, lane, turn radii and/or angles of left and right turns, distances and dimensions of road features, locations of spacers between bi-directional traffic, and/or the like elements, along with associated geographic locations (e.g., geographic coordinates) of these elements. The map data 154 may also include reference data such as real-time and/or historical traffic information, current and/or predicted weather conditions, road work information, information about laws and regulations (e.g., speed limits, whether right turns are allowed or forbidden at red light, whether turning around is allowed or forbidden, allowed directions of travel, and/or the like), news events, and/or the like.

Although the map data 154 is illustrated as being stored in the data store 150 of the server 130, this is not meant to be limiting. For example, the server 130 may transmit the map data 154 to the vehicle 120 for storage therein (e.g., in the data store 129, as described below).

Search data 156 may include searches that were entered by a number of different users. For example, the search data 156 may include a text search for access and/or destination locations. The search may be for a particular address, geographic location, name associated with a geographic location (e.g., name of a park, restaurant, gas station, attraction, landmark, etc.), and so forth.

The log data 158 may include vehicle data provided by one or more vehicles 120. For example, the vehicle data may include route data, sensor data, awareness data, vehicle 120 control data, vehicle 120 component failure and/or failure data, and the like.

FIG. 1B illustrates a block diagram showing the vehicle 120 of FIG. 1A communicating with one or more other vehicles 170A-N and/or the server 130 of FIG. 1A, according to one embodiment. As shown in fig. 1B, the vehicle 120 may include various components and/or data stores. For example, vehicle 120 may include a sensor array 121, a communication array 122, a data processing system 123, a communication system 124, an internal interface system 125, a vehicle control system 126, an operating system 127, a map engine 128, and/or a data store 129.

Communications 180 may be sent and/or received between vehicle 120, one or more vehicles 170A-N, and/or server 130. The server 130 may transmit and/or receive data from the vehicle 120, as described above in connection with fig. 1A. For example, the server 130 may transmit vehicle control instructions or commands to the vehicle 120 (e.g., as the communication 180). The vehicle control instructions may be received by a communication array 122 (e.g., an array of one or more antennas configured to transmit and/or receive wireless signals) that is operated by a communication system 124 (e.g., a transceiver). The communication system 124 may communicate vehicle control commands to a vehicle control system 126 that may operate acceleration, steering, braking, lights, signals, and other operating systems 127 of the vehicle 120 to drive and/or maneuver the vehicle 120 and/or assist a driver in driving and/or maneuvering the vehicle 120 along a direct path to a destination location specified by the vehicle control commands.

As an example, the vehicle control instructions may include route data 163 that may be processed by the vehicle control system 126 to steer the vehicle 120 and/or assist a driver in steering the vehicle 120 along a given route (e.g., an optimized route calculated by the server 130 and/or the map engine 128) to a specified destination location. In processing the route data 163, the vehicle control system 126 may generate control commands 164 for execution by the operating system 127 (e.g., acceleration, steering, braking, maneuvering, reversing, etc.) to cause the vehicle 120 to travel along the route to the destination location and/or to assist the driver in maneuvering the vehicle 120 along the route to the destination location.

The destination location 166 may be specified by the server 130 based on user requests (e.g., access requests, delivery requests, etc.) communicated from applications running on the user device 102. Alternatively or additionally, a lift user and/or driver of the vehicle 120 may provide user input 169 via the internal interface system 125 (e.g., a vehicle navigation system) to provide the destination location 166. In some embodiments, the vehicle control system 126 may communicate the input destination location 166 and/or the current location of the vehicle 120 (e.g., as a GPS data packet) as a communication 180 to the server 130 via the communication system 124 and the communication array 122. The server 130 (e.g., the navigation unit 140) may perform an optimization operation using the current location of the vehicle 120 and/or the input destination location 166 to determine an optimal route for the vehicle 120 to travel to the destination location 166. Route data 163 including the optimal route may be transmitted from server 130 to vehicle control system 126 via communication array 122 and communication system 124. Upon receiving the route data 163, the vehicle control system 126 can enable the operating system 127 to steer the vehicle 120 along the optimal route directly toward the destination location 166, assist the driver in steering the vehicle 120 along the optimal route directly toward the destination location 166, and/or enable the internal interface system 125 to display and/or present instructions for steering the vehicle 120 along the optimal route directly toward the destination location 166.

Alternatively or additionally, the route data 163 includes an optimal route and the vehicle control system 126 automatically inputs the route data 163 into the map engine 128. The map engine 128 may generate map data 165 using the optimal route (e.g., generate a map that displays the optimal route and/or take instructions for the optimal route) and provide the map data 165 to the internal interface system 125 (e.g., via the vehicle control system 126) for display. The map data 165 may include information derived from map data 154 stored in the data store 150 on the server 130. The displayed map data 165 may indicate the estimated time of arrival and/or display the travel progress of the vehicle 120 along the optimal route. The displayed map data 165 may also include indicators such as diversion commands, emergency notification, road work information, real-time traffic data, current weather conditions, information about laws and regulations (e.g., speed limits, whether right turns are allowed or forbidden at red lights, where to allow or forbidden turns around, allowed directions of travel, etc.), news events, and/or the like.

The user input 169 may also be a request to access a network (e.g., network 110). In response to such requests, the internal interface system 125 may generate access requests 168, which may be processed by the communication system 124 to configure the communication array 122 to send and/or receive data corresponding to user interactions with the internal interface system 125 and/or user device 102 interactions with the internal interface system 125 (e.g., user devices 102 connected to the internal interface system 125 through a wireless connection). For example, the vehicle 120 may include an onboard Wi-Fi that passengers and/or drivers may access to send and/or receive email and/or text messages, stream audio and/or video content, browse content pages (e.g., web pages, etc.), and/or access applications using web access. Based on the user interactions, internal interface system 125 may receive content 167 via network 110, communication array 122, and/or communication system 124. Communication system 124 may dynamically manage network access to avoid or minimize disruption of transmission of content 167.

The sensor array 121 may include any number of one or more types of sensors, such as satellite radio navigation systems (e.g., GPS), light detection and ranging (LiDAR) sensors, landscape (land slope) sensors (e.g., radio detection and ranging sensors), inertial Measurement Units (IMUs), cameras (e.g., infrared cameras, visible light cameras, stereo cameras, etc.), wi-Fi detection systems, cellular communication systems, inter-vehicle communication systems, road sensor communication systems, feature sensors, proximity sensors (e.g., infrared, electromagnetic, photoelectric, etc.), distance sensors, depth sensors, and/or the like. The satellite radio navigation system may calculate the current location of the vehicle 120 (e.g., in the range of 1-10 meters) based on analyzing signals received from the satellite constellation.

Light detection and ranging (LiDAR) sensors, radio detection and ranging sensors, and/or any other similar type of sensor may be used to detect the environment surrounding the vehicle 120 when the vehicle 120 is in motion or is about to begin motion. For example, light detection and ranging (LiDAR) sensors may be used to reflect multiple laser beams from approaching objects to evaluate their distance and provide accurate three-dimensional (3D) information about the surrounding environment. Data obtained from light detection and ranging (LiDAR) sensors may be used to perform object recognition, motion vector determination, collision prediction, and/or implement accident avoidance processes. Alternatively, light detection and ranging (LiDAR) sensors may use a rotating scanning mirror assembly to provide a 360 degree viewing angle. Light detection and ranging (LiDAR) sensors may optionally be mounted on the roof of the vehicle 120.

An Inertial Measurement Unit (IMU) may include a X, Y, Z orientation gyroscope and/or accelerometer. An Inertial Measurement Unit (IMU) provides data regarding rotational and linear motion of the vehicle 120, which can be used to calculate the motion and position of the vehicle 120.

The camera may be used to capture visual images of the environment surrounding the vehicle 120. Depending on the configuration and number of cameras in particular, the cameras may provide a 360 degree view around the vehicle 120. The image from the camera may be used to read road markings (e.g., lane markings), read street signs, detect objects, and/or the like.

Wi-Fi detection systems and/or cellular communication systems may be used to triangulate Wi-Fi hotspots or cellular towers, respectively, to determine the location of the vehicle 120 (optionally in combination with satellite radio navigation systems).

An inter-vehicle communication system (which may include a Wi-Fi detection system, a cellular communication system, and/or the communication array 122) may be used to receive and/or transmit data to other vehicles 170A-N, such as current speed and/or position coordinates of the vehicle 120, time and/or position coordinates corresponding to when a deceleration is planned, and a planned deceleration rate, time and/or position coordinates when an operation is planned to stop, time and/or position coordinates when a lane change is planned, and lane change direction, time and/or position coordinates when a turning operation is planned, time and/or position coordinates when a parking operation is planned, and/or the like.

The road sensor communication system (which may include a Wi-Fi detection system and/or a cellular communication system) may be used to read information from the road sensor (e.g., indicative of traffic flow speed and/or traffic congestion) and/or to read information from the traffic control device (e.g., traffic lights).

When a user requests a tap (e.g., through an application running on the user device 102), the user may specify a particular destination location. The origination location may be a current location of the vehicle 120, which may be determined using satellite radio navigation systems (e.g., GPS, galileo, beidou/COMPASS, DORIS, GLONASS, and/or other satellite radio navigation systems), wi-Fi positioning systems, cellular tower triangulation, and/or the like, installed in the vehicle. Alternatively, the originating location may be specified by a user through a user interface provided by the vehicle 120 (e.g., the internal interface system 125) or through the user device 102 running the application. Alternatively, the originating location may be automatically determined based on location information obtained from the user device 102. In addition to the originating location and the destination location, one or more navigation points may be designated to enable multiple destination locations.

Raw sensor data 161 from sensor array 121 may be processed by in-vehicle data processing system 123. The processed data 162 may then be transmitted by the data processing system 123 to the vehicle control system 126 and optionally to the server 130 via the communication system 124 and the communication array 122.

The data store 129 can store map data (e.g., map data 154) and/or subsets of map data 154 (e.g., a portion of map data 154 corresponding to a general area in which the vehicle 120 is currently located). In some embodiments, the vehicle 120 may record updated map data along the travel route using the sensor array 121 and transmit the updated map data to the server 130 via the communication system 124 and the communication array 122. The server 130 may then transmit the updated map data to one or more of the vehicles 170A-N and/or further process the updated map data.

The data processing system 123 may provide continuous or near continuous processing of the data 162 to the vehicle control system 126 in response to peer-to-peer activity in the environment surrounding the vehicle 120. The processed data 162 may include a comparison between raw sensor data 161, representing the operating environment of the vehicle 120 and continuously collected by the sensor array 121, and map data stored in the data store 129. In one example, the data processing system 123 is programmed with machine learning or other artificial intelligence capabilities to enable the vehicle 120 to identify and respond to conditions, events, and/or potential hazards. In variations, the data processing system 123 may continuously or near continuously compare the raw sensor data 161 with stored map data to perform positioning to continuously or near continuously determine the position and/or orientation of the vehicle 120. The positioning of the vehicle 120 may enable the vehicle 120 to learn the instant position and/or orientation of the vehicle 120 as compared to stored map data in order to maneuver the vehicle 120 across traffic on a surface street and/or assist a driver in maneuver the vehicle 120 across traffic on a surface street and identify and respond to potential hazards (e.g., pedestrians) or local conditions, such as weather or traffic conditions.

Furthermore, positioning may enable vehicle 120 to tune or beam steer control communication array 122 to maximize communication link quality and/or minimize interference with other communications from other vehicles 170A-N. For example, communication system 124 may steer the beam of radiation patterns of communication array 122 in response to network configuration commands received from server 130. The data store 129 can store current network resource map data identifying network base stations and/or other network sources providing network connectivity. The network resource map data may indicate locations of base stations and/or available network types (e.g., 3G, 4G, LTE, wi-Fi, etc.) within the area where the vehicle 120 is located.

Although fig. 1B depicts certain operations as being performed by vehicle 120 or server 130, this is not meant to be limiting. The operations performed by the vehicle 120 and the server 130 as described herein may be performed by any entity. For example, certain operations typically performed by the server 130 (e.g., transmitting updated map data to the vehicles 170A-N) may be performed by the vehicle 120 for load balancing purposes (e.g., reducing the processing load of the server 130, utilizing idle processing power on the vehicle 120, etc.).

Further, any of the vehicles 170A-N may include some or all of the components of the vehicle 120 described herein. For example, vehicles 170A-N may include a communication array 122 to communicate with vehicle 120 and/or server 130.

Safety route planning for autonomous vehicles

Sometimes, when an autonomous vehicle is executing an initially generated route, the vehicle may identify, via its one or more sensors, actual or potential environmental (e.g., road) conditions that may require deviation from the initial route or that are more advantageous from the initial route. For example, the initial route may designate a lane change of the vehicle from a center lane to a right turn lane and turn right at the designated intersection. However, if one or more vehicle sensors (e.g., light detection and ranging (LiDAR), radio detection and ranging, and/or camera sensors) indicate a right-turn lane jam and cannot be safely incorporated into the right-turn lane, the route may need to be modified.

It would be advantageous to have an alternative route that is pre-generated and immediately available so that an autonomous vehicle can quickly and safely respond to conditions requiring a change of route without violating driving rules and without causing a collision.

Several different techniques may be used to determine when to generate the alternative route and for which points in the route the alternative route should be calculated. Certain techniques may be selected to reduce the pre-processing load and memory utilization by reducing the total number of pre-generated alternative routes while still ensuring safe operation of the autonomous vehicle.

For example, before the vehicle begins the trip of the original route, a corresponding alternative route may be generated for selected or all steering and other navigation events included in the original route. Then, if the autonomous vehicle determines that it cannot safely continue following the initial route (e.g., perform a given turn, lane change, entry or exit in the initial route), the vehicle may select a corresponding generated alternative route that is immediately available. Thus, the autonomous vehicle can continue the safe navigation without waiting for the generation of a new route.

The following is an example table of timing options for generating alternative routes in advance, where the alternative routes are generated in anticipation of possible future demands. In the following table, the phrase "node" corresponds to a navigation event (e.g., turn, enter ramp, leave ramp, park, change ramp, and/or the like). The phrase "abnormal event" refers to an event that is needed or desired to deviate from the current route.

TABLE 1

Various tradeoffs may be considered in considering which of the aforementioned strategies is selected for generating the alternative route in advance. For example, the greater the number of generated alternative routes, the greater the likelihood that alternative routes are immediately available when needed, but the greater the load on the route generation processing system and the greater the memory utilization for storing such alternative routes. The technique may be selected based on the determined likelihood of an anomaly event occurring overall on the route, the determined likelihood of an anomaly event occurring on each node, and/or a weight assigned to a node or node type.

Referring to certain policies above, the data used to determine the likelihood (e.g., probability) of an abnormal event may include some or all of the following: the geographic area of navigation, time of day, expected congestion, historical anomalies of the corresponding node at time of day of initial routing, population density of the geographic area of navigation, presence and location of traffic control devices (e.g., street lights and parking signs), weather, vehicle memory capacity for storing routes, vehicle density of the geographic area of navigation, other reference data discussed herein, and/or the like.

For strategy 1, to minimize throughput and memory utilization, alternative routes may be generated only in response to detected abnormal events, rather than generated in advance. Examples of detected abnormal events may include a lane jam to be driven in according to a current route of the vehicle, a lane jam to be turned in accordance with a current route of the vehicle, an entrance ramp or exit ramp jam to be driven in accordance with a current route of the vehicle navigation, an on-edge parking directed by an emergency vehicle or operator (e.g., police, fire, ambulance, and the like), a parking lot closing where the vehicle is parked, and/or the like. For example, strategy 1 may be selected when the initial route is expected to have a relatively low probability of an abnormal event determined using the data described above, or when the vehicle does not have sufficient memory available to store a large number of alternative routes. A given alternative route may begin at a point or node corresponding to a detected abnormal event.

For policy 2, an alternative route may be pre-generated for each node of the initial route. If the probability that the route population does not exceed one anomaly is low, policy 2 will ensure that there is a high likelihood that alternative routes need not be generated on demand.

For policy 3, an alternative route for each node of the initial route may be generated in advance, and an alternative route for a node of the alternative route of n-layer depth may be generated in advance. Strategy 3 may be employed when there is a high probability of an abnormal event occurring (e.g., when there may occur a large road construction project along and around a route, when a natural disaster occurs in an area where the route is located, when a holiday or sporting event is held in the area where the route is located, etc.), or when an autonomous vehicle is performing a mission critical function (e.g., sending a wounded person to a hospital ambulance, a fire truck responding to a fire report, a police car responding to a crime or accident report, etc.).

For policy 4, it is determined whether an alternative route is to be generated on a node-to-node basis, and if the probability of an abnormal event for a given node of the initial route exceeds a specified threshold, the alternative route for the given node of the initial route may be pre-generated. Policy 4 balances ensuring that alternative routes are available in the event that an abnormal event has a probability of occurrence exceeding a threshold with the need to reduce the processing and/or memory utilization for generating and storing alternative routes.

For policy 5, if the probability of occurrence of an abnormal event at a given node exceeds a specified threshold, an alternative route for the given node of the initial route and an alternative route for the given node of the alternative route of n-layer depth may be generated in advance.

As described above, different nodes or node types may be associated with different weights. The weight may reflect the importance of having an immediately available alternative route for security. For example, if a node is the exit of a highway ramp where a vehicle may be traveling at high speed (e.g., 70 miles per hour), the vehicle may have little time to detect a blockage of the exit ramp and may have little time to calculate and execute a new route. Thus, there may be pre-calculated and immediately available alternative routes in this situation that are more important than if the vehicle is traveling in an area where the speed limit is 25 miles per hour. As a further example, if a street has 3 lanes in each direction and the vehicle is to change from a right lane to a left turn lane, the weight associated with such nodes may be higher than the nodes associated with roads that are single lanes in each direction in the case of a left turn of the vehicle. Thus, for example, different node weights may be associated with intersections of different sizes, streets of different widths, different expected speeds of vehicles, different expected congestion, nodes with different traffic control devices (e.g., traffic lights, stop lights, etc.), and so forth.

For policy 6, if the associated weight exceeds a specified threshold, an alternative route for a given node of the initial route may be generated in advance.

For policy 7, if the associated weight of a given node exceeds a specified threshold, an alternative route for the given node of the initial route and for the given node of the n-layer depth of the alternative route may be pre-generated.

For policy 8, it is determined whether an alternative route is to be pre-generated for a given node of the initial route based on a combination of the associated weights and the associated anomaly event probabilities.

For policy 9, it is determined whether an alternative route is to be pre-generated for a given node of n-layer depth of the initial route and the alternative route based on a combination of the associated weights and the associated probability of an abnormal event.

A given alternative route may be stored in a data store remote from the vehicle and may be downloaded to the vehicle upon conditional receipt of the alternative route by the vehicle (e.g., connected to a network and having memory available for storing the alternative route) in response to the vehicle detecting an abnormal event (an environmental condition that prevents the vehicle from continuing to travel along the route or that would make travel along the route unsafe) and/or based on other triggering conditions.

Thus, for example, the vehicle navigation system may detect an anomaly event or potential anomaly event at a given node while driving according to an initial route. For example, the threshold anomaly detection distance may be set prior to a given node, globally for all nodes, for all nodes of a certain type (e.g., turn, park, enter ramp, exit ramp), or at a location where the vehicle is expected to travel at a particular speed (where the threshold distance may be proportional to or otherwise correspond to the vehicle speed). Not later than a threshold distance from the neighboring node, the navigation system will determine from the sensor readings whether an abnormal event is present or likely to be present. If the navigation system determines that an abnormal event is or is likely to be present, the vehicle navigation system may determine whether an alternative route exists for use by the node by generating a search request that includes a unique node identifier. If an alternative route is available, the route may be accessed (e.g., accessed from a local memory or downloaded from a remote data store and stored in a local memory) and executed.

The alternative route may be generated using one or more routing strategies based on one or more criteria (e.g., speed, distance, road type, number of turns, and/or the like). For example, alternative routes may be generated to minimize time to the next waypoint (which may be the final destination), to minimize distance to the next waypoint, to minimize use of highways, to minimize use of toll roads, to minimize the number of turns required to reach the next waypoint, or some combination of the foregoing, to minimize the processing bandwidth required to calculate the alternative route, and/or the like, wherein different criteria may be given different weights when generating the alternative route.

Some alternative routes may take the form of emergency alternate route selection that directs the vehicle to rest in a nearby safe location (e.g., roadside, parking lot, etc.). Such emergency back-up routes may be used when a vehicle failure (e.g., a flat tire) is detected or in response to an on-edge parking command issued remotely to the vehicle (e.g., by a responder vehicle (e.g., police car, fire truck, ambulance, etc.) or other remote system).

In addition to pre-generating routes and on-demand routes in response to requests from a given vehicle, route updates may be generated based on changing conditions detected by a remote route planning system (e.g., navigation unit 140). For example, the route planning system may receive a report on unexpected congestion or accident from another vehicle or from a traffic reporting service. The route planning system may use the location information received from the vehicle to determine the current location of a given vehicle and use the current location of the vehicle to generate an updated route originating from the current location of the vehicle to avoid congestion or accidents. The route planning system may then transmit the updated route to the vehicle navigation system for execution.

Certain aspects will now be discussed with reference to fig. 2A-6.

FIG. 2A illustrates an example autonomous vehicle detecting an abnormal event proximate to a node. In this example, the node is a transition from a first lane to a right turn lane, and the abnormal event is that the right turn lane is blocked by other vehicles. Thus, the alternative route is accessed and used to navigate the vehicle (continue straight through the node).

Fig. 2B illustrates a schematic map of the execution of the original route and the alternative route of fig. 2A. As shown, before reaching node a (navigating to the right turn lane and then entering the right lane), an abnormal event is detected, thus an alternative route is accessed and used to navigate the vehicle. In this example, the alternative route returns the vehicle navigation back to the original route.

FIG. 3 illustrates an example process for determining when to generate an alternative route. For example, the process may be performed by a route planning system hosted on a cloud system (e.g., navigation unit 140) or a vehicle. At block 302, a route request is received. For example, requests are received from users over a wired or wireless network via an interface provided by the vehicle navigation system, via an application installed on a user device (e.g., mobile phone, smart television, set-top box, game console, etc.), or via a web page accessed through a browser.

At block 304, the process accesses the reference data for determining whether an alternative route is to be pre-calculated. The reference data may be accessed from the vehicle (e.g., available memory for storing routes, charge/fuel levels, etc.), local data storage, and/or one or more third party data sources. For example, data may be accessed from a third party source through a corresponding application data interface (API). Similar to the discussion above, the reference data may include map data.

The map data may include data that may be used to determine whether alternative routes for a given node should be generated in advance, as well as to generate routes (including alternative routes). Similarly to the discussion above, the map data may include a layout of streets and intersections, turning radii and/or left and right turn angles, distances and dimensions of road features (e.g., road length, road width, intersection dimensions, height and width of bridges on roads, vehicle entrances and exits (e.g., for parking structures), etc.), locations of parking signs and traffic lights, locations of isolation zones between bi-directional traffic, road type (expressway, accessory road, single-way road, bi-directional lane, etc.), and/or the like. As further examples, the map data may include road markings (e.g., centerline markings separating opposing traffic lanes, stop lines, left turn guide lines, right turn guide lines, crosswalks, bus lane markings, bicycle lane markings, safety island markings, pavement text, highway exit and entrance markings, etc.), allowable travel directions, curbs, curb heights, and/or other relevant information.

Optionally, the reference data may also include node weights, as well as information associated with corresponding geographic location data, real-time and/or historical traffic information, current and/or predicted weather conditions, road work information, information about laws and regulations (e.g., speed limits, whether red light right turns are allowed or prohibited, head drops are allowed or prohibited, etc.), related events (e.g., concerts, sporting events, holidays, etc.), and/or news events.

At block 306, some or all of the foregoing reference data is used to determine which of a plurality of pre-route generation policies to select, such as those discussed above with reference to table 1.

For example, if the probability of an anomaly event occurring on the route as a whole (rather than node-by-node) is to be used to determine the route policy, the following example formula may be used:

if sigma P<T ₁ According to the strategy S ₁ Generating alternative routes

Wherein:

p is the probability of an abnormal event at a given node,

T ₁ the value of =threshold 1,

S ₁ policy 1 in table 1.

If T ₁ ≤∑P<T ₂ Then select S ₂ ,

Wherein,

T ₂ the value of =threshold 2,

S ₂ policy 2 in table 1.

If T ₂ Sigma P or V is not more than _mc If true, select S ₃ ,

Wherein,

V _mc the vehicle performs mission critical functions (e.g., ambulances to send wounded to a hospital, fire trucks to respond to reported fires, police cars to respond to reported crimes or accidents, etc.),

S ₃ Policy 3 in table 1.

As a further example, if the route policy is determined on a node-by-node basis using the probability of occurrence of an abnormal event, the following example formula may be used:

if P _n <T ₃ According to the strategy S ₄ An alternative route is generated in advance for the nth node,

wherein,

P _n =probability of occurrence of an abnormal event at the nth node,

T ₃ the value of =threshold 3,

S ₃ policy 3 in table 1.

If T ₃ ≤P _n Or V _mc If true, according to strategy S ₅ Early generation for nth nodeIn the alternative route, the route is changed into a route,

wherein,

V _mc =the vehicle performs a mission critical function,

S ₅ policy 5 in table 1.

As a further example, if a route policy is determined on a node-by-node basis using the weights of a given node, the following example formula may be used:

if W is _n <WT ₁ According to the strategy S ₆ The alternative route is generated in advance and the route is selected,

wherein,

W _n =the weight of the nth node,

WT ₁ the number threshold value of 1 is given,

S ₆ policy 6 in table 1.

If WT ₁ ≤W _n Or V _mc If true, according to strategy S ₇ An alternative route is generated for a given node,

wherein,

V _mc =the vehicle performs a mission critical function,

S ₇ policy 7 in table 1.

As a further example, if a route policy is determined using node-by-node weights, the following example formula may be used:

If n ₁ P _n +n ₂ w _n <T _PW According to the strategy S ₈ An alternative route is generated in advance for the node,

wherein:

n ₁ the number of times the normalization factor 1,

P _n probability of abnormal event of n-th node,

n ₂ the number of times of the normalization factor 2,

w _n =the n-th node is given a weight,

if T _PW ≤n ₁ P _n +n ₂ w _n Or V _mc If true, according to strategy S ₉ Generating alternative routes for nodes in advance,

V _mc =the vehicle performs a mission critical function,

S ₉ policy 9 in table 1.

Other factors may be taken into account when selecting a policy. For example, if the amount of possible result data exceeds the amount available to store such result data, policies may be excluded.

At block 308, an alternate route is generated prior to the corresponding exception event according to the selected route advance generation policy. These given alternative routes may be packaged together with identification data so that they can be easily found and accessed in the event of a corresponding anomaly. For example, a given alternative route may optionally be stored in association with a unique alternative route identifier (which may be in the form of a link to the alternative route or may be in the form of an alphanumeric code), a unique identifier associated with the original route, a unique identifier associated with the vehicle, and/or a unique identifier associated with an initial node (e.g., initial node coordinates) of the alternative route.

At block 310, the process enables the vehicle control system to access the alternative route (e.g., via control system 126). For example, the alternative route may be stored in a local memory accessible to the vehicle control system. If the alternative route is generated by a system remote from the vehicle control system (e.g., via the cloud-based system described above), the remote system may download the alternative route wirelessly into the vehicle memory. Alternatively, the downloads of the alternative routes may be ordered in the chronological order of the corresponding nodes of the initial route to better ensure that the alternative routes have been downloaded before reaching the corresponding nodes. Alternatively, once the vehicle control system detects that a node has been successfully reached without an abnormal event, the vehicle control system may clear the memory of data for alternative routes associated with the successfully reached node, as such alternative route data will not be employed. This frees up memory for storing other data, such as backup route data for nodes that have not arrived.

FIG. 4 illustrates an example process for determining whether to generate an alternative route according to policy 8 in Table 1 above, where the process uses the associated weights and probabilities of unusual events to determine whether to generate an alternative route for a given node of an initial route.

At block 400, a node is selected from an initial route, where the route is intended for a certain time (e.g., immediately or at an intended time). At block 402, a likelihood (e.g., probability) of occurrence of an abnormal event for the selected node is determined, similar to as discussed above.

At block 404, it is determined what the weight associated with the node is. As described above, the weights may reflect the importance of having an alternative route available immediately. For example, each possible node in a given area may have been given a corresponding weight, regardless of the particular planned route. As a further example, the corresponding weights may optionally have been assigned for a given node type. By way of illustration, different weights may be given to lane changes, right turns without traffic control, right turns with parking lights, right turns with right turn lanes, left turns without traffic control, left turns with parking lights, left turns with left turn lanes, turn around, parking maneuver, right turn into lanes, left turn into lanes, up ramps, down ramps, and/or the like.

At block 406, it is determined whether an alternative route is to be generated in advance. As described above, the node weight and the probability of occurrence of an abnormal event at the node may be used to determine.

For example, the following evaluation may be performed:

if n ₁ P _n +n ₂ w _n >T _PW Generating the alternative route in advance, otherwise not generating the alternative route in advance,

wherein:

n ₁ the number of times the normalization factor 1,

P _n probability of abnormal event of n-th node,

n ₂ the number of times of the normalization factor 2,

w _n =weight given to nth node.

If it is determined at block 406 that no alternative route is generated, the process proceeds to the next node (if any) and the process is repeated. If it is determined at block 406 that an alternative route is to be generated, the process proceeds to block 408 and an alternative route is generated that begins at node n. Alternative routes may be provided to the vehicle control system, as similarly discussed above in connection with fig. 3. The process may then proceed to the next route node (if there is a next node) and the process is repeated. If there are no subsequent route nodes, the process may terminate.

A case of on-demand alternative route generation will now be described with reference to the process shown in fig. 5, in which an abnormal event is detected but an alternative route is not generated in advance. At block 502, a current speed of the autonomous vehicle is determined. For example, the speed may be obtained from the vehicle via a type II on-board diagnostic system (OBD II) or other protocol, via a satellite radio navigation system, or otherwise.

At block 504, a minimum safe distance from the neighboring node is determined that allows for a safe transition from the current route to an alternative route (which may require a turn or lane change) in the event of an abnormal event. The current speed of the vehicle may be used to determine, where the higher the speed, the greater the minimum safe distance. For example, a table or chart, such as the chart in FIG. 6, may be accessed that maps a given vehicle speed to a corresponding safe distance. The chart may be different for different vehicles. For example, for a given speed, the minimum safe distance for a small sports car with high performance braking and high stability may be shorter than for a large truck with poor braking performance and relatively poor stability.

At block 506, it is determined whether the vehicle has reached a minimum safe distance from an adjacent node. If the vehicle has reached a minimum safe distance from the neighboring node, at block 508, the process determines the likelihood (e.g., probability) that an abnormal event exists and whether the determined likelihood (e.g., probability) exceeds a corresponding threshold. Data from one or more local vehicle sensors and/or data from sensors whose information can be accessed wirelessly by the vehicle via a wireless network (e.g., sensors of roads or other vehicles in the area of the nearby node) may be used to determine. For example, a vehicle light detection and ranging (LiDAR) sensor, radar, camera, inter-vehicle communication system, road sensor communication system, or the like may be used to determine that a node is blocked. The likelihood threshold may be a globally used threshold (for all route nodes), a threshold for a node, or a threshold for a node type. The vehicle may also determine that it cannot determine whether an abnormal event or the likelihood of an abnormal event exists.

If the likelihood does not exceed the corresponding threshold, at block 514, the vehicle continues to navigate using the current route.

If the likelihood exceeds the corresponding threshold, at block 510, the vehicle may determine whether there are already alternative routes available and if not, the vehicle generates an alternative route request. The request may be provided to a vehicle-based routing system locally or may be transmitted wirelessly to a remote routing system. At block 512, the alternative route is received and used to navigate the vehicle.

Automatic driving vehicle telemetering

As described above, to improve safe and efficient operation of autonomous vehicles, it is useful to be able to collect and analyze telemetry data while a large number of autonomous vehicles are in operation. Such data may be used for diagnostic purposes, such as identifying and correcting errors or faults. In addition, such data may be used to improve the route of an autonomous vehicle using an improved simulation of the environment in which the navigation vehicle is located. Further, such data may be used to simulate vehicle performance. While it may be desirable in some situations for the vehicle to continuously transmit telemetry data, in many cases such continuous transmission may place undue burden on the wireless network as well as on the network, processing and memory resources of the remote telemetry analysis system. It would therefore be advantageous to be able to selectively control the transmission of telemetry data recorded by a vehicle control system to ensure that certain desired telemetry data is transmitted in time for analysis and use, while other telemetry data is transmitted less frequently or not at all.

The recorded telemetry data may include time stamped location information (e.g., location latitude and longitude coordinates or other location data as determined by a satellite radio navigation system, wi-Fi, or cellular triangulation system, or other means of the vehicle), vehicle pose (location and orientation) information, speed information, acceleration information, deceleration information, turn information, detected object information (e.g., information from light detection and ranging (LiDAR) sensors, radar, cameras, inter-vehicle communication systems, road sensor communication systems, etc.), road marking information (e.g., crosswalk, lane separation, safety island markings, etc.), text data (e.g., read from street signs, road surfaces, store signs, etc.), route data, perception data, anomaly data, weather data, road condition data, road feature storage data, and/or other information. The detected object information may include detection and identification of objects such as other vehicles, construction equipment, bolsters, road blocks, buildings, and the like.

Referring to FIG. 1C, an example processing system 100C is disclosed. The processing system may be included in the server 130 shown in fig. 1A or may be a separate system. The example processing system includes a telemetry data acquisition module 102C, a validation module 104C, a diagnostic module 106C, and a training module 108C.

The telemetry data acquisition module 102C may receive, store, pre-process, and/or identify telemetry data of interest, such as the data described above, from the vehicle (e.g., from the vehicle control system 126 via the communication system 124 of the vehicle 120). For example, telemetry data acquisition module 102C may store the received telemetry data in a telemetry database and may normalize the telemetry data prior to using the telemetry for verification or training. For example, the process may normalize road lengths ranging from 0 to 3500 miles to obtain normalized road lengths ranging from 0 to 1. Telemetry data acquisition module 102C may also identify telemetry data of interest and inhibit processing of other telemetry data to reduce computer resource utilization and enhance the speed of processing and analysis.

Telemetry data from the telemetry data acquisition module 102C may be provided to the training module 108C for training, in conjunction with other data, a route recommendation model used by the navigation unit 140. The route may be generated from the route request (e.g., by the navigation unit 140) using a route recommendation model. The route may include location data, turn-by-turn instruction data, acceleration instruction data, stop instruction data, deceleration instruction data, predicted times of arrival of the vehicle at various points on the route (e.g., each node, periodically based on time or distance, final destination, each waypoint, or the like), and so forth.

In addition to telemetry data from the vehicle, data from other sources, such as map data, current and/or historical traffic data, current and/or historical weather data, current and/or historical traffic data, and/or other reference data discussed herein may be used by the training module 108D to train the route recommendation model.

Training of the route recommendation model may be performed using an iterative training process, wherein the training process is terminated after a certain number of iterations or when certain criteria are met. During the training process, one or more route recommendation model parameters may be updated to optimize the model.

Telemetry data may also be used by verification module 104C to verify the accuracy of predictions generated based on the route recommendation model. For example, the verification module 104C may verify the accuracy of the generated route by comparing the actual route navigated by the vehicle with the initial route generated using the route recommendation model. In addition, the verification module 104C may compare the predicted arrival times at various points along the route with the actual arrival times for those same points as determined from the telemetry data. Alternatively, if the accuracy is less than the first threshold, a route recommendation model may be specified for subsequent training. The reference data (including map data) may also be verified using the verification module 104C.

The diagnostic module 106C may use the telemetry data for diagnostic purposes, such as detecting errors or defects in vehicle sensors or navigation systems. For example, if the vehicle telemetry data indicates that the vehicle sensor did not detect the first object (e.g., a road sign or traffic light) at a location where the map indicated the presence of the first object, it may be determined that the vehicle was experiencing (e.g., in sensor or sensor signal processing) a fault or that there may be a map error (e.g., the first object may never have been present or the first object may have been removed), as discussed elsewhere herein.

The diagnostic module 106C may utilize data from other sources (e.g., sensor data from other vehicles) to determine whether the vehicle is faulty or whether the map is in error. For example, if one or more other vehicles fail to detect the first object, it may be determined that the vehicle sensors are functioning properly, but the map is erroneous. If it is determined that the map is wrong, the map may be updated. If, however, one or more other vehicles detect the first object, it may be determined that a vehicle that fails to detect the object is in error and it may be determined that the vehicle requires repair and repair or that a software update needs to be downloaded to correct the error.

Referring now to fig. 7, an example process for transmitting and using autonomous vehicle position and sensor data will be described.

At block 702, a telemetry analysis system receives route data for a planned vehicle route. The route data may include a route start location, a final destination, waypoints, and each navigation maneuver. The telemetry analysis system may be a cloud-based system. At block 704, a telemetry transmission policy is determined, including one or more broadcast parameters for controlling telemetry data broadcasting. A variety of factors may be taken into account in determining the telemetry transmission strategy, including some or all of the following:

the length of the route is set to be,

the length of time that the road segment has available navigation data,

the length of time that navigation data is available for the road segment under the current weather conditions,

the construction planned along the road is carried out,

availability of communication bandwidth for transmitting telemetry data, and/or

Availability of storage for transmitting telemetry data.

For example, a route may be divided into a plurality of segments. The segments may be defined such that some or all of the segments have the same length. Alternatively, the route may be divided into a plurality of segments such that each segment is grouped by node. Other policies may be used to define the plurality of segments. If one or more road segments have little more updated data, it may be desirable to obtain more up-to-date data for future route planning purposes to ensure that the route planning uses map data that accurately reflects actual road conditions. Similarly, if one or more route segments have little up-to-date data in the current weather conditions, it may be desirable to obtain more up-to-date data regarding the traffic patterns along the route in that weather. As a further example, if construction is performed along a route, it may be necessary to obtain data regarding whether the construction resulted in a node blockage or a change in traffic pattern. As a further example, if the availability of wireless network bandwidth is only intermittent, telemetry transmissions may need to be limited.

Additionally or alternatively, the telemetry policy may include transmitting telemetry data associated with each navigation node and/or each anomaly event by the vehicle.

Thus, for example, the telemetry transmission schedule for the recorded data may be continuous, periodic (e.g., every 5 seconds, every 30 seconds, every minute, every 5 minutes, every 15 minutes, or other time frame), or completed in batch mode after the vehicle reaches its final destination. As a further example, a telemetry transmission schedule may specify continuous transmissions for certain segments (e.g., where there is a lack of up-to-date data or where there is dynamic changes in road construction), and periodic transmissions or no transmissions for other route segments. As a further example, a first telemetry transmission schedule may be specified for certain types of telemetry data (e.g., continuous for vehicle location information or diversion from an original route), a second telemetry transmission schedule may be specified for certain other types of telemetry data (e.g., object detection), and a third telemetry transmission schedule may be specified for yet other types of telemetry data (e.g., pavement text, pavement markings, street sign text, etc.). Alternatively, the telemetry transmission schedule may specify that transmission of telemetry data is to be suspended if the vehicle is parked and/or stationary for more than a threshold period of time. Advantageously, the foregoing techniques reduce the likelihood of being overwritten in memory before desired telemetry data is broadcast.

At block 706, the transmission schedule is transmitted and loaded into a vehicle telemetry system. At block 708, the vehicle telemetry system wirelessly transmits telemetry data according to a corresponding telemetry schedule, and the telemetry analysis system receives and stores the data. A given telemetry transmission may include data that enables a telemetry analysis system to quickly identify data of interest. The telemetry analysis system may optionally not analyze certain telemetry data that is not of interest and may optionally clear such data from memory, freeing such memory to store other data.

For example, a given telemetry transmission may include a header indicating what data is to be included in the transmission, the amount of data, and/or the number of data packets in the transmission. Further, the telemetry transmission may include one or more time stamps. For example, there may be a timestamp on when the transmission occurred and/or when a given data item was captured. Optionally, a given telemetry data item is transmitted in association with vehicle pose (position and orientation) data to assist the telemetry analysis system in synchronizing telemetry with a particular location.

At block 710, the telemetry analysis system identifies particular telemetry data of interest. For example, telemetry data of interest may be identified by vehicle location data, vehicle orientation data, time stamp data, and/or the like.

At block 712, telemetry data of interest may be used to verify routes, to verify maps for generating maps, and/or for vehicle diagnostics (e.g., to detect errors with respect to vehicle operation and/or sensors). For example, if a vehicle sensor detects a traffic signal, traffic sign, or road obstacle that is not present on the map at the corresponding location, the map may be updated with the detected item, which may be verified by a service person prior to updating the map or verified using telemetry data from other vehicles, or other actions may be taken.

At block 713, telemetry data of interest may be used for vehicle diagnostics (e.g., to detect errors with respect to vehicle operation and/or sensors). For example, if telemetry indicates that the vehicle fails to detect an item present (e.g., an object on a road or a curve) or incorrectly identifies an item (e.g., identifies a park flag as a park inhibit flag), this may indicate an error in a vehicle sensor or related processing software or related hardware (e.g., processing component, power supply, analog-to-digital converter, communication interface, etc.). Such information may be recorded and the vehicle may be required for repair, new software may be downloaded to the vehicle to correct errors, and/or detected errors may be used to improve future versions of the vehicle to avoid such errors. If similar faults are specific to occurrence in sensors of other vehicles, it may be determined that there are extensive manufacturing or design defects, and recall may be performed on vehicles having sensors corresponding to the sensors for which faults have been determined.

At block 714, the route planning system may be trained using telemetry data. For example, the route planning system may include a learning engine. Telemetry data may be used to create a simulation of the navigational environment and to generate test cases. For example, an object detected by the vehicle may be added to the simulated route. Furthermore, telemetry data may be used to simulate vehicle performance. For example, if it is determined from telemetry that a vehicle light detection and ranging (LiDAR) cannot detect an object under certain fog conditions, future simulations of the vehicle may likewise reflect that the vehicle light detection and ranging (LiDAR) cannot detect an object under such fog conditions.

The process may optionally perform preprocessing operations (e.g., normalization and/or elimination of error points) on the telemetry data before using the telemetry data for verification or training. For example, the process may normalize a road length ranging from 0 to 3000 miles to obtain a normalized road length ranging from 0 to 1.

Furthermore, in the event that the route planning system determines that the vehicle should re-route based on data received from another source and indicative of unexpected congestion or accident on the current route, the telemetry data may be used to generate updated routes in real-time. The route planning system may determine the current location of a given vehicle using location information included in the telemetry data and generate an updated route based on the current location of the vehicle to avoid congestion or accidents. The route planning system may then transmit the updated route to the vehicle control system for execution.

Example embodiment

Some example enumerated embodiments of the present invention are recited in this paragraph in methods, systems, and non-transitory computer readable media and are not limiting.

One aspect of the present disclosure relates to a computer-implemented method of generating a route for an autonomous vehicle, the method comprising: at a first route planning system, receiving a request for a first navigation route of a remotely autonomous vehicle, the request including a start location and a destination location and being associated with a navigation start time; generating, by the first route planning system, a first navigation route based at least in part on the starting location, the destination location, and the starting time, the first navigation route comprising a plurality of nodes, wherein a given node corresponds to a navigation event; for a given node in the first navigation route, identifying, by the first route planning system, a corresponding weight, and/or for the given node in the first navigation route, determining, by the first route planning system, a probability of an abnormal event occurring at the given node; determining, by a first routing system, whether to generate a corresponding alternative route that excludes the given node using a weight corresponding to the given node and/or a probability determined that an abnormal event occurred at the given node, the corresponding alternative route configured to be employed in response to the autonomous vehicle detecting an abnormal event associated with the given node in the future, wherein the abnormal event prohibits the autonomous vehicle from navigating to the given node; generating, by the first routing system, the alternative route in response to determining to generate the corresponding alternative route; and transmitting the first navigation route and the corresponding backup route to the autonomous vehicle and enabling the autonomous vehicle to navigate the autonomous vehicle using the first navigation route and the corresponding backup route to be used to navigate the autonomous vehicle in the event of detection of an abnormal event associated with the given node.

One aspect of the present disclosure relates to a navigation route planning system, comprising: a computing device; a network interface; a non-transitory computer readable memory having program instructions stored thereon that, when executed by the computing device, cause the computing device to: using the network interface, receiving a request for a first navigation route of a remote vehicle, the request including a start location and a destination location and being associated with a navigation start time; generating a first navigation route using the starting location, the destination location, and the starting time, the first navigation route including one or more nodes, wherein a given node corresponds to a navigation event; for a given node in the first navigation route, identifying a corresponding weight, and/or for a given node in the first navigation route, determining a likelihood or probability of an abnormal event occurring at the given node; determining whether to generate a corresponding alternative route that excludes the given node using a weight corresponding to the given node and/or a likelihood or probability determined that an abnormal event occurred at the given node, the corresponding alternative route configured to be employed in response to the vehicle detecting an abnormal event associated with the given node in the future, wherein the abnormal event inhibits the vehicle from navigating to the given node; generating the alternative route in response to determining to generate the corresponding alternative route; and transmitting the first navigation route and the corresponding alternate route to the vehicle and enabling the vehicle to navigate the vehicle using the first navigation route and the corresponding alternate route to be used to navigate the vehicle upon detection of an abnormal event associated with the given node.

One aspect of the disclosure relates to a non-transitory computer readable memory having program instructions stored thereon that, when executed by the computer system device, cause the computer system to perform operations comprising: receiving a request for a first navigation route of a remote vehicle, the request including a start location and a destination location and being associated with a navigation start time; generating a first navigation route using the starting location, the destination location, and the starting time, the first navigation route including one or more nodes, wherein a given node corresponds to a navigation event; for a given node in the first navigation route, identifying a corresponding weight, and/or for a given node in the first navigation route, determining a likelihood or probability of an abnormal event occurring at the given node; determining whether to generate a corresponding alternative route using the weight corresponding to the given node and/or the likelihood or probability determined that an abnormal event occurred at the given node, the corresponding alternative route configured to be employed in response to the vehicle detecting an abnormal event associated with the given node in the future; generating the alternative route in response to determining to generate the corresponding alternative route; and causing the first navigation route and the corresponding alternate route to be transmitted to the vehicle, wherein the vehicle is to use the first navigation route to navigate the vehicle at least initially, and wherein the vehicle is to use the corresponding alternate route to navigate the vehicle when an abnormal event associated with the given node is detected.

One aspect of the present disclosure relates to a computer-implemented method of controlling broadcasting telemetry data from an autonomous vehicle, the method being performed by a system comprising one or more processing devices, the method comprising: accessing route data for a first route generated by a route planning system of an autonomous vehicle, the route data configured to control navigation of the autonomous vehicle; generating, using route data of the first route, one or more telemetry broadcast controls for use by the autonomous vehicle in broadcasting telemetry data including at least vehicle location data while navigating the autonomous vehicle using the route data, wherein the telemetry broadcast controls are configured to cause the autonomous vehicle to broadcast telemetry data for a plurality of selected segments of the first route and to inhibit broadcasting telemetry data for a plurality of non-selected segments of the first route; transmitting the telemetry broadcast control to the autonomous vehicle; receiving a transmission of telemetry data for the selected segment of the first route from the autonomous vehicle; using at least the received telemetry data in generating a simulated environment for the route planning learning engine; and performing diagnostics and/or verification of map data for generating the first route on the autonomous vehicle using at least a portion of the received telemetry data.

One aspect of the present disclosure relates to a system, comprising: a computing device; a network interface; a non-transitory computer readable memory having program instructions stored thereon that, when executed by the computing device, cause the computing device to: accessing route data for a first route of a vehicle, the route data configured to navigate the vehicle; generating telemetry broadcast parameters for use by the vehicle in broadcasting telemetry data, the telemetry data including at least vehicle location data while navigating the vehicle using the routing data, wherein the telemetry broadcast parameters are configured to cause the vehicle to broadcast telemetry data for the first route portion in accordance with the broadcast parameters; transmitting the telemetry broadcast parameters to the vehicle via the network interface; receiving a transmission of telemetry data for the selected section of the first route from the vehicle; and using at least the received telemetry data in generating a simulated environment for the route planning learning engine.

One aspect of the disclosure relates to a non-transitory computer readable memory having program instructions stored thereon that, when executed by the computer system device, cause the computer system to perform operations comprising: accessing route data for a first route of a vehicle, the route data configured to navigate the vehicle; generating telemetry broadcast parameters for use by the vehicle in broadcasting telemetry data, the telemetry data including at least vehicle location data while navigating the vehicle using the route data, wherein the telemetry broadcast parameters are configured to cause the vehicle to broadcast telemetry data of the first route portion in accordance with the broadcast parameters; transmitting the telemetry broadcast parameters to the vehicle via the network interface; receiving a transmission of telemetry data for the selected section of the first route from the vehicle; and using at least the received telemetry data in generating a simulated environment for the route planning learning engine.

In other embodiments, one or more systems may operate in accordance with one or more of the methods and/or computer-readable media recited in the preceding paragraphs. In still other embodiments, one or more methods may operate in accordance with one or more of the systems and/or computer-readable media recited in the preceding paragraphs. In still other embodiments, one or more computer-readable media, excluding transitory propagating signals, may cause one or more computing devices having one or more processors and non-transitory computer-readable memory to operate according to one or more of the systems and/or methods recited in the preceding paragraphs.

Accordingly, the present disclosure discloses systems and methods for dynamically adjusting routes to accommodate dynamically changing environments, thereby ensuring safe and efficient operation of an autonomous vehicle.

Further, the present disclosure discloses systems and methods for detecting vehicle component and software faults and errors using autopilot vehicle telemetry data.

Further, the present disclosure discloses systems and methods for utilizing autopilot vehicle telemetry to simulate vehicle performance and simulate a vehicle navigation environment to improve route planning.

Although the present disclosure is generally described herein in connection with an autonomous vehicle, this is for illustration purposes only and not limitation. Any of the techniques or operations described herein may be applied to vehicles that provide driver assistance features and/or are used to share travel or other location-based services.

Terminology

Conditional language such as "capable," "possible," "may," or "may," unless specifically stated otherwise or otherwise understood in the context of use, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps must be in any way for one or more embodiments or that one or more embodiments necessarily include logic for determining: whether such features, elements, and/or steps are included in or are to be performed in any particular embodiment with or without user input or prompting.

In the description and in the claims, the words "comprise", "comprising", and the like are to be construed in an inclusive sense, rather than an exclusive or exhaustive sense, i.e. "including but not limited to", unless the context clearly requires otherwise. As used herein, the term "connected," "coupled," or any variant thereof refers to any direct or indirect connection or coupling between two or more elements; the coupling or connection between the elements may be physical, logical, or a combination thereof. Furthermore, the words "herein," "above," "below," and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Words using the singular or plural number may also include the plural or singular number, respectively, where the context permits. When combining a list of two or more items, the word "or" encompasses all of the following interpretations of the word: any one item in the list, all items in the list, and any combination of items in the list. Also, when combining a list of two or more items, the term "and/or" encompasses all of the following interpretations of the word: any one item in the list, all items in the list, and any combination of items in the list.

In some embodiments, certain operations, acts, events, or functions of any of the algorithms described herein can be performed in a different order, may be added, combined, or eliminated entirely (e.g., not all are essential to the implementation of the algorithm). In some embodiments, the operations, acts, functions or events may be performed concurrently, e.g., by multi-threaded processing, interrupt processing, or multiple processors or processor cores, or on other parallel architectures, rather than sequentially.

The systems and modules described herein may include software, firmware, hardware, or any combination of software, firmware, or hardware suitable for the purposes described. The software and other modules may reside on and execute on servers, workstations, personal computers, computerized tablets, PDAs, and other computing devices suitable for the purposes described herein. The software and other modules may be accessed through a local computer memory, network, browser, or other means suitable for the purposes described herein. The data structures described herein may include computer files, variables, programming arrays, programming structures, or any electronic information storage schemes or methods suitable for the purposes described herein, or any combination thereof. The user interface elements described herein may include elements from a graphical user interface, an interactive voice response, a command line interface, and other suitable interfaces.

Furthermore, the processing of the various components of the illustrated system may be distributed across multiple machines, networks, and other computing resources. Two or more components of a system may be combined into fewer components. The various components of the illustrated system may be implemented in one or more virtual machines rather than in a dedicated computer hardware system and/or computing device. Likewise, the data store shown may represent physical and/or logical data storage, including, for example, a storage area network or other distributed storage system. Furthermore, in some embodiments, the connections between the illustrated components represent possible paths of data flow, rather than actual connections between the hardware. Although some examples of possible connections are shown, in various implementations, any subset of the components shown are capable of communicating with one another.

Embodiments are also described above in connection with flowcharts for methods, apparatus (systems) and computer program products. Each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. Such instructions may be provided to a processor of a general purpose computer, special purpose computer (e.g., including a high performance database server, a graphics subsystem, etc.), or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the actions specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a non-transitory computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be loaded onto a computing device or other programmable data processing apparatus to cause a computer implemented process to be performed on the computing device or other programmable apparatus such that the instructions which execute on the computing device or other programmable apparatus provide steps for implementing the actions specified in the flowchart and/or block diagram block or blocks.

While the phrase "single click" may be used in connection with user selection of a control, menu selection, etc., other user inputs may be used, such as voice commands, text input, gestures, etc. For example, user input may be provided, for example, through an interface, such as via a text field, where the user enters text and/or selects via a menu (e.g., a drop down menu, list, or other arrangement or set of individually selectable icons that the user may sort or otherwise select through a checkbox, etc.). When a user provides input or activates a control, the corresponding computing system may perform the corresponding operation. Some or all of the user-provided data, inputs, and instructions may optionally be stored in a system data store (e.g., database) from which the system can access and retrieve such data, inputs, and instructions. The notifications and user interfaces described herein can be provided through web pages, dedicated or non-dedicated mobile applications, computer application persistence, short message service messages (e.g., SMS, MMS, etc.), instant messages, emails, push notifications, audible, and/or other means.

The user terminals described herein may be in the form of mobile communication devices (e.g., cellular telephones), notebook computers, tablet computers, interactive televisions, gaming devices, streaming media devices, head mounted displays, network watches, and the like. The terminal may optionally include a display, a user input device (e.g., touch screen, keyboard, mouse, voice recognition, etc.), a network interface, and the like.

Any of the patents and applications mentioned above, and other references, including any that may be listed in the attached filing documents, are incorporated herein by reference. Aspects of the invention can be modified, if necessary, to employ the systems, functions, and concepts of the various references described above to provide yet another embodiment of the invention. These and other changes can be made to the invention in light of the above detailed description. While certain examples of the invention have been described above, and while the best mode contemplated, the invention may be practiced in many ways, regardless of the details presented in the text. The details of the system vary significantly in its specific embodiments while still being encompassed by the invention disclosed herein. As noted above, certain terms used in describing certain features of various aspects of the present invention should not be construed to imply that these terms are not limited herein to any specific features, characteristics, or aspects of the present invention with which these terms are associated. In general, terms used in the following claims should not be construed to limit the invention to the specific examples disclosed in the specification unless such terms are explicitly defined in the above detailed description. Therefore, the actual scope of the invention encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the invention under the claims.

In order to reduce the number of claims, certain aspects of the invention are presented below in certain claim forms, but applicant may contemplate other aspects of the invention in any number of claim forms. For example, although only one aspect of the invention is recited as a means-plus-function claim in accordance with 35U.S. c sec.112 (f) (AIA), other aspects may likewise be implemented as a means-plus-function claim or in other forms, such as in a computer-readable medium. Any claim intended to be processed in accordance with 35u.s.c. ≡112 (f) will start with the statement "means for … …", but the use of "for" in any other context does not mean an cited process in accordance with 35u.s.c. ≡112 (f). Accordingly, the applicant reserves the right to append additional claims to the present application or to a subsequent application after filing the application.

Claims

1. A computer-implemented method of controlling the broadcast of telemetry data from an autonomous vehicle, the method being performed by a system comprising one or more processing devices, the method comprising:

accessing route data for a first route generated by a route planning system of an autonomous vehicle, the route data configured to control navigation of the autonomous vehicle;

Using the route data of the first route while navigating the autonomous vehicle using the route data, generating one or more telemetry broadcast controls for use by the autonomous vehicle in broadcasting telemetry data, the broadcasting telemetry data including at least vehicle location data,

wherein the first route is divided into a plurality of segments, the telemetry broadcast control is configured to cause the autonomous vehicle to broadcast telemetry data for selected segments of the first route and inhibit broadcasting telemetry data for non-selected segments of the first route;

transmitting the telemetry broadcast control to the autonomous vehicle;

receiving a transmission of telemetry data of the selected road segment of the first route from the autonomous vehicle;

using at least the received telemetry data for generating a simulated environment for the route planning learning engine; and

performing diagnostics and/or verification of map data for generating the first route on the autonomous vehicle using at least a portion of the received telemetry data.

2. The computer-implemented method of claim 1, further comprising simulating a vehicle using at least a portion of the received telemetry data.

3. The computer-implemented method of claim 1, wherein the telemetry broadcast control is configured to cause the autonomous vehicle to transmit telemetry data throughout a node.

4. The computer-implemented method of claim 1, wherein the telemetry broadcast control is configured to cause the autonomous vehicle to transmit telemetry data at specified travel distance intervals.

5. The computer-implemented method of claim 1, wherein the telemetry broadcast control is configured to cause the autonomous vehicle to transmit telemetry data at specified intervals.

6. The computer-implemented method of claim 1, wherein the first road segment of the first route for which telemetry data is to be broadcast is selected based on how old map data stored in a first data store is to the first road segment, the first road segment being one of the selected road segments.

7. The computer-implemented method of claim 1, wherein the first road segment of the first route for which telemetry data is to be broadcast is selected based on a determination that there is road construction in the first road segment, the first road segment being one of the selected road segments.

8. The computer-implemented method of claim 1, wherein performing diagnostics on the autonomous vehicle using at least a portion of the received telemetry data further comprises:

determining that a first object is present at a first location on a digital map of a first road segment of the first route, the first road segment being one of the selected road segments;

determining whether the received telemetry data includes sensor data indicating the presence of the first object at the first location; and

responsive at least in part to determining that the sensor data does not indicate the presence of the first object at the first location, initiating a remedial action with respect to the autonomous vehicle.

9. The computer-implemented method of claim 1, wherein performing diagnostics on the autonomous vehicle using at least a portion of the received telemetry data further comprises:

Responsive at least in part to determining that the sensor data does not indicate the presence of the first object at the first location, accessing telemetry data of other vehicles that have traversed a route that includes a view of the first location to determine whether the telemetry data of the other vehicles includes sensor data that indicates the presence of the first object at the first location; and

in response, at least in part, to determining that telemetry data of the other vehicle does not include sensor data indicating the presence of the first object at the first location, the digital map is updated to indicate the absence of the first object at the first location.

10. A system for controlling the broadcasting of telemetry data from an autonomous vehicle, the system comprising:

a computing device;

a network interface;

a non-transitory computer readable memory having program instructions stored thereon that, when executed by the computing device, cause the computing device to:

accessing route data for a first route of a vehicle, the route data configured for navigating the vehicle;

generating telemetry broadcast parameters for use by the vehicle in broadcasting telemetry data, the telemetry data including at least vehicle location data while navigating the vehicle using the route data, wherein the first route is divided into a plurality of portions, the telemetry broadcast parameters configured to cause the vehicle to broadcast telemetry data for selected portions of the first route in accordance with the telemetry broadcast parameters;

Transmitting the telemetry broadcast parameters to the vehicle via the network interface;

receiving a transmission of telemetry data of the selected portion of the first route from the vehicle; and

at least the received telemetry data is used to generate a simulated environment for the route planning learning engine.

11. The system of claim 10, wherein the system is configured to simulate a vehicle using at least a portion of the received telemetry data.

12. The system of claim 10, wherein the system is configured to perform diagnostics and/or verification of map data for generating the first route on the vehicle using at least a portion of the received telemetry data.

13. The system of claim 10, wherein the telemetry broadcast parameters are configured to cause the vehicle to transmit telemetry data throughout a node.

14. The system of claim 10, wherein the telemetry broadcast parameters are configured to cause the vehicle to transmit telemetry data at specified travel distance intervals.

15. The system of claim 10, wherein the telemetry broadcast parameters are configured to cause the vehicle to transmit telemetry data at specified intervals.

16. The system of claim 10, wherein the first portion of the first route for which telemetry data is to be broadcast is selected based on how old map data stored in a first data store is to the first portion, the first portion being one of the selected portions.

17. The system of claim 10, wherein the first portion of the first route for which telemetry data is to be broadcast is selected based on determining that there is road construction in the first portion, the first portion being one of the selected portions.

18. The system of claim 10, wherein the system is configured to use at least a portion of the received telemetry data to:

determining that a first object is present at a first location on a digital map of a first portion of the first route, the first portion being one of the selected portions;

responsive at least in part to determining that the sensor data does not indicate the presence of the first object at the first location, a remedial action is initiated with respect to the vehicle.

19. The system of claim 10, wherein the system is configured to use at least a portion of the received telemetry data to:

20. A non-transitory computer readable memory having program instructions stored thereon, which when executed by a computer system, cause the computer system to perform operations comprising:

generating telemetry broadcast parameters for use by the vehicle in broadcasting telemetry data, the telemetry data including at least vehicle location data while navigating the vehicle using the route data, wherein the first route is divided into a plurality of portions, the telemetry broadcast parameters being configured to cause the vehicle to broadcast telemetry data for selected portions of the first route in accordance with the telemetry broadcast parameters;

transmitting the telemetry broadcast parameters to the vehicle via a network interface;

21. The non-transitory computer readable memory of claim 20, wherein the program instructions, when executed by a computer system device, are further configured to simulate a vehicle using the received telemetry data.

22. The non-transitory computer readable memory of claim 20, wherein the program instructions, when executed by a computer system device, are further configured to cause the computer system to perform diagnostics and/or validation of map data for generating the first route on the vehicle using at least a portion of the received telemetry data.

23. The non-transitory computer readable memory of claim 20, wherein the telemetry broadcast parameters are configured to cause the vehicle to transmit telemetry data at a node traversal.

24. The non-transitory computer readable memory of claim 20, wherein the telemetry broadcast parameters are configured to cause the vehicle to transmit telemetry data at specified travel distance intervals.

25. The non-transitory computer readable memory of claim 20, wherein the telemetry broadcast parameters are configured to cause the vehicle to transmit telemetry data at specified intervals.

26. The non-transitory computer readable memory of claim 20, wherein the first portion of the first route for which telemetry data is to be broadcast is selected based on how old map data stored in a first data store is to the first portion, the first portion being one of the selected portions.

27. The non-transitory computer-readable memory of claim 20, wherein the first portion of the first route for which telemetry data is to be broadcast is selected based on determining that there is road construction in the first portion, the first portion being one of the selected portions.

28. The non-transitory computer readable memory of claim 20, wherein the program instructions, when executed by a computer system device, are further configured to cause the computer system to use at least a portion of the received telemetry data to:

29. The non-transitory computer readable memory of claim 20, wherein the program instructions, when executed by a computer system device, are further configured to cause the computer system to use at least a portion of the received telemetry data to: