Patent Publication Number: US-2020283030-A1

Title: Driving policies determination

Description:
RELATED APPLICATION INFORMATION 
     The present application claims the benefit of priority from US Provisional Patent Application, Ser. No. 62/528745 filed on Jul. 5, 2017 which is incorporated herein in its entirety. 
    
    
     TECHNICAL FIELD 
     The present disclosure relates generally to vehicle driving systems, and more particularly to determining driving policies based on analysis of multimedia content. 
     BACKGROUND 
     In part due to improvements in computer processing power and in location-based tracking systems such as global positioning systems, autonomous and other assisted driving systems have been developed with the aim of providing driverless control or driver-assisted control of vehicles while in movement. An autonomous vehicle includes a system for controlling the vehicle based on the surrounding environment such that the system autonomously controls functions such as acceleration, braking, steering, and the like. 
     Existing solutions for autonomous driving may use a global positioning system receiver, electronic maps, and the like, to determine a path from one location to another. Understandably, fatalities and injuries due to vehicles colliding with people or obstacles during the determined path are significant concerns for developers of autonomous driving systems. To this end, autonomous driving systems may utilize sensors such as cameras and radar for detecting objects to be avoided. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The subject matter that is disclosed herein is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the disclosed embodiments will be apparent from the following detailed description taken in conjunction with the accompanying drawings. 
         FIG. 1  is a network diagram utilized to describe the various disclosed embodiments; 
         FIG. 2  is a schematic diagram of a driving policies&#39; generator according to an embodiment; 
         FIG. 3  is a flowchart illustrating a method for generating driving policies based on multimedia content elements according to an embodiment; 
         FIG. 4  is a block diagram depicting the basic flow of information in the signature generator system of  FIG. 1 ; and 
         FIG. 5  is a diagram showing a flow of patches generation, response vector generation, and signature generation in a large-scale speech-to-text system. 
     
    
    
     DESCRIPTION OF EXAMPLE EMBODIMENTS 
     Overview 
     A method for determining driving policies for a vehicle includes: receiving, in real-time during a trip of a vehicle, at least a set of input multimedia content elements captured by at least one sensor deployed in proximity to the vehicle, determining a plurality of possible future scenarios based at least on the set of input multimedia content elements, determining a probability score for each of the plurality of possible future scenarios, determining at least one driving policy according to at least the probability score for at least one of the plurality of possible future scenarios, and controlling the vehicle according to the at least one driving policy. 
     Description 
     It will be appreciated that as autonomous vehicles are introduced they will have to co-exist in the near future with non-autonomous vehicles, and even among autonomous vehicles, additional safety precautions may be necessary before they are safe enough for reliable, general use. 
     For example, some existing autonomous driving solutions engage in automatic or otherwise autonomous braking to avoid and/or minimize damage from collisions. However, such solutions may face challenges in accurately identifying obstacles. Moreover, such solutions typically employ a configured setting for braking or deceleration in response to the detection of a potential collision event. Such a setting does not necessarily account for the continued inertia and/or changes in movement of the obstacle being avoided. As a result, the automatically braking vehicle may stop unnecessarily quickly or conversely may not stop quickly enough. 
     Accordingly, in practice such solutions may not successfully prevent the collision event from occurring. In fact, in some cases the solutions may actually be a contributary factor in causing a collision, even if not necessarily the initially detected potential collision event. For example, stopping quickly to avoid an obstacle in front of the car may result in a rear-end collision caused by a vehicle behind the autonomously braking vehicle. 
     It will therefore be appreciated that such solutions typically suffer from a lack of proper consideration for the overall context for the detection of a potential collision event. It would therefore be advantageous to provide a solution for accurately detecting obstacles and determining possible scenarios respective thereof. 
     Reference is now made to  FIG. 1  which is an exemplary network diagram  100  utilized to describe the various embodiments disclosed herein. Network diagram  100  comprises a driving control system (DCS)  120 , a driving policies generator  130 , a database  150 , and at least one sensor  160 , communicatively connected via a network  110 . Network  110  may be implemented using one or more of the Internet, the world-wide-web (WWW), a local area network (LAN), a wide area network (WAN), a metro area network (MAN), and/or any other network(s) capable of enabling communication between the elements of network diagram  100 . 
     Driving control system  120  is configured to control the vehicle (not shown), or at least a function thereof, either autonomously or at least semi-autonomously subject to driving policies determined by driving policies generator  130  in real-time during a trip of the vehicle based on sensor signals captured by sensors  160  deployed in proximity to the vehicle. While  FIG. 1  depicts a single driving control system  120 , it will be appreciated that in practice the overall functionality of driving control system  120  may be provided by a multiplicity of such systems. For example, driving control system  120  may interface with one or more of the vehicle&#39;s electronic control units (ECUs) to control the vehicle. Alternatively, in some implementations one or more of the vehicle&#39;s ECUs may be configured to function as additional driving control systems  120  that may communicate directly with driving policies generator  130 . 
     In accordance with an exemplary embodiment, one, some, or all of driving control system  120 , driving policies generator  130 , sensor(s)  160  may be disposed in or affixed to the vehicle. It will be appreciated that the trip includes movement of the vehicle from at least a start location to a destination location. During the trip, at least visual multimedia content elements are captured by the sensors  160 . 
     At least one of sensors  160  is configured to capture visual multimedia content elements demonstrating characteristics of at least a portion of the environment (e.g., roads, obstacles, etc.) surrounding the vehicle. In an example implementation, sensors  160  may include one or more cameras installed on a portion of a vehicle such as, but not limited to, a dashboard of the vehicle, a hood of the vehicle, a rear window of the vehicle, and the like. The visual multimedia content elements may include images, videos, and the like. The sensors  160  may be integrated in or communicatively connected to the driving control system  120  without departing from the scope of the disclosed embodiments. 
     In accordance with some embodiments described herein, one or more other sensors  160  may be configured to capture audio signals in the vicinity of the vehicle. For example, sensors  160  may include one or more microphones mounted in one or more locations on the vehicle&#39;s exterior. The microphone(s) may be disposed to capture ambient sounds in the driving environment, e.g., honking, shouting, brakes screeching, etc. Alternatively, or in addition, a microphone may also be located within the vehicle and disposed to capture sounds from, for example, passenger conversations, cellphone conversations, the vehicle&#39;s radio, and/or and an entertainment system (either as an integrated component of the vehicle and/or associated with an electronic device carried by one of the passengers). 
     Alternatively, or in addition, sensors  160  may be at least in part implemented using a vehicle&#39;s embedded electronic control units (ECUs). For example, ECUs controlling one or more of the vehicle&#39; s doors, windows, engine, power steering, seats, speed, telematics, transmission, brakes, battery, may also be leveraged to provide input regarding an environmental state for the vehicle. It will be appreciated that such ECUs may typically be connected to an onboard computer in the vehicle. In accordance with some embodiments described herein, driving control system  120  and/or driving policies generator  130  may be connected to, or even integrated as part of, the vehicle&#39;s onboard computer, such that no additional infrastructure may be necessary to receive sensor input from the vehicle&#39;s ECUs. 
     Alternatively, or in addition, one or more of sensors  160  may be implemented as a service, providing vehicle environment data from sensors operated independently of the vehicle. For example, a camera installed at a key intersection may provide “look ahead” images, or at least an angle or view not available to a camera mounted in or on the vehicle. In another example, the service may provide information regarding weather, traffic, and/or other environmental conditions. 
     Driving control system  120  may comprise an application  125  which may be implemented in software, hardware, firmware, or a combination thereof. Application  125  may be configured to send multimedia content elements and/or other environmental information captured by sensors  160  to driving policies&#39; generator  130 , and to receive policies therefrom. Application  125  may be further configured to receive collision avoidance instructions to be executed by driving control system  120  from driving policies&#39; generator  130 . 
     Database  150  may store a plurality of scenarios and associated potential causes and effects of collisions, probability scores, collision risk parameters, automatic braking instructions, and/or a combination thereof. Potential causes may include, but are not limited to, moving objects (e.g., other vehicles, pedestrians, animals, etc.), static objects (e.g., parked cars, buildings, boardwalks, trees, bodies of water, etc.), and/or current environmental conditions (rain, temperature, etc.). Each scenario represents a future possible series of events that leads to one or more outcomes. For example, given a pedestrian walking in proximity to an intersection in front of a vehicle in motion, one scenario may be that the pedestrian will cross the intersection, and one possible outcome may be a collision between the pedestrian and the vehicle. Another possible outcome may be that the pedestrian runs across the intersection and there is no collision. It will be appreciated that the possible outcomes listed herein are exemplary; in practice there may be other results as well. 
     A probability score for each of the plurality of scenarios may be stored in database  150 . In accordance with embodiments described herein, the probability score may be calculated based on analysis of actual observations of the scenarios as they have occurred. For example, traffic videos may be used to identify scenarios and then to use them to populate database  150 . The actual observed outcomes for each of the identified scenarios may be analyzed to calculate a probability score for each possible outcome. For example, given X occurrences observed for a given scenario with possible outcomes A and B: if outcome A is observed Y times, then its probability score may be calculated as Y/X; if outcome B is observed Z times, then its probability score may be calculated as Z/X, etc. Alternatively, or in addition, some or all of the probability scores may be input to database  150  manually. It will be appreciated that the embodiments described herein may support other methods of determining probability scores and populating database  150 . 
     Using the abovementioned example, the speed and route of both the vehicle and the pedestrian, may be used to determine a probability score for each of the possible outcomes, where a risk score may represent the likelihood of a worst-case outcome, e.g., a collision between them the vehicle and the pedestrian. It will be appreciated that in scenarios there may be more than one undesirable outcome. For example, in a given scenario there may be a probability score reflecting the probability that the vehicle may make contact with a pedestrian or a second vehicle. In the same scenario there may also be a probability score reflecting the probability that the vehicle may hit a telephone pole when swerving to avoid the pedestrian or vehicle. In such a scenario, the risk score may be calculated to represent a combined, weighted probability for either undesirable outcome to occur. 
     As depicted in  FIG. 1 , network diagram  110  also comprises signature generator system (SGS)  140  and deep-content classification (DCC) system  170 . In accordance with embodiments described herein SGS  140  and DCC system  170  are connected to the network  110  and may be utilized by the driving policies generator  130  to perform various embodiments described herein. It will be appreciated that each of SGS  140  and DCC system  170  may be connected to the Driving Policies Generator  130  either directly or through the network  110 . In certain configurations, SGS  140 , DCC system  170 , and/or both may alternatively be embedded in driving policies generator  130 . 
     SGS  140  is configured to generate signatures for multimedia content elements and comprises a plurality of computational cores, each computational core having properties that are at least partially statistically independent of each other core, where the properties of each core are set independently of the properties of each other core. Generation of signatures by the signature generator system is described further herein below with respect to  FIGS. 4 and 5 . 
     Deep content classification system  170  is configured to create, automatically and in an unsupervised fashion, concepts for a wide variety of multimedia content elements. To this end, deep content classification system  170  may be configured to inter-match patterns between signatures for a plurality of multimedia content elements and to cluster the signatures based on the inter-matching. Deep content classification system  170  may be further configured to generate reduced signature clusters by reducing the number of signatures in a cluster to a minimum while maintaining matching and enabling generalization to new multimedia content elements. Metadata of the multimedia content elements is collected to form, together with each of the reduced signature clusters, a concept. An example deep content classification system is described further in U.S. Pat. No. 8,266,185, which is assigned to the common assignee, the contents of which are hereby incorporated by reference. It will be appreciated that the configuration of SGS  140  and DCC  170  in network diagram  110  may be exemplary; the embodiments described herein may also support the use of other methods/systems to identify/classify the input multimedia content elements and/or to associate them with the scenarios and probability scores stored in database  150 . 
     In an embodiment, driving policies generator  130  may be configured to send the input multimedia content elements to signature generator system  140 , to deep content classification system  170 , or both. Additionally, driving policies generator  130  may also be configured to receive a plurality of signatures generated for the input multimedia content elements from signature generator system  140 , to receive a plurality of signatures (e.g., signature reduced clusters) of concepts matched to the input multimedia content elements from deep content classification system  170 , or both. Alternatively, or in addition, driving policies&#39; generator  130  may be configured to generate the plurality of signatures, identify the plurality of signatures (e.g., by determining concepts associated with the signature reduced clusters matching the multimedia content element to be tagged), or a combination thereof. 
     It will be appreciated that each signature is associated with at least one concept. A concept may be understood as a description of the content for which the signature was generated. Each concept comprises a collection of signatures representing associated multimedia content elements and metadata describing the concept. As a non-limiting example, a ‘Superman concept’ is a signature-reduced cluster of signatures describing elements (such as multimedia elements) related to, e.g., a Superman cartoon, and a set of metadata providing textual representation of the Superman concept. As another example, metadata of a concept represented by the signature generated for a picture showing a bouquet of red roses may be “flowers”. In yet another example, metadata of a concept represented by the signature generated for a picture showing a bouquet of wilted roses may be “wilted flowers”. 
     In accordance with embodiments described herein, driving policies generator  130  may be configured to determine a context of the input multimedia content elements based on their signatures, associated concepts, and/or both. Determination of the context allows for contextually matching between a potential cause of collision according to the input multimedia content elements and a predetermined potential cause of collision shown in a reference multimedia content element. Determining contexts of multimedia content elements is described further in U.S. patent application Ser. No. 13/770,603, assigned to the common assignee, the contents of which are hereby incorporated by reference. 
     In accordance with embodiments described herein, driving policies generator  130  may be configured to obtain, in real-time, or at least near real-time, input multimedia content elements from driving control system  120  that are captured by sensors  160  during the trip. It will be appreciated that at least some of the input multimedia content elements may be visual multimedia content elements showing obstacles that may lead to one or more future scenarios based on the current vehicle movement and the characteristics of the obstacle. For each future scenario, driving policies generator  130  may generate a probability score indicating the probability of that scenario occurring. The probability score may be generated by comparing one or more historical scenarios to each of the future possible scenarios that may occur based at least on the vehicle&#39;s movement and the obstacle&#39;s expected behavior. The obstacle may be, for example, pedestrians, animals, other vehicles, etc. It will be appreciated that the embodiments described herein may also support the use of other environmental factors as input when generating probability scores. For example, some of the historical scenarios may be associated with poor visibility and/or unsafe road conditions. These additional environmental factors may also be factored into the generation of probability scores, e.g., the presence of fog and/or slippery road conditions may increase the likelihood of an undesirable outcome. 
     In accordance with embodiments described herein, driving policies generator  130  may be configured to determine whether any reference multimedia content element matches the input multimedia content elements and, if so, to determine a probability score accordingly, e.g., per a probability score stored in database  150  for a scenario associated with the matched reference multimedia content element. For example, if the matched reference multimedia content element is a puddle on the road, the probability scores may reflect the likelihood for each possible outcome (e.g., how likely is it that the car may skid, the engine may be flooded, there may be no effect, etc.) as per the stored probability scores in database  150 . 
     In accordance with embodiments described herein, determining whether there is a matching reference multimedia content element includes generating at least one signature for each input multimedia content element and comparing the generated input multimedia content signatures to signatures of the reference multimedia content elements. It will be appreciated that driving policies generator  130  may be configured to send the input multimedia content elements to SGS  140 , to deep content classification system  170 , and/or both. Driving policies generator  130  may further be configured to receive the generated signatures (e.g., from SGS  140 ) and/or at least one concept matching the input multimedia content elements (e.g., from DCC system  170 ). It will also be appreciated that the functionality attributed herein to SGS  140  and DCC  170  may be exemplary; the embodiments described herein may also support the use of other methods/systems determining whether there is a matching reference multimedia content element. 
     Each reference multimedia content element in database  150  is a previously captured multimedia content element representing an obstacle or other potential future scenario associated therewith. Each reference multimedia content element may be associated with at least one probability score, a risk score (e.g., reflecting one or more undesirable outcomes with possible damage that may occur), predetermined collision avoidance instructions, and the like. The collision avoidance instructions include, but are not limited to, one or more instructions for controlling the vehicle, e.g., to avoid an accident due to colliding with one or more obstacles. 
     Each reference multimedia content element may further be associated with a portion of a vehicle so as to indicate the location on the vehicle from which the reference multimedia content element was captured. To this end, in some embodiments, a reference multimedia content element may only match an input multimedia content element if, in addition to any signature matching, the reference multimedia content element is associated with the same or a similar portion of the vehicle (e.g., a portion on the same side of the vehicle). 
     As a non-limiting example, input multimedia content elements showing a dog approaching the car from 5 feet away that were captured by a camera deployed on a hood of the car may only match a reference multimedia content element showing a dog approaching the car from approximately 5 feet away that was captured by a camera deployed on the hood or other area on the front side of the car. The same reference multimedia content element may not match the input multimedia content element if the input multimedia content element was captured from a camera facing the rear of the vehicle. However, it will be appreciated that there may be a scenario in database  150  where the vehicle is in reverse (i.e., moving backwards) with a dog approaching from the rear. Accordingly, if the input multimedia content element showing a dog approaching from the rear is accompanied by additional information indicating that the vehicle is in reverse, it may still match a reference multimedia content element in database  150 . 
     In accordance with embodiments described herein, when a potential collision is detected, driving policies generator  130  may be configured to generate an alert. The alert may indicate the potential cause of collision shown in the input multimedia content elements (i.e., a potential cause of collision associated with the matching reference multimedia content element), the at least one collision parameter associated with the matching reference multimedia content element (as stored in database  150 ), or both. The alert may further include one or more collision avoidance instructions to be executed by driving control system  120  to avoid the collision. The collision avoidance instructions may be instructions for configuring one or more portions of the driving control system such as, but not limited to, a braking system, a steering system, and the like. 
     In accordance with embodiments described herein, driving policies generator  130  may be configured to send the generated alert and/or the collision avoidance instructions to the driving control system  120 . Alternatively, driving policies generator  130  may include driving control system  120  in an integrated module and may be further configured to control the vehicle based on the collision avoidance instructions. 
     It will be appreciated that only one driving control system  120  and one application  125  are described herein above with reference to  FIG. 1  for the sake of simplicity and without limitation on the disclosed embodiments. Multiple driving control systems  120  may provide multimedia content elements via multiple applications  125 , and appropriate driving decisions may be provided to each such instance of driving control system  120 , without departing from the scope of the disclosure. 
     It should be noted that any of driving control system  120 , sensors  160 , driving policies generator  130 , and database  150  may be integrated without departing from the scope of the disclosure. 
     Reference is now made to  FIG. 2  which is an example schematic diagram  200  of driving policies generator  130  according to an embodiment. Driving policies generator  130  comprises processing circuitry  210  coupled to memory  220 , storage  230 , and network interface  240 . The components of driving policies&#39; generator  130  may be communicatively connected via bus  250 . 
     Processing circuitry  210  may be Instantiated as one or more hardware logic components and circuits. For example, and without limitation, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), Application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or any other hardware logic components capable of performing calculations and/or other manipulations of information. In accordance with embodiments described herein, processing circuitry  210  may be implemented as an array of at least partially statistically independent computational cores. The properties of each computational core may be set independently of those of each other core, as described further herein above. 
     Memory  220  may be volatile (e.g., RAM, etc.), non-volatile (e.g., ROM, flash memory, etc.), or a combination thereof. It will be appreciated that computer readable instructions to implement one or more embodiments disclosed herein may be stored in storage  230 . 
     Memory  220  may also be configured to store software. Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by processing circuitry  210 , instruct the processing circuitry  210  to perform the various processes described herein. Specifically, the instructions, when executed, facilitate at least the generation by processing circuitry  210  of driving alerts based on multimedia content as described herein. 
     Storage  230  may be magnetic storage, optical storage, and the like, and may be implemented, for example, as flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs), or any other suitable medium which may be used to store the desired information. 
     Network interface  240  enables driving policies generator  130  to communicate with the signature generator system  140  and/or DCC  170  for the purpose of, for example, sending multimedia content elements, receiving signatures, and the like. Further, network interface  240  enables driving policies&#39; generator  130  to obtain multimedia content elements from sensors  160  as well in order to determine a plurality of possible scenarios that may occur in light of the obstacles and the vehicle&#39;s movement. 
     It should be understood that the embodiments described herein are not limited to the specific architecture illustrated in  FIG. 2 , and other architectures may be equally used without departing from the scope of the disclosed embodiments. In particular, driving policies generator  130  may further include an integrated signature generator system functionally similar to SGS  140  that may be configured to generate signatures as described herein without departing from the scope of the disclosed embodiments. 
     Reference is now made to  FIG. 3  which depicts a flowchart  300  illustrating an exemplary method to be performed by driving policies generator  130  to generate driving policies based on multimedia content according to embodiments described herein. For example, as discussed hereinabove, driving policies generator  130  may generate driving policies based on multimedia content elements captured by sensors  160  (e.g., a camera) deployed in proximity to a vehicle such that the sensor signals indicate at least some features of the environment around the vehicle. The multimedia content elements may be captured during a trip, where the trip includes movement of the vehicle from a beginning location to a destination location. 
     Driving policies generator  130  may receive (step S 310 ), input multimedia content elements (MMCEs) during a vehicle&#39;s trip. As described herein, the input multimedia content elements may be captured by sensors  160  deployed in proximity to the vehicle and may be, for example, received from sensors  160  via driving control system  120  which may be communicatively connected to sensors  160 . The input multimedia content elements may be received in real-time, or near real-time, during the trip, thereby facilitating real-time provision of alerts to autonomous or assisted driving systems. 
     At least some of the input multimedia content elements may comprise obstacles shown therein. Such obstacles may include, both moving objects (e.g., pedestrians, other vehicles, animals, etc.) or stationary objects (e.g., signs, bodies of water, parked vehicles, statues, buildings, walls, etc.). 
     SGS  140  generates (step S 320 ) signatures of the input multimedia content elements. The generation of signatures by SGS  140  is further described herein below with respect of  FIGS. 4 and 5 . 
     In accordance with embodiments described herein, step S 320  may include SGS  140  generating (or at least causing generation) of at least one signature for each input multimedia content element and comparing the generated signatures for the input multimedia content element to signatures of the plurality of reference multimedia content elements. The reference multimedia content element signatures may be generated and stored in database  150  in a preprocessing step and/or during previous iterations of flowchart  300 . 
     In accordance with embodiments described herein, step S 320  may include generating the signatures via a plurality of at least partially statistically independent computational cores, where the properties of each core are set independently of the properties of the other cores. In another embodiment, S 320  includes sending the multimedia content element(s) to signature generator system  140 , to deep content classification system  170 , or both, and receiving the plurality of signatures in return. Signature generator system  140  may comprise a plurality of at least statistically independent computational cores as described further herein. Deep content classification system  170  may be configured to autonomously define concepts for a wide variety of multimedia content elements in an unsupervised fashion. 
     In accordance with embodiments described herein, step S 320  may include driving policies generator  130  querying DCC system  170  using the generated signatures to identify at least one concept matching the input multimedia content elements. The metadata of the matching concept may be used for correlation between a first signature (e.g., from the input MMCE) and at least a second signature (e.g., from a reference MMCE). 
     Driving policies generator  130  may determine (step S 330 ), a plurality of future possible scenarios based on matches between the input and reference multimedia content elements. It will be appreciated that the vehicle&#39;s movement and the identification of one or more obstacles that may potentially collide with the vehicle may be factored into such a determination. 
     Driving policies generator  130  may determine (step S 340 ) a probability score for each future scenario. The probability score can be determined by comparing the future scenarios to historical scenarios stored in the database  150  and determining the respective probability and characteristics associated therewith. It will be appreciated that at least some of the probability scores stored in database  150  may be determined and stored either in a preprocessing step and/or in previous iterations of flowchart  300 ; i.e., it will be appreciated that database may be at least partially populated with probability scores prior to a given iteration of flowchart  300 . Driving policies generator  130  may then determine (step S 350 ) driving policies for the future scenarios in light of their associated probability scores. The determination of the driving policies is further described hereinabove with respect of  FIG. 1 . 
     If additional input multimedia content elements have been received (step S 360 ), process control may return to step S 310 . Otherwise, execution of flowchart  300  may terminate. Accordingly, execution of flowchart  300  may continue until the trip is completed by, for example, arriving at the destination location, the vehicle stopping at or near the destination location, and the like. 
     As a non-limiting example, input video may be received from a dashboard camera mounted on a car and facing forward such that the dashboard camera captures video of the environment in front of the car showing a pedestrian entering a crosswalk. The captured input video is obtained in real-time and analyzed to generate signatures therefore. The generated signatures are compared to signatures of reference videos. Based on the comparison, a plurality of possible future scenarios may be determined. Then, a probability of a collision between the vehicle and the pedestrian may be determined in light of at least current/expected movement of the vehicle and the pedestrian. A driving policy may then be determined based on the determined probability of collision. As an example, in case of high probability, a driving policy may be to slow down while arriving close to the crosswalk. In the case of an autonomous vehicle, the driving policy may be to brake, thereby avoiding collision with the pedestrian. 
     Reference is now made to  FIGS. 4 and 5  which together illustrate an exemplary implementation for the generation of signatures for the multimedia content elements by SGS  140 . An exemplary high-level description of the process for large scale matching is depicted in  FIG. 4 . In this example, the matching is for video content. 
     Video content segments  2  from a master database (DB)  6  and a target DB  1  are processed in parallel by a large number of independent computational cores  3  that constitute an architecture for generating the signatures (hereinafter the “architecture”). Further details on the computational cores generation are provided below. The independent cores  3  generate a database  5  of robust signatures  4  for video content-segments  2  from target DB  1  and a database  8  of robust signatures  7  for video content-segments  2  from master DB  6 . An exemplary and non-limiting process of signature generation for an audio component is shown in detail in  FIG. 4 . Finally, target robust signatures  4  and/or signatures are effectively matched, by a matching algorithm  9 , to master robust signatures  7  and/or signatures database to find matches between the two databases. 
     To demonstrate an example of the signature generation process, it is assumed, merely for the sake of simplicity and without limitation on the generality of the disclosed embodiments, that the signatures are based on a single frame, leading to certain simplification of the computational cores generation. The matching system is extensible for signatures generation capturing the dynamics in-between the frames. In an embodiment the driving policies generator  130  may be configured with a plurality of computational cores to perform matching between signatures. 
     The signatures generation process is now described with reference to  FIG. 5 . The first step in the process of signatures generation from a given speech-segment is to breakdown the speech-segment to K patches  14  of random length P and random position within the speech segment  12 . The breakdown is performed by the patch generator component  21 . The value of the number of patches K, random length P and random position parameters is determined based on optimization, considering the tradeoff between accuracy rate and the number of fast matches required in the flow process of driving policies generator  130  and SGS  140 . Thereafter, all the K patches are injected in parallel into multiple computational cores  3  to generate K response vectors  22 , which are fed into a signature generator system  23  to produce a database of robust signatures and signatures  4 . 
     In order to generate robust signatures, i.e., signatures that are robust to additive noise L (where L is an integer equal to or greater than 1) by the computational cores  3 , a frame ‘i’ is injected into the cores  3 . Then, cores  3  generate two binary response vectors:   which is a signature vector, and {right arrow over (RS)} which is a robust signature vector. 
     For generation of signatures robust to additive noise, such as White-Gaussian-Noise, scratch, etc., but not robust to distortions typical in video elements, e.g., crop, shift and rotation, etc., a core Ci={n i }(1≤i≤L) may consist of a single leaky integrate-to-threshold unit (LTU) node or more nodes. The node n i  equations are: 
     
       
         
           
             
               V 
               i 
             
             = 
             
               
                 ∑ 
                 j 
               
                
               
                 
                   w 
                   
                     i 
                      
                     j 
                   
                 
                  
                 
                   k 
                   j 
                 
               
             
           
         
       
       
         
           
             
               n 
               i 
             
             = 
             
               θ 
                
               
                 ( 
                 
                   Vi 
                   - 
                   
                     Th 
                     x 
                   
                 
                 ) 
               
             
           
         
       
     
     where, θ is a Heaviside step function; w ij  is a coupling node unit (CNU) between node i and image component j (for example, grayscale value of a certain pixel j); kj is an image component T (for example, grayscale value of a certain pixel j); Th X  is a constant Threshold value, where ‘x’ is ‘S’ for signature and ‘RS’ for robust signature; and Vi is a Coupling Node Value. 
     The Threshold values Th X  are set differently for signature generation and for robust signature generation. For example, for a certain distribution of Vi values (for the set of nodes), the thresholds for signature (Th S ) and robust signature (Th RS ) are set apart, after optimization, according to at least one or more of the following criteria: 
     
       
         
           
             
               
                 
                   
                     
                       For 
                        
                       
                         : 
                       
                        
                       
                           
                       
                        
                       
                         V 
                         i 
                       
                     
                     &gt; 
                     
                       T 
                        
                       
                         h 
                         
                           R 
                            
                           S 
                         
                       
                     
                   
                    
                   
                     
 
                   
                    
                   
                     1 
                     - 
                     
                       p 
                        
                       
                         ( 
                         
                           V 
                           &gt; 
                           
                             T 
                              
                             
                               h 
                               S 
                             
                           
                         
                         ) 
                       
                     
                     - 
                     1 
                     - 
                     
                       
                         
                           ( 
                           
                             1 
                             - 
                             ɛ 
                           
                           ) 
                         
                         l 
                       
                        
                       
                         &lt;&lt; 
                         1 
                       
                     
                   
                 
               
               
                 1 
               
             
           
         
       
     
     i.e., given that l nodes (cores) constitute a robust signature of a certain image I, the probability that not all of these l nodes will belong to the signature of same, but noisy image,   is sufficiently low (according to a system&#39;s specified accuracy). 
       2:  p ( V   i   &gt;Th   RS )≈ l/L  
 
     i.e., approximately l out of the total L nodes can be found to generate a robust signature according to the above definition.
         3: Both robust signature and signature are generated for certain frame i.       

     It should be understood that even though the generation of a signature uses lossless compression, where the characteristics of the compressed data are maintained, the uncompressed data of the underlying multimedia content element may not be reconstructed; a generated signature may be unidirectional in that the lossless compression may be used on only a portion of the multimedia content element such that the entire element may not be reconstructed by merely reversing the lossless compression. However, the use of lossless compression facilitates the purpose of comparison to another signature without the need of comparison to the original data. The detailed description of the Signature generation can be found in U.S. Pat. Nos. 8,326,775 and 8,312,031, assigned to the common assignee, which are hereby incorporated by reference. 
     A computational core generation is a process of definition, selection, and tuning of the parameters of the cores for a certain realization in a specific system and application. The process may be based on several design considerations, such as: 
     (a) The cores are designed so as to obtain maximal independence, i.e., the projection from a signal space should generate a maximal pair-wise distance between any two cores&#39; projections into a high-dimensional space. 
     (b) The cores are optimally designed for the type of signals, i.e., the cores are maximally sensitive to the spatio-temporal structure of the injected signal, for example, and in particular, sensitive to local correlations in time and space. Thus, in some cases a core represents a dynamic system, such as in state space, phase space, edge of chaos, etc., which may be uniquely used herein to exploit their maximal computational power. 
     (c) The cores are optimally designed with regard to invariance to a set of signal distortions, of interest in relevant applications. 
     A detailed description of computational core generation and the process for configuring such cores is discussed in more detail in U.S. Pat. No. 8,655,801 which is assigned to the common assignee, the contents of which are hereby incorporated by reference. 
     It is important to note that the embodiments disclosed herein are only examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of the present application do not necessarily limit any of the various claimed inventions. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in plural and vice versa with no loss of generality. In the drawings, like numerals refer to like parts through several views. 
     It should be noted that various embodiments described herein are discussed with respect to autonomous driving decisions and systems are merely for simplicity and without limitation on the disclosed embodiments. The embodiments disclosed herein are equally applicable to other assisted driving systems such as, for example, accident detection systems, lane change warning systems, and the like. In such example implementations, the automated driving decisions may be generated, e.g., only for specific driving events. 
     The various embodiments disclosed herein may be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium consisting of parts, or of certain devices and/or a combination of devices. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such a computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit. Furthermore, a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal. 
     The term “non-transitory”, as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM). 
     All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the disclosed embodiments and the concepts contributed by the inventor to furthering the art and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure. 
     It should be understood that any reference to an element herein using a designation such as “first,” “second,” and so forth does not generally limit the quantity or order of those elements. Rather, these designations are generally used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be employed there or that the first element must precede the second element in some manner. Also, unless stated otherwise, a set of elements comprises one or more elements. 
     As used herein, the phrase “at least one of” followed by a listing of items means that any of the listed items can be utilized individually, or any combination of two or more of the listed items can be utilized. For example, if a system is described as including “at least one of A, B, and C,” the system can include A alone; B alone; C alone; A and B in combination; B and C in combination; A and C in combination; or A, B, and C in combination.