Integrated module for sensor data aggregation and control of sensor support hardware

Systems, methods, and computer-readable media are provided for receiving first data from a first sensor utilizing a first communication protocol, wherein the first sensor is positioned in an aggregation zone, receiving second data from a second sensor utilizing a second communication protocol, wherein the second sensor is positioned in the aggregation zone, processing the first data received from the first sensor and the second data received from the second sensor to conform the first communication protocol and the second communication protocol, and providing instructions based on the processed first data and the processed second data in a third communication protocol, wherein the instructions adjust auxiliary functions of an autonomous vehicle.

BACKGROUND

1. Technical Field

The subject technology provides solutions for autonomous vehicles, and in particular, for managing a plurality of sensors to enable modular and upgradeable sensing for autonomous vehicles.

Autonomous vehicles are vehicles having computers and control systems that perform driving and navigation tasks conventionally performed by a human driver. As autonomous vehicle technologies continue to advance, ride-hailing services will increasingly utilize autonomous vehicles to improve service safety and efficiency. For effective use in ride-hailing deployments, autonomous vehicles will be required to execute many service functions that are conventionally performed by human drivers.

Currently, autonomous vehicles include a main vehicle computer that is individually connected to all of the sensors that are positioned throughout the autonomous vehicle. This type of sensor connectivity arrangement requires many connection ports, wiring harnesses, a large enclosure, and unique firmware as each sensor includes its own respective firmware that is independently developed by the manufacturer. For example, the sensors are built by automotive Tier 1 manufacturers that have no cross-functional knowledge of sensors from other manufacturers. Packaging several enclosures into a small space, writing unique driver code for each sensor, sourcing several different automotive grade connectors, and managing several Tier 1 suppliers is extremely challenging, expensive, and time-consuming.

DETAILED DESCRIPTION

Various examples of the present technology are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the present technology. In some instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more aspects. Further, it is to be understood that functionality that is described as being carried out by certain system components may be performed by more or fewer components than shown.

FIG.1illustrates an example autonomous vehicle environment100. The example autonomous vehicle environment100includes an autonomous vehicle102, a remote computing system150, and a ridesharing application170. The autonomous vehicle102, remote computing system150, and ridesharing application170can communicate with each other over one or more networks, such as a public network (e.g., a public cloud, the Internet, etc.), a private network (e.g., a local area network, a private cloud, a virtual private network, etc.), and/or a hybrid network (e.g., a multi-cloud or hybrid cloud network, etc.).

The autonomous vehicle102can navigate about roadways without a human driver based on sensor signals generated by sensors104-108on the autonomous vehicle102. The sensors104-108on the autonomous vehicle102can include one or more types of sensors and can be arranged about the autonomous vehicle102. For example, the sensors104-108can include, without limitation, one or more inertial measuring units (IMUs), one or more image sensors (e.g., visible light image sensors, infrared image sensors, video camera sensors, surround view camera sensors, etc.), one or more light emitting sensors, one or more global positioning system (GPS) devices, one or more radars, one or more light detection and ranging sensors (LIDARs), one or more sonars, one or more accelerometers, one or more gyroscopes, one or more magnetometers, one or more altimeters, one or more tilt sensors, one or more motion detection sensors, one or more light sensors, one or more audio sensors, etc. In some implementations, sensor104can be a radar, sensor106can be a first image sensor (e.g., a visible light camera), and sensor108can be a second image sensor (e.g., a thermal camera). Other implementations can include any other number and type of sensors.

The autonomous vehicle102can include several mechanical systems that are used to effectuate motion of the autonomous vehicle102. For instance, the mechanical systems can include, but are not limited to, a vehicle propulsion system130, a braking system132, and a steering system134. The vehicle propulsion system130can include an electric motor, an internal combustion engine, or both. The braking system132can include an engine brake, brake pads, actuators, and/or any other suitable componentry configured to assist in decelerating the autonomous vehicle102. The steering system134includes suitable componentry configured to control the direction of movement of the autonomous vehicle102during navigation.

The autonomous vehicle102can include a safety system136. The safety system136can include lights and signal indicators, a parking brake, airbags, etc. The autonomous vehicle102can also include a cabin system138, which can include cabin temperature control systems, in-cabin entertainment systems, etc.

The autonomous vehicle102can include an internal computing system110in communication with the sensors104-108and the systems130,132,134,136, and138. The internal computing system110includes one or more processors and at least one memory for storing instructions executable by the one or more processors. The computer-executable instructions can make up one or more services for controlling the autonomous vehicle102, communicating with remote computing system150, receiving inputs from passengers or human co-pilots, logging metrics regarding data collected by sensors104-108and human co-pilots, etc.

The internal computing system110can include a control service112configured to control operation of the vehicle propulsion system130, the braking system132, the steering system134, the safety system136, and the cabin system138. The control service112can receive sensor signals from the sensors104-108can communicate with other services of the internal computing system110to effectuate operation of the autonomous vehicle102. In some examples, control service112may carry out operations in concert with one or more other systems of autonomous vehicle102.

The internal computing system110can also include a constraint service114to facilitate safe propulsion of the autonomous vehicle102. The constraint service116includes instructions for activating a constraint based on a rule-based restriction upon operation of the autonomous vehicle102. For example, the constraint may be a restriction on navigation that is activated in accordance with protocols configured to avoid occupying the same space as other objects, abide by traffic laws, circumvent avoidance areas, etc. In some examples, the constraint service114can be part of the control service112.

The internal computing system110can also include a communication service116. The communication service116can include software and/or hardware elements for transmitting and receiving signals to and from the remote computing system150. The communication service116can be configured to transmit information wirelessly over a network, for example, through an antenna array or interface that provides cellular (long-term evolution (LTE), 3rd Generation (3G), 5th Generation (5G), etc.) communication.

In some examples, one or more services of the internal computing system110are configured to send and receive communications to remote computing system150for reporting data for training and evaluating machine learning algorithms, requesting assistance from remote computing system150or a human operator via remote computing system150, software service updates, ridesharing pickup and drop off instructions, etc.

The internal computing system110can also include a latency service118. The latency service118can utilize timestamps on communications to and from the remote computing system150to determine if a communication has been received from the remote computing system150in time to be useful. For example, when a service of the internal computing system110requests feedback from remote computing system150on a time-sensitive process, the latency service118can determine if a response was timely received from remote computing system150, as information can quickly become too stale to be actionable. When the latency service118determines that a response has not been received within a threshold period of time, the latency service118can enable other systems of autonomous vehicle102or a passenger to make decisions or provide needed feedback.

The internal computing system110can also include a user interface service120that can communicate with cabin system138to provide information or receive information to a human co-pilot or passenger. In some examples, a human co-pilot or passenger can be asked or requested to evaluate and override a constraint from constraint service114. In other examples, the human co-pilot or passenger may wish to provide an instruction to the autonomous vehicle102regarding destinations, requested routes, or other requested operations.

As described above, the remote computing system150can be configured to send and receive signals to and from the autonomous vehicle102. The signals can include, for example and without limitation, data reported for training and evaluating services such as machine learning services, data for requesting assistance from remote computing system150or a human operator, software service updates, rideshare pickup and drop off instructions, etc.

The remote computing system150can include an analysis service152configured to receive data from autonomous vehicle102and analyze the data to train or evaluate machine learning algorithms for operating the autonomous vehicle102. The analysis service152can also perform analysis pertaining to data associated with one or more errors or constraints reported by autonomous vehicle102.

The remote computing system150can also include a user interface service154configured to present metrics, video, images, sounds reported from the autonomous vehicle102to an operator of remote computing system150, maps, routes, navigation data, notifications, user data, vehicle data, software data, and/or any other content. User interface service154can receive, from an operator, input instructions for the autonomous vehicle102.

The remote computing system150can also include an instruction service156for sending instructions regarding the operation of the autonomous vehicle102. For example, in response to an output of the analysis service152or user interface service154, instructions service156can prepare instructions to one or more services of the autonomous vehicle102or a co-pilot or passenger of the autonomous vehicle102.

The remote computing system150can also include a rideshare service158configured to interact with ridesharing applications170operating on computing devices, such as tablet computers, laptop computers, smartphones, head-mounted displays (HMDs), gaming systems, servers, smart devices, smart wearables, and/or any other computing devices. In some cases, such computing devices can be passenger computing devices. The rideshare service158can receive from passenger ridesharing app170requests, such as user requests to be picked up or dropped off, and can dispatch autonomous vehicle102for a requested trip.

The rideshare service158can also act as an intermediary between the ridesharing app170and the autonomous vehicle102. For example, rideshare service158can receive from a passenger instructions for the autonomous vehicle102, such as instructions to go around an obstacle, change routes, honk the horn, etc. The rideshare service158can provide such instructions to the autonomous vehicle102as requested.

The remote computing system150can also include a package service162configured to interact with the ridesharing application170and/or a delivery service172of the ridesharing application170. A user operating ridesharing application170can interact with the delivery service172to specify information regarding a package to be delivered using the autonomous vehicle102. The specified information can include, for example and without limitation, package dimensions, a package weight, a destination address, delivery instructions (e.g., a delivery time, a delivery note, a delivery constraint, etc.), and so forth.

The package service162can interact with the delivery service172to provide a package identifier to the user for package labeling and tracking. Package delivery service172can also inform a user of where to bring their labeled package for drop off. In some examples, a user can request the autonomous vehicle102come to a specific location, such as the user's location, to pick up the package. While delivery service172has been shown as part of the ridesharing application170, it will be appreciated by those of ordinary skill in the art that delivery service172can be its own separate application.

One beneficial aspect of utilizing autonomous vehicle102for both ridesharing and package delivery is increased utilization of the autonomous vehicle102. Instruction service156can continuously keep the autonomous vehicle102engaged in a productive itinerary between rideshare trips by filling what otherwise would have been idle time with productive package delivery trips.

Autonomous vehicles are vehicles having computers and control systems that perform driving and navigation tasks conventionally performed by a human driver. As autonomous vehicle technologies continue to advance, ride-hailing services will increasingly utilize autonomous vehicles to improve service safety and efficiency. For effective use in ride-hailing deployments, autonomous vehicles will be required to execute many service functions that are conventionally performed by human drivers.

Currently, autonomous vehicles include a main vehicle computer that is individually connected to all of the sensors that are positioned throughout the autonomous vehicle. This type of sensor connectivity arrangement requires many connection ports, wiring harnesses, a large enclosure, and unique firmware as each sensor includes its own respective firmware that is independently developed by the manufacturer. For example, the sensors are built by automotive Tier 1 manufacturers that have no cross-functional knowledge of sensors from other manufacturers. Packaging several enclosures into a small space, writing unique driver code for each sensor, sourcing several different automotive grade connectors, and managing several Tier 1 suppliers is extremely challenging, expensive, and time-consuming.

As such, a need exists for a system and a method that can efficiently and effectively aggregate sensor data, thereby providing a modular sensor data system for autonomous vehicles.

FIG.2illustrates an example topology of a sensor data aggregation system200, according to some aspects of the disclosed technology.FIG.3illustrates an example of zones222A-222D of the sensor data aggregation system200ofFIG.2, according to some aspects of the disclosed technology.

Sensor Data Aggregation System:

In some instances, the sensor data aggregation system200can be an integrated controller that manages temperature, sensor cleaning, motor control, data aggregation, power supply, or any other auxiliary function that is suitable for the intended purpose and understood by a person of ordinary skill in the art to enable modular and upgradeable sensing for autonomous driving.

The sensor data aggregation system200can also aggregate the above-referenced auxiliary functions into a module, thereby reducing the overall cost, size, connector count, and mass of the sensor data aggregation system200. In some instances, the sensor data aggregation system200can streamline firmware driver development into a codebase, which can further reduce an overall interface with a main autonomous vehicle computer, while reducing an overall autonomous vehicle component count.

The sensor data aggregation system200can include a servo-drive204(e.g., a brushless direct current (DC) control), a microcontroller unit (“MCU”)206, an Ethernet switch208, an Ethernet physical layer (“PHY”)210, and a power conversion and failover unit214. The sensor data aggregation system200may be communicatively coupled to a brushless DC motor202, a main autonomous driving compute212, a 12V power source216, and a plurality of sensors220.

In some instances, the sensor data aggregation system200can be integrated into a small package that can be positioned alongside the various sensors220of the autonomous vehicle102. The sensor data aggregation system200can further include one or more printed circuit boards (PCB) populated with the microcontroller206, the servo drive204, the power management214, and the Ethernet switch208and physical layer integrated circuits (“IC”)210,218. In other instances, the sensor data aggregation system200can include PCB connectors that interface with the sensor data aggregation system's200wiring harness, the sensors220, and supporting content such as motors202, thermocouples, or any other supporting content suitable for the intended purpose and understood by a person of ordinary skill in the art. In such an instance, the sensors220can be connected to the sensor data aggregation system200rather than be directly connected to the main autonomous driving compute212, thereby reducing the numbers of connections with the main autonomous driving compute212.

In other instances, the sensor data aggregation system200can be agnostic of the sensors220that the sensor data aggregation system200aggregates, and can further be prepared for future expansion. The sensor data aggregation system200can include input/output interfaces to provide interfaces for additional sensing or actuation in the event that additional auxiliary functions are added to the sensor data aggregation system200. This also allows the sensor data aggregation system200to be used in several instances on the autonomous vehicle102and to not be paired with a specific sensor set or sensor enclosure.

The autonomous vehicle102of the sensor data aggregation system200can include various sensors220to detect objects such as camera sensors, light detection and ranging (LIDAR) sensors, radio detection and ranging (RADAR) sensors, and any other sensor suitable for the intended purpose and understood by a person of ordinary skill in the art. The sensors220collect data and measurements that the autonomous vehicle102can use for operations such as navigation and automotive controls.

The sensors220can provide the data and measurements to an internal computing system (e.g., the main autonomous driving compute212) of the autonomous vehicle102, which can use the data and measurements to control a mechanical system of the autonomous vehicle102, such as a vehicle propulsion system, a braking system, a door lock system, or a steering system. Furthermore, the sensors220can be mounted at fixed locations on the autonomous vehicle102to provide optimum views of the surrounding area. In some instances, the sensors220of the sensor data aggregation system200can determine the speed, trajectory, distance, position, size, or any other parameter of an object suitable for the intended purpose and understood by a person of ordinary skill in the art.

In some instances, the zones222A-222D (e.g., aggregation zones) of the sensor data aggregation system200can include areas around the autonomous vehicle102that may be proximate to a cluster of sensors220and/or physical components of the autonomous vehicle102. For example, as shown inFIG.3, the aggregation zones222A-222D are illustrated as four quadrants of the autonomous vehicle102(e.g., a front driver quadrant222A, a front passenger quadrant222B, a rear driver quadrant222C, and a rear passenger quadrant222D). The number and size of aggregation zones can also vary depending on the quantity, size, and position of the various sensors220around the autonomous vehicle102. For example, the sensor data aggregation system200can include six aggregation zones, one aggregation zone on the left driver side and another aggregation zone on the right passenger side. In some instances, the sensor data aggregation system200can aggregate the sensor data from each of the aggregation zones222A-222D, process the aggregated sensor data, and provide instructions to corresponding components of the autonomous vehicle102accordingly.

Autonomous Driving Compute Instructions:

In other instances, the sensor data aggregation system200can receive instructions and commands from the main autonomous driving compute212(e.g., a central autonomous driving system computer (ADSC)) over an interface such as a controller area network (“CAN bus”), Ethernet, or any other interface suitable for the intended purpose and understood by a person of ordinary skill in the art. After receiving commands from the main autonomous driving compute212and/or the sensors220, the sensor data aggregation system200can communicate internally to provide instructions to the servo drive204(e.g., motor controller). For example, if the main autonomous driving compute212requests a different azimuth angle for an articulator of the autonomous vehicle102, the main autonomous driving compute212can provide a command to the sensor data aggregation system200, which can then utilize stored corresponding firmware to request the azimuth angle of the BLDC motor202via the motor controller (e.g., servo drive204).

In some instances, the sensor data aggregation system200can be a subcomponent in an upgradeable sensor aggregation module (e.g., a sensor “pod”) that can be configured to manage articulator motor control, temperature control, sensor cleaning control, power supply, data aggregation, and other auxiliary functions to support sensor integration with the autonomous vehicle102. For example, the sensor data aggregation system200can aggregate the following auxiliary functions into a system: DC motor (e.g., brushless) control and actuation204, fan control and thermal management, solenoid and/or local diaphragm compressor control and actuation, data aggregation (e.g., Ethernet switch208), and redundant power control214.

1) DC Motor Control and Actuation:

In some instances, the sensor data aggregation system200can be configured to control the BLDC motor202or any other motor suitable for the intended purpose and understood by a person of ordinary skill in the art via the servo drive204. The sensor data aggregation system200can control the BLDC motor202based on instructions from the main autonomous driving compute212or from data received from the sensors220. For example, if the sensor data aggregation system200receives instructions from the main autonomous driving compute212regarding controlling the BLDC motor202, the sensor data aggregation system200can execute the instructions accordingly and provide corresponding instructions to the servo drive204that then controls the BLDC motor202. In other instances, the sensor data aggregation system200can receive data from the sensors220via the Ethernet PHY218and the Ethernet switch208, and independently determine whether to control certain aspects of the autonomous vehicle102such as the BLDC motor202(e.g., independent of the main autonomous driving compute212). In such a case, the sensor data aggregation system200can be autonomous of the main autonomous driving compute212and independently control the BLDC motor202. Thereafter, the sensor data aggregation system200can provide instructions to the BLDC motor202via the servo drive204.

2) Fan Control and Thermal Management:

In some instances, the sensor data aggregation system200can be configured to include fan control and thermal management of the autonomous vehicle102. For example, the sensor data aggregation system200can receive data from the sensors220that may indicate that a particular zone222A-222D is overheating. In this instance, the sensor data aggregation system200can activate fans and thermal controls in the corresponding zone222A-222D to decrease the temperature of the zone222A-222D. In other instances, the sensor data aggregation system200can perform fan control and thermal management independent of the main autonomous driving compute212.

3) Solenoid and/or Local Diaphragm Compressor Control and Actuation:

In some instances, the sensor data aggregation system200can be configured to include solenoid and/or local diaphragm compressor control and actuation. For example, if the sensor data aggregation system200receives instructions from the main autonomous driving compute212to clean a part of the autonomous vehicle102, the sensor data aggregation system200can activate a solenoid or actuate a diaphragm compressor to clean the corresponding part of the autonomous vehicle102. The sensor data aggregation system200can also be configured to receive data from the sensors220indicating that a part of the autonomous vehicle102should be cleaned. In such an instance, the sensor data aggregation system200can activate a solenoid or actuate a diaphragm compressor to clean the corresponding part of the autonomous vehicle102, independent of receiving instructions from the main autonomous driving compute212.

In some instances, the sensor data aggregation system200can be configured to aggregate data from the sensors220. For example, the sensor data aggregation system200can receive data from sensors220having different communication protocols from one another, process the received data from the sensors220to a communication protocol designated by the main autonomous driving compute212, and provide the processed data to the main autonomous driving compute212. This can allow the sensor data aggregation system200to convert the communication protocol of the sensors220so that the main autonomous driving compute212can reserve its resources for other tasks. In some instances, the Ethernet switch208and the Ethernet PHY210,218may be one example of a communication protocol. In other instances, examples of communication protocols (e.g., inter-pod) may include Gigabit Multimedia Serial Link (GMSL), Flat Panel Display Link (FPD Link), 100B-T1 (Broad-R Reach), 1000B-Tx, controller area network (CAN), local interconnect network (LIN), and any other type of communication protocol that can be utilized for the intended purpose and understood by a person of ordinary skill in the art.

In some instances, the sensor data aggregation system200can be configured to control power conversion and failover214of the power input216(e.g., 12V power input). In other instances, the sensor data aggregation system200can receive instructions from the main autonomous driving compute212to modify power inputs and outputs. The sensor data aggregation system200can also receive data from the sensors220indicating that power outputs and/or inputs be changed. In such an instance, the sensor data aggregation system200can change power inputs and/or outputs based on the data received from the sensors220, independent of receiving instructions from the main autonomous driving compute212.

In some instances, the sensor data aggregation system200can integrate several sensor-specific management functions. For example, instead of the main autonomous driving compute212performing sensor-specific management functions, the sensor data aggregation system200can perform these functions independent from the main autonomous driving compute212(e.g., as an “edge device”). In some instances, the BLDC motor202, the power input216, the sensors220, an actuator, and a solenoid may be components of the autonomous vehicle102.

FIGS.4A-4Cillustrate examples of sensor aggregation processes, according to some aspects of the disclosed technology.

Diagnostics and Data Logging:

As shown inFIG.4A, the sensor data aggregation system200can be configured to perform diagnostics and data logging400A, which can enable the sensor data aggregation system200to have a higher automotive safety integrity level and provide useful debugging and logging information. Such diagnostics and data logging can be performed by the sensor data aggregation system200without receiving instructions from the main autonomous driving compute212.

In some instances, the main autonomous driving compute212(e.g., ADSC) can request diagnostics402. The request can then be abstracted to an Ethernet packet addressed to the sensor data aggregation system200(e.g., the pod management module)404. In response to the request, the sensor data aggregation system200can relay information and data from the sensors220that may correspond to the overall health of the sensor data aggregation system200,406.

As shown inFIG.4B, the sensor data aggregation system200can be configured to replace and/or upgrade hardware400B. In some instances, the sensor data aggregation system200can include replacing and/or upgrading hardware408. In other instances, the sensors220that may be connected to the sensor data aggregation system200can be swamped or changed within the sensor data aggregation system200,410. In such an instance, the sensor data aggregation system200can remain agnostic of the sensors220that the sensor data aggregation system200aggregates, and can further be prepared for future expansion412. This can also allow the sensor data aggregation system200to be used in several instances on the autonomous vehicle102and to not be paired with a specific sensor set or sensor enclosure.

As shown inFIG.4C, the sensor data aggregation system200can be configured to clean the sensors220,400C. In some instances, the main autonomous driving compute212(e.g., ADSC) can request sensor cleaning414. The request can be an Ethernet command that can be provided to the sensor data aggregation system200(e.g., the pod management module)416. In response to the Ethernet command, the sensor data aggregation system200can adjust inputs and/or outputs to actuate the solenoid418to begin cleaning of the sensors220.

Having disclosed some example system components and concepts, the disclosure now turns toFIG.5, which illustrate example method500for sensor data aggregation. The steps outlined herein are exemplary and can be implemented in any combination thereof, including combinations that exclude, add, or modify certain steps.

At step502, the method500can include receiving first data from a first sensor utilizing a first communication protocol, wherein the first sensor can be positioned in an aggregation zone.

At step504, the method500can include receiving second data from a second sensor utilizing a second communication protocol, wherein the second sensor can be positioned in the aggregation zone. In some instances, the first communication protocol and the second communication protocol can be firmware of the corresponding sensor.

In other instances, the first sensor and the second sensor may be agnostic to an autonomous vehicle such that the autonomous vehicle may not be paired with a specific sensor set or sensor enclosure.

At step506, the method500can include processing the first data received from the first sensor and the second data received from the second sensor to conform the first communication protocol and the second communication protocol.

At step508, the method500can include providing instructions based on the processed first data and the processed second data in a third communication protocol, wherein the instructions adjust auxiliary functions of an autonomous vehicle.

In some instances, the auxiliary functions of the autonomous vehicle can include at least one of temperature control, sensor cleaning, motor control, data aggregation, and power supply control. In other instances, the sensor cleaning can be actuated by a solenoid. The motor control can be directed by a servo drive to control a motor of the autonomous vehicle. The temperature control can be initiated by the activation of a fan.

In other instances, the third communication protocol can be a communication protocol of a main computer of the autonomous vehicle. The third communication protocol can be different from the first communication protocol and the second communication protocol. In some instances, the first sensor and the second sensor may not be directly connected to the main computer of the autonomous vehicle.

In some instances, the providing of the instructions can be provided to corresponding components of the autonomous vehicle. In other instances, the providing of the instructions to the corresponding components can occur without receiving instructions to adjust the auxiliary functions from a main computer of the autonomous vehicle.

In other instances, the method500can further include performing diagnostics and data logging to have a higher automotive safety integrity level and provide useful debugging and logging information. The diagnostics and data logging information can be provided to the main computer to determine the overall health of the autonomous vehicle. In some instances, the method500can include receiving a request for diagnostic data. The request for diagnostic data can be abstracted to an Ethernet packet and provided through an Ethernet switch. The method500can then relay data from the first sensor and the second sensor to the main computer of the autonomous vehicle in response to the request for diagnostic data.

In some instances, the method500can further include replacing and/or upgrading the first sensor and/or the second sensor without conforming the communication protocols of the first sensor and the second sensor with the communication protocol of the main computer of the autonomous vehicle.

In other instances, the method500can further include receiving instructions to clean the sensors from the main computer of the autonomous vehicle. The request can be an Ethernet command that can include instructions to actuate a solenoid to begin cleaning of the first sensor and/or the second sensor.

FIG.6illustrates an example computing system600which can be, for example, any computing device making up internal computing system110, remote computing system150, a passenger device executing rideshare application170, or any other computing device. InFIG.6, the components of the computing system600are in communication with each other using connection605. Connection605can be a physical connection via a bus, or a direct connection into processor610, such as in a chipset architecture. Connection605can also be a virtual connection, networked connection, or logical connection.

Example system600includes at least one processing unit (CPU or processor)610and connection605that couples various system components including system memory615, such as read-only memory (ROM)620and random access memory (RAM)625to processor610. Computing system600can include a cache of high-speed memory612connected directly with, in close proximity to, or integrated as part of processor610.

Processor610can include any general purpose processor and a hardware service or software service, such as services632,634, and636stored in storage device630, configured to control processor610as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor610may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction, computing system600includes an input device645, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. Computing system600can also include output device635, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input/output to communicate with computing system600. Computing system600can include communications interface640, which can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement, and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

The storage device630can include software services, servers, services, etc., that when the code that defines such software is executed by the processor610, it causes the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor610, connection605, output device635, etc., to carry out the function.