Patent Application
20210107496
Embodiments described herein generally relate to automated vehicle control and more specifically to passenger discomfort measurement during vehicle maneuver.
Mobility-as-a-Service (MaaS) is a concept whereby vehicles are managed and provided to transport passengers. MaaS generally involves using fleets of automated vehicles to provide the passenger transportation. Such automated vehicles generally use sensors and control hardware to reduce or eliminate the need for a human driver or pilot of the vehicle. An MaaS system generally includes an interaction between the service and the user through an app (e.g., mobile phone application) and a network. The network also generally connects the MaaS vehicles to each other, route planning services, or other hardware to enable a robot taxi (robotaxi) service or the like.
In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.
A good ride experience is important in mobility services. A good ride experience not only help ensure continued use of the service by passengers, but may also mitigate health issues, such as motion sickness. In traditional mobility services—such as taxis—passengers generally have direct contact with the driver and may share problems with the ride. When a human driver is absent, such as in automated vehicle MaaS, passengers no longer have a direct connection with another human experiencing the same ride hat is experienced by the passenger. Thus, it may be difficult to determine when the user experiences discomfort in a ride, and to what extent the discomfort is caused by the ride.
Passenger ride experience depends to a great extent on the driving style employed for the vehicle and the chosen route. Usually, abrupt acceleration (e.g., heavy braking, increased application of engine power, turning suddenly, etc.) or roads through unpleasant areas negatively impact the ride experience. Conversely, in many instances, using a smooth driving style improves the passenger's perception of the ride experience. Because the ride experience is the ride perceived by a passenger, the ride experience is very individual and situation specific. For example, while on one day, a person may like to get quickly from point A to point B—e.g., because of an important appointment)—and so is tolerant, or even welcoming, of an aggressive driving style, on another day the same person prefers a smooth, slow and steady ride instead.
Because the ride experience is important to a successful MaaS implementation, there is an issue of measuring rider comfort during trips, and using those measurements to improve MaaS, for a given trip and beyond. An example system to accomplish such rider comfort measurements includes in vehicle monitoring of biomechanical measurements of the user. Such biomechanical measurements may include such things as heart rate, facial expressions, or vocal utterances of the user. The biomechanical measurements may be classified to identify time periods in which the user experiences distress. These time periods may then be correlated to maneuvers performed by the vehicle to identify vehicle behavior that may have caused the distress. The system may then modify the parameters of a maneuver to reduce passenger discomfort in the current ride or in a future ride. Further, the metrics collected during the rides of various passengers may be aggregated to improve ride quality across many different riders.
In an example, the system may be implemented as a two-level system to improve the overall user experience in MaaS by improving the passenger comfort during rides. The system includes an in-vehicle subsystem that monitors the passenger comfort, correlates low comfort levels with currently executed maneuvers or road segments, and automatically adapts the driving style of an automated vehicle. The second level of the system is a cloud-based subsystem that receives anonymized ride data from the vehicles and, possibly, user feedback (e.g., voting or rating) for a last ride of the user. The cloud-based subsystem may then use data mining techniques to extract commonly disliked road segments or maneuvers. This information may be used to extend map data (e.g., through a high-definition map tile) to improve the ride experience for future rides. In an example, the cloud-based subsystem may compute statistics from road segments about the behavior of other traffic participants which also might lead to passenger discomfort. Again, the information may be used to update map information, or adjust automated driving parameters, to dynamically adapt and improve passenger ride experiences generally. Additional examples and details are described below.
During operation, the processing circuitry 110 is configured (e.g., via software, hardware design, or a combination of the two) to obtain (e.g., retrieve or receive) a set of biomechanical measurements of the passenger. The biomechanical measurements are measurable properties that relate to a physical condition of the passenger. Such measurements may be fairly direct, such as a heart rate measured by the wrist-worn device 120, or less direct, such as a vocal moan or other utterance. When a given biomechanical measurement is made, a time period is captured for the measurement. The time period may be represented as a timestamp with a predefined sampling frequency. In an example, the time period may include start and stop times to explicitly define the time period. In an example, a biomechanical measurement in the set of biomechanical measurements includes an applicable time period. The time period is used to correlate user comfort with driving conditions (e.g., a maneuver performed by the vehicle 105) as described below.
There may be several different sources from which the processing circuitry 110 may obtain the biomechanical measurements. In an example, a biomechanical measurement is retrieved from a device of the passenger. For example, the passenger may have a mobile phone, tablet, or other personal electronic device that either stores, or measures, the biomechanical measurement.
The processing circuitry 110 may pair (e.g., through a personal area network such as defined by IEEE 802.15 standards) or otherwise connect with the device and obtain the biomechanical measurements. In an example, the device is a wrist-worn device 120, such as a smart watch, fitness band, etc. Other types of devices, such as a chest band, a heart monitoring device, etc., may also be used. An advantage to such user devices generally comes from the intimate nature of such devices with the passenger's body. Thus, these devices may provide relatively accurate measurements of the passenger's heart rate, which is a useful measurement of stress.
In an example, the processing circuitry 110 is configured to obtain the set of biomechanical measurements from a sensor 115 mounted in the vehicle 105. The in-vehicle sensor 115 may provide a few advantages, as it is consistent across rides and passengers, whereas passenger possessed devices may not be. Also, the sensor 115 may use power or processing capabilities that are absent on low-power or embedded devices commonly available to passengers. These abilities may include sophisticated signal processing or artificial intelligence classifications, varying emitters (e.g., infrared emitters for touchless thermometers or depth cameras), etc. Moreover, often, the sensor 115 may have a perspective on the passenger that is generally not available to a worn or carried device, such as a view of the passenger's face.
The sensor 115 may be any single or combination of a variety of sensors. Examples of the sensor 115 includes a visible light spectrum camera, a depth camera, a thermal camera, a touchless thermometer, or a microphone. The biomechanical measurement captured by the sensor 115 varies based on the sensor. For example, where the sensor is a visible light spectrum camera, facial expressions (e.g., facial action coding system (FACS) or the like) may be captured to ascertain user emotions. A thermometer may capture absolute, or changes, in user facial temperature. A microphone may capture vocal utterances, such as grunts, groans, screams, etc. of the passenger. Although many of the biomechanical measurements described herein are specific to discomfort, signs of pleasure or relaxation may also be captured, because understanding what makes passengers happy may be as important as discovering what makes passengers unhappy.
The processing circuitry 110 is configured to select a subset from the set of biomechanical measurements. The subset of measurements corresponds to distress (e.g., discomfort) in the passenger. Thus, a variety of measurements that are indecipherable, or do not represent an unpleasant trip by the passenger, are removed to more efficiently identify areas of the ride to improve upon. As noted above, in an example, pleasure, or merely comfort, may be selected to identify parts of the ride that are enjoyed, or well tolerated, by the passenger. Generally, distress provides room for improvement (e.g., changes to the driving style or route) while contentment provides evidence that a change should not be made. This last element may be important to understand aggregated user experiences, where a particular driving style is enjoyed by most. Here, a distressed passenger experience generally should not be given too much weight in changing automated vehicle behavior. Rather, a more tailored, user preference, modification may be in order.
The processing circuitry 110 is configured to search, or filter, maneuvers performed by the vehicle 105 to find (e.g., identify) a maneuver operating in a time that overlaps a time period from a member of the subset. Here, the processing circuitry 110 is correlating the passenger discomfort to behaviors of the vehicle 105. A maneuver is driving control of the vehicle 105, such as increasing motor output, braking, or turning. A maneuver may also include a route selection. Route selection may be important as, for example, traveling a safe speed on a twisty road imparts greater lateral acceleration on the vehicle 105, and thus the passenger. Other factors of route selection may include bumpy roads—such as may be caused by cobblestones, potholes, speed bumps, etc.—noisy roads, or dusty roads, among others.
After correlating a maneuver to passenger discomfort based on cooccurrence in time, the processing circuitry 110 is configured to modify a future application of the maneuver. Thus, the processing circuitry 110 attempts to mitigate future passenger discomfort by changing the behavior of the vehicle 105. In an example, the maneuver includes an acceleration in a longitudinal, lateral, or vertical direction with respect to the vehicle. Examples of these types of acceleration are illustrated in
In an example, the acceleration is based on a route traveled by the vehicle. Here, reducing the acceleration includes selecting a different route. Again, the route may impart necessary acceleration (e.g., bumps at an acceptable rate of speed, lateral acceleration from turns or twists in the road, etc.) that impact the passenger. Changing the route to reduce these accelerations may provide additional comfort to the user. A new leg of the route may be selected based on route leg characteristics. Thus, if an uncomfortable leg of a route is detected, its characteristics, such as rate of speed, texture, radii of curves, etc may be compared to future legs of the route to identify legs to avoid.
The is an example in which accelerations may be increased. If a passenger is anxious about getting to a destination, such as being late for an appointment, and two routes are equally (within a threshold) quick, the passenger may be comforted by a hurried feel to the trip. Thus, in this example, the route with greater opportunity to impart accelerations (e.g., a twisty road) may be selected to assure the passenger that the vehicle 105 is speeding the passenger to the destination.
The modification of the maneuver may be applied to a current trip for the passenger, to a future trip for the passenger, or to trips by other passengers (current or future). Generally, modifying a current trip may be entirely managed by the processing circuitry 110. These modifications may include reducing a travel rate (e.g., speed) through corners, increases the time over which increase motor output is supplied, increase the time over Which braking output is supplied, increase the radius of a turn, etc. Some modifications may include choosing a different leg (e.g., road, path, etc.) for a future leg of the route. In general, the modifications attempt to smooth the ride for the passenger. As noted above, in some cases, the modification may make the ride rougher. Here, the goal is to give the passenger a sense of urgency when, for example, the passenger is anxious about the length of a trip.
For future trips of the passenger, or for different passengers, the processing circuitry 110 is configured to share trip information to the MaaS service 125. The MaaS service 125 may be configured to maintain a user profile for the passenger. Here, individual deviations from a norm may be tracked and given to the vehicle 105 to personalize the trip for the passenger. The MaaS service 125 may also query the user through network 130 to the user service 135) to obtain a. rating (e.g., opinion) about a trip. When considering riding maneuvers for other users, the passenger may be categorized, such that discomfort queues may be matched to other users, enabling a similar improvement of experience across the group. In an example, the personally identifiable data that is shared with the MaaS service 125 is anonymized to protect the passenger's privacy. In an example, the MaaS service 125 aggregates the measured and reported experiences of users to provide routing suggestions, or driving suggestions to automated vehicles, such as through a layer in an HD map.
The following provides additional details about data flow, an in-vehicle system, and a cloud-based system to facilitate passenger discomfort measurement and mitigation. For the discussion, consider an example of two different passengers: one person (Person A) feels very uncomfortable at higher speeds and prefers a smooth and steady ride; then, there is another person (Person B) that, because of high time pressure, becomes bad-tempered if the speed is too slow. Both take the same route and the same MaaS. In this example, whenever Person A is satisfied, Person B is not, and vice versa. Hence, it is important that passenger comfort level is sensed, monitored, and analyzed for each passenger.
Further consideration is given to a scenario in which there is a third and fourth person—namely Person C and Person D—that have the same preferences as Person A, and take the same route at a later point in time. The monitoring-and-analysis of passenger A demonstrated that, despite going slowly, the comfort level of Person A and Person C was very low on certain road segments—maybe due to many very tight bends. If the vehicle uploads a correlation between the situation where the low comfort level was detected, and the situation itself into a cloud-based analysis system, this cloud-based system could possibly detect undesirable road segments, which may then be used for future route planning, by extending the map content (e.g., map layers, navigation directives, etc.). As a result, the next passenger, Person D, would use another route, avoid low comfort levels for this person. Hence, the cloud-based analysis system may improve not only the current ride experience, but also pro-actively improve future ride experiences.
As it is sometimes very difficult to measure a passenger's comfort level, even with dedicated sensors, a user feedback system may be used to let the system know about the overall passenger satisfaction with the ride in general and with important factors (e.g., comfort, fear, time, etc.). Together with measurements that are available in vehicles—such as acceleration, traffic density, safety layer intervention, etc.—conclusions about driving style preferences may be made on a statistical basis as well possibly identifying one or more situations that lead to overall trip rating.
The in-vehicle system correlates a low comfort level with the current maneuver or a road segment and automatically without human intervention) adapts the driving style of the vehicle 310 when a low comfort level for a passenger was detected (e.g., driver slower, smoother, with less acceleration etc.).
The illustrated cloud-based system includes user profiles 315, comfort analysis 320, and mapping 325 capabilities. Generally, the in-vehicle system accepts profile information 315 for the passenger 305 and mapping 325 to modify its operations and provides trip data to the user profile 315. Thus, the cloud-based system maintains or collates ride data and user feedback and analyzes ride data—often in an anonymized manner to respect user privacy—to find common patterns among different passengers to identify maneuvers and road segments that are causing low comfort levels. With respect to the comfort analysis 320, filters may be used to exclude situations that are caused by misbehaviors of other traffic participants. For example, if an aggressive braking maneuver was applied to avoid hitting an unexpected cut-in vehicle, even if the passenger 305 is discomforted, there was nothing that the vehicle 310 could realistically do to prevent such an occurrence in the future. However, if such cut-ins are frequent upon a leg of a route, then perhaps the route leg should be avoided. The differences will be discovered via a statistical analysis of many passengers to prevent outliers from destructively interfering with route planning.
The cloud-based system updates mapping 325 data with the previous results (e.g., comfort conclusions), to enable others with access to the mapping 325 to avoid using road segments causing low comfort. Here, future routing requests will be labeled with a “high-comfort” route, in addition to the normal routes (e.g., shortest, fastest, etc.). Here, an accumulation of situations is considered where other traffic participants' behaviors often lead to an emergency reactions (e.g., safety systems—such as Responsibility-Sensitive Safety (RSS) or Safety Force Field (SET)—resulting in the vehicle (e.g., ego vehicle) acting in predictively precautions way at these places resulting in less discomfort for the passengers. In an example, map data may be updated to include adaptive safety system parameters, loosening or tightening buffer zones, for example, between vehicles to reduce hazardous situations.
Although many of the examples discussed herein address terrestrial vehicles ferrying passengers, the system and arrangement of operations may be applied to many different transportation solutions. For example, given human-operated taxis, the same techniques may be used to identify passenger discomfort and select routes to improve passenger comfort. The system may even suggest that a driver slow down, or smooth out turns, in order to modify the driving style of the driver. Other transportation systems, such as trams, busses, bicycles, scooters, etc. may also benefit by identifying passenger discomfort and, at least, providing information to select routes or route legs that increase passenger comfort.
In an example, the monitoring component 405 continuously processes new sensor data or the smart health data if available. In an example, the data is provided to an artificial intelligence system to classify the current well-being of the passenger. In an example, the output of the AI system is a comfort level. In an example, the comfort level may be a normalized real number value between zero (the lowest level of comfort) and one (the highest level of comfort. Thus,
Comfort Level CL=f(image, health data) ∈[0,1]
The analysis component, such as the root cause analysis component 415 or the situation analysis 410, may use the comfort level CL together with map information—such as from a current road segment obtained by map matching the UPS position of the vehicle to the map—and information about the current driving situation, to create a correlation between the comfort level and the current driving behavior. In an example, if the passenger's comfort level is low, the adaption component 420 may be used to change the driving style of the automated vehicle.
To create a mapping between situation and CL, the CL may he tracked and aggregated (e.g., averaged, exponential moving average, weighted average, etc.) over time. Such aggregation may be useful to smooth outputs from the monitoring component 405 may output noise, or outlier data, that may unduly affect the driving behavior model, such as by triggering an immediate reaction by the vehicle when no action should be taken. If, however, the vehicle continuously follows a leading vehicle too closely in the eyes of the passenger, the CL will decrease with repeated warnings or continued discomfort by the user over time, resulting in a trigger to adapt the driving style, if the averaged CL is too low. The following table provides some example correlations or mappings between the CL and a situation:
In an example, a table similar to this one may be transmitted (e.g., to the cloud 425) after the end of a ride or in pieces during the ride. The cloud 425 here supports the MaaS provider for the vehicle.
In an example, a database of several situation-maneuver classes may be created that cover different driving profiles velocity, acceleration, acceleration rate, etc.), different road segments (e.g., traffic light intersection, all-way stop intersections, highway, inner-city road, country lanes, etc.), and different driving behaviors (e.g., following vehicle lead, lane change, evasive maneuver, etc.). The records may then be compared to determine combinations that increase CL. In an example, a machine learning system, such as an AI, may be used to select a best fit combination of factors to combine. This is similar to an Operational Design Domain (ODD) identification likely to be used in future automated vehicles. In an example, safety systems, such as RSS, or driving risk estimation approaches, may be used to infer additional situation-specific information to provide a more comprehensive mapping of CL to a situation.
In general, as many aspects of a current situation are considered. Otherwise, a correlation between vehicle parameters that influence driving behavior and the passenger's comfort level maybe wrong, worsening rather than improving a passenger ride experience. Specifically, maneuvers performed to address unforeseen and unlikely to be repeated actions, such as a sudden braking upon the unexpected loss of tire pressure or swerving to avoid a vehicle running from the police, are detected and removed from consideration for behavioral adaptions if possible.
The adaption component 420 is configured to adapt driving parameters for the automated vehicle to improve passenger comfort. This may start by increasing the gap (e.g., lead) between a leading vehicle by a following vehicle if the proximity of the vehicles is causing discomfort to the passenger. Actions such as braking, changing lanes, reducing rate of acceleration, etc., may be employed by the adaption component 420 to increase passenger comfort.
Generally, the cloud-based system may perform data mining on passengers and trips to extract undesirable road segments or vehicle actions to enrich the map system 515 with information that may be used for future trips or by others to improve passenger CL generally. When the user profile database 520 information is considered, driving behavior may be tweaked for individual preferences to further raise the CL of a trip.
In an example, the cloud-based analysis system 510 receives input from the user—such as a general trip voting that may be performed via the MaaS mobile App—and from the vehicle used for the trip—e.g., created by the in-vehicle system. In an example, the trip data collection by the vehicle is configured to maintain user privacy by, for example, removing individual identifying information. In an example, only the CL, maneuver and situation data is transferred to the trip database 505 from the vehicle. In an example, the trip data is transmitted as part of the standard communications between the vehicle and the MaaS service provider.
The data received from passengers and vehicles is stored in the trip database 505. The trip database 505 is provided as input to the analysis component 510. The analysis component 510 applies a number of analytical techniques—such as AI classification, AI regression fitting, clustering, etc.—to correlate details among trips and comfort levels in the trip database 505.
Upon detection of a correlation between a low or high comfort level and road segment in a sufficiently large group of trips, the map system 515 is updated. Therefore, road segments may be annotated with an average comfort level, such as a moving average to grant recent trips a higher influence. The comfort level may be leveraged by routing systems to, for example, avoid road segments with low comfort levels, or to favor road segments with high comfort levels.
In an example, automatic adaption of parameters may be applied for different road segments where the observation shows that, for example, traffic or traffic routing led to situations where traffic participants are forced to behave more aggressive. These situations may lead to more uncomfortable driving styles for many impacted vehicles. By adapting parameters pro-actively these situations may be mitigated and lead to more comfortable trips for the passengers. Safety system parameters, such as increasing buffer distances between vehicles, are an example parameter that may be automatically adapted in this way.
In an example, the database of undesirable maneuvers 525 may be created or updated. The database of undesirable maneuvers 525 may be accessed by the vehicles to update driving policies to avoid such maneuvers if possible. For example, a low preference may be given to trajectories that result in undesirable maneuvers.
The combination of the features described above may lead to improved passenger comfort on a variety of MaaS vehicles. The following scenario illustrates an overall experience using these systems. The experience may start with booking. When a user is booking a ride, a route is selected to deliver the user to a destination. Dependent on user input during booking, the user may be presented with a selection of possible routes that are likely to satisfy the user. For example, a fastest or a shortest route may be presented, and a route that makes use of the comfort settings of the user in combination with the comfort data in the map. The user may select which route of the several to take.
Upon starting the ride, the user (now passenger) profile is loaded by the vehicle. The vehicle may automatically adapt its driving style according to the user profile or settings in a MaaS mobile App (which may also be used for booking). The modified driving style may affect acceleration parameters, as well as road preferences, among other things. While the ride is ongoing, the vehicle continually monitors the passenger comfort.
After the ride is completed, the vehicle, the user, or both provide (e.g., upload) a digest on the ride experience or detected comfort levels to the cloud-based user profile. As a result, the ride experience will become better with each trip, and will help to ensure passenger satisfaction. In an example, the cloud-based ratings may be used to infer additional information, for example to detect critical vehicle behavior to avoid.
As noted above, the present techniques can improve human driving as well. Although automatic driving style adaption is not possible, a communication to a human driver to modify the driving style may result in greater passenger comfort. Further, the route selection (e.g., road segment labeling) may be used equally by automated and human driver systems alike. In fact, the map updates may be employed in vehicles without a passenger, such as bicycles or scooters.
The map data may also be used by managing entities, such as rail operators, highway operators, cities, states, counties, provinces, countries, etc. These entities parse the maps and extract road segments with low comfort levels. Then, for example, an inspection team may investigate these locations and inspect the segments and potentially fix for example holes in the road surface.
At operation 605, a set of biomechanical measurements of a passenger in the vehicle is obtained. In an example, a biomechanical measurement in the set of biomechanical measurements includes an applicable time period. In an example, to obtain the set of biomechanical measurements, a biomechanical measurement is retrieved from a device of the passenger. In an example, the device of the passenger is a wrist-worn device.
In an example, to obtain the set of biomechanical measurements, a sensor mounted in the vehicle is used to observe the passenger. In an example, the sensor is a camera, in an example, facial expressions are captured as biomechanical measurements.
In an example, the sensor is a microphone. In an example, vocal utterances of passenger are captured as biomechanical measurements.
At operation 610, a subset from the set of biomechanical measurements is selected. The members of the subset are members of the biomechanical measurements that correspond to distress in the passenger.
At operation 615, maneuvers performed by the vehicle are searched to find a maneuver operating in a time that overlaps a time period from a member of the subset.
At operation 620, a future application of the maneuver is modified response to finding the maneuver. In an example, the maneuver includes an acceleration in a longitudinal, lateral, or vertical direction with respect to the vehicle. In an example, modifying a future application of the maneuver includes reducing the acceleration. In an example, the acceleration is based on a route traveled by the vehicle. Here, reducing the acceleration includes selecting a different route.
In an example, modifying the future application of the maneuver includes modifying a parameter of the maneuver for a current trip of the passenger. In an example, modifying the future application of the maneuver includes modifying a parameter of the maneuver for a future trip of the passenger. In an example, modifying the future application of the maneuver includes modifying a parameter of the maneuver for a different passenger.
In an example, modifying the future application of the maneuver includes collecting instances of distress across passengers with respect to the maneuver. Then, a parameter of the maneuver may be changed in response passing a statistical threshold with respect to the instances of distress.
In alternative embodiments, the machine 700 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 700 may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine 700 may act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The machine 700 may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.
The machine (e.g., computer system) 700 may include a hardware processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 704, a static memory (e.g., memory or storage for firmware, microcode, a basic-input-output (BIOS), unified extensible firmware interface (UEFI), etc.) 706, and mass storage 708 (e.g., hard drives, tape drives, flash storage, or other block devices) some or all of which may communicate with each other via an interlink (e.g., bus) 730. The machine 700 may further include a display unit 710, an alphanumeric input device 712 (e.g., a keyboard), and a user interface (UI) navigation device 714 (e.g., a mouse). In an example, the display unit 710, input device 712 and UI navigation device 714 may be a touch screen display. The machine 700 may additionally include a storage device (e.g., drive unit) 708, a signal generation device 718 (e.g., a speaker), a network interface device 720, and one or more sensors 716, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machine 700 may include an output controller 728, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
Registers of the processor 702, the main memory 704, the static memory 706, or the mass storage 708 may be, or include, a machine readable medium 722 on which is stored one or more sets of data structures or instructions 724 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 724 may also reside, completely or at least partially, within any of registers of the processor 702, the main memory 704, the static memory 706, or the mass storage 708 during execution thereof by the machine 700. In an example, one or any combination of the hardware processor 702, the main memory 704, the static memory 706, or the mass storage 708 may constitute the machine readable media 722. While the machine readable medium 722 is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 724.
The term “machine readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine 700 and that cause the machine 700 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine-readable medium examples may include solid-state memories, optical media, magnetic media, and signals (e.g., radio frequency signals, other photon-based signals, sound signals, etc.). In an example, a non-transitory machine-readable medium comprises a machine-readable medium with a plurality of particles having invariant (e.g., rest) mass, and thus are compositions of matter. Accordingly, non-transitory machine-readable media are machine readable media that do not include transitory propagating signals. Specific examples of non-transitory machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
In an example, information stored or otherwise provided on the machine readable medium 722 may be representative of the instructions 724, such as instructions 724 themselves or a format from which the instructions 724 may be derived. This format from which the instructions 724 may be derived may include source code, encoded instructions (e.g., in compressed or encrypted form), packaged instructions (e.g., split into multiple packages), or the like. The information representative of the instructions 724 in the machine readable medium 722 may be processed by processing circuitry into the instructions to implement any of the operations discussed herein. For example, deriving the instructions 724 from the information (e.g., processing by the processing circuitry) may include: compiling (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamically or statically linking), encoding, decoding, encrypting, unencrypting, packaging, unpackaging, or otherwise manipulating the information into the instructions 724.
In an example, the derivation of the instructions 724 may include assembly, compilation, or interpretation of the information (e.g., by the processing circuitry) to create the instructions 724 from some intermediate or preprocessed format provided by the machine readable medium 722. The information, when provided in multiple parts, may be combined, unpacked, and modified to create the instructions 724. For example, the information may be in multiple compressed source code packages (or object code, or binary executable code, etc.) on one or several remote servers. The source code packages may be encrypted when in transit over a network and decrypted, uncompressed, assembled (e.g., linked) if necessary, and compiled or interpreted (e.g., into a library, stand-alone executable etc.) at a local machine, and executed by the local machine.
The instructions 724 may be further transmitted or received over a communications network 726 using a transmission medium via the network interface device 720 utilizing any one of a number of transfer protocols (e.g., frame relay, internee protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a. packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface device 720 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 726. In an example, the network interface device 720 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine 700, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software. A transmission medium is a machine-readable medium.
Example 1 is an apparatus for passenger discomfort measurement, the apparatus comprising: a memory including instructions; and processing circuitry that, when in operation, is configured by the instructions to: obtain a set of biomechanical measurements of a passenger in a vehicle during a time period; select a subset of the biomechanical measurements that indicate distress of the passenger; determine a vehicle action that corresponds to the timer period of biomechanical measurements that indicate distress; and modify a future application of the vehicle action based on the determination that the vehicle action corresponded to passenger distress.
In Example 2, the subject matter of Example 1 includes, wherein, to obtain the set of biomechanical measurements, the processing circuitry is configured to retrieve a biomechanical measurement from a device of the passenger.
In Example 3, the subject matter of Example 2 includes, wherein the device of the passenger is a wearable device.
In Example 4, the subject matter of Examples 1-3 includes, wherein, to obtain the set of biomechanical measurements, the processing circuitry is configured to use a sensor mounted in the vehicle to observe the passenger.
In Example 5, the subject matter of Example 4 includes, wherein the sensor is a camera.
In Example 6, the subject matter of Example 5 includes, wherein facial expressions are captured as biomechanical measurements.
In Example 7, the subject matter of Examples 4-6 includes, wherein the sensor is a microphone.
In Example 8, the subject matter of Example 7 includes, wherein vocal utterances of passenger are captured as biomechanical measurements.
In Example 9, the subject matter of Examples 1-8 includes, wherein the vehicle action includes an acceleration in a longitudinal, lateral, or vertical direction with respect to the vehicle.
In Example 10, the subject matter of Example 9 includes, wherein, to modify the future application of the vehicle action, the processing circuitry is configured to reduce the acceleration.
In Example 11, the subject matter of Example 10 includes, wherein the acceleration is based on a route traveled by the vehicle, and wherein, to reduce the acceleration, the processing circuitry is configured to select a different route.
In Example 12, the subject matter of Examples 1-11 includes, wherein, to modify the future application of the vehicle action, the processing circuitry is configured to modify a parameter of the vehicle action for a current trip of the passenger.
In Example 13, the subject matter of Examples 1-12 includes, wherein, to modify the future application of the vehicle action, the processing circuitry is configured to modify a parameter of the vehicle action for a future trip of the passenger.
In Example 14, the subject matter of Examples 1-13 includes, wherein to modify the future application of the vehicle action, the processing circuitry is configured to modify a parameter of the vehicle action for a different passenger.
In Example 15, the subject matter of Examples 1-14 includes, wherein, to modify the future application of the vehicle action, the processing circuitry is configured to: collect instances of distress across passengers with respect to the vehicle action; and change a parameter of the vehicle action in response passing a statistical threshold with respect to the instances of distress.
In Example 16, the subject matter of Example 15 includes, wherein, to collect instances of distress across passengers, the processing circuitry is configured to transmit the set of biomechanical measurements to a server that correlates distress among passengers from several vehicles over several trips using the statistical threshold, the distress corresponding to vehicle maneuvers or route segments; and wherein, to change the parameter of the vehicle action in responses to passing the statistical threshold, the processing circuitry is configured to receive, the parameter from the server with regard to the maneuver or a route segment,
Example 17 is a method for passenger discomfort measurement, the method comprising: obtaining a set of biomechanical measurements of a passenger in a vehicle during a time period; selecting a subset of biomechanical measurements that indicate distress of the passenger; determining a vehicle action that corresponds to the time period of biomechanical measurements that indicate distress; and modifying a future application of the vehicle action based on the determination that the vehicle action corresponded to passenger distress.
In Example 18, the subject matter of Example 17 includes, wherein obtaining the set of biomechanical measurements includes retrieving a biomechanical measurement from a device of the passenger.
In Example 19, the subject matter of Example 18 includes, wherein the device of the passenger is a wearable device.
In Example 20, the subject matter of Examples 17-19 includes, wherein obtaining the set of biomechanical measurements includes using a sensor mounted in the vehicle to observe the passenger.
In Example 21, the subject matter of Example 20 includes, wherein the sensor is a camera.
In Example 22, the subject matter of Example 21 includes, wherein facial expressions are captured as biomechanical measurements.
In Example 23, the subject matter of Examples 20-22 includes, wherein the sensor is a microphone.
In Example 24, the subject matter of Example 23 includes, wherein vocal utterances of passenger are captured as biomechanical measurements.
In Example 25, the subject matter of Examples 17-24 includes, wherein the vehicle action includes an acceleration in a longitudinal, lateral, or vertical direction with respect to the vehicle.
In Example 26, the subject matter of Example 25 includes, wherein modifying a future application of the vehicle action includes reducing the acceleration.
In Example 27, the subject matter of Example 26 includes, wherein the acceleration is based on a route traveled by the vehicle, and wherein reducing the acceleration includes selecting a different route.
In Example 28, the subject matter of Examples 17-27 includes, wherein modifying the future application of the vehicle action includes modifying a parameter of the vehicle action for a current trip of the passenger.
In Example 29, the subject matter of Examples 17-28 includes, wherein modifying the future application of the vehicle action includes modifying a parameter of the vehicle action for a future trip of the passenger.
In Example 30, the subject matter of Examples 17-29 includes, wherein modifying the future application of the vehicle action includes modifying a parameter of the vehicle action for a different passenger.
In Example 31, the subject matter of Examples 17-30 includes, wherein modifying the future application of the vehicle action includes: collecting instances of distress across passengers with respect to the vehicle action; and changing a parameter of the vehicle action in response passing a statistical threshold with respect to the instances of distress.
In Example 32, the subject matter of Example 31 includes, wherein collecting instances of distress across passengers includes transmitting the set of biomechanical measurements to a server that correlates distress among passengers from several vehicles over several trips using the statistical threshold, the distress corresponding to vehicle maneuvers or route segments; and wherein changing the parameter of the vehicle action in responses to passing the statistical threshold includes receiving the parameter from the server with regard to the maneuver or a route segment.
Example 33 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations comprising: obtaining a set of biomechanical measurements of a passenger in a vehicle during a time period; selecting a subset of biomechanical measurements that indicate distress of the passenger; determining a vehicle action that corresponds to the time period of biomechanical measurements that indicate distress; and modifying a future application of the vehicle action based on the determination that the vehicle action corresponded to passenger distress.
In Example 34, the subject matter of Example 33 includes, wherein obtaining the set of biomechanical measurements includes retrieving a biomechanical measurement from a device of the passenger.
In Example 35, the subject matter of Example 34 includes, wherein the device of the passenger is a wearable device.
In Example 36, the subject matter of Examples 33-35 includes, wherein obtaining the set of biomechanical measurements includes using a sensor mounted in the vehicle to observe the passenger.
In Example 37, the subject matter of Example 36 includes, wherein the sensor is a camera.
In Example 38, the subject matter of Example 37 includes, wherein facial expressions are captured as biomechanical measurements.
In Example 39, the subject matter of Examples 36-38 includes, wherein the sensor is a microphone.
In Example 40, the subject matter of Example 39 includes, wherein vocal utterances of passenger are captured as biomechanical measurements.
In Example 41, the subject matter of Examples 33-40 includes, wherein the vehicle action includes an acceleration in a longitudinal, lateral or vertical direction with respect to the vehicle.
In Example 42, the subject matter of Example 41 includes, wherein modifying a future application of the vehicle action includes reducing the acceleration.
In Example 43, the subject matter of Example 42 includes, wherein the acceleration is based on a route traveled by the vehicle, and wherein reducing the acceleration includes selecting a different route.
In Example 44, the subject matter of Examples 33-43 includes, wherein modifying the future application of the vehicle action includes modifying a parameter of the vehicle action for a current trip of the passenger.
In Example 45, the subject matter of Examples 33-44 includes, wherein modifying the future appl.ication of the vehicle action includes modifying a parameter of the vehicle action for a future trip of the passenger.
In Example 46, the subject matter of Examples 33-45 includes, wherein modifying the future application of the vehicle action includes modifying a parameter of the vehicle action for a different passenger.
In Example 47, the subject matter of Examples 33-46 includes, wherein modifying the future application of the vehicle action includes: collecting instances of distress across passengers with respect to the vehicle action; and changing a parameter of the vehicle action in response passing a statistical threshold with respect to the instances of distress.
In Example 48, the subject matter of Example 47 includes, wherein collecting instances of distress across passengers includes transmitting the set of biomechanical measurements to a server that correlates distress among passengers from several vehicles over several trips using the statistical threshold, the distress corresponding to vehicle maneuvers or route segments; and wherein changing the parameter of the vehicle action in responses to passing the statistical threshold includes receiving the parameter from the server with regard to the maneuver or a route segment.
Example 49 is a system for passenger discomfort measurement, the system comprising: means for obtaining a set of biomechanical measurements of a passenger in a vehicle during a time period; means for selecting a subset of biomechanical measurements that indicate distress of the passenger; means for determining a vehicle action that corresponds to the time period of biomechanical measurements that indicate distress; and means for modifying a future application of the vehicle action based on the determination that the vehicle action corresponded to passenger distress.
In Example 50, the subject matter of Example 49 includes, wherein the means for obtaining the set of biomechanical measurements include means for retrieving a biomechanical measurement from a device of the passenger.
In Example 51, the subject matter of Example 50 includes, wherein the device of the passenger is a wrist-worn device.
In Example 52, the subject matter of Examples 49-51 includes, wherein the means for obtaining the set of biomechanical Measurements include means for using a sensor mounted in the vehicle to observe the passenger.
In Example 53, the subject matter of Example 52 includes, wherein the sensor is a camera.
In Example 54, the subject matter of Example 53 includes, wherein facial expressions are captured as biomechanical measurements.
In Example 55, the subject matter of Examples 52-54 includes, wherein the sensor is a microphone.
In Example 56, the subject matter of Example 55 includes, wherein vocal utterances of passenger are captured as biomechanical measurements.
In Example 57, the subject matter of Examples 49-56 includes, wherein the vehicle action includes an acceleration in a longitudinal, lateral, or vertical direction with respect to the vehicle.
In Example 58, the subject matter of Example 57 includes, wherein the means for modifying a future application of the vehicle action include means for reducing the acceleration.
In Example 59, the subject matter of Example 58 includes, wherein the acceleration is based on a route traveled by the vehicle, and wherein the means for reducing the acceleration include means for selecting a different route.
In Example 60, the subject matter of Examples 49-59 includes, wherein the means for modifying the future application of the vehicle action include means for modifying a parameter of the vehicle action for a current trip of the passenger.
In Example 61, the subject matter of Examples 49-60 includes, wherein means for modifying the future application of the vehicle action include means for modifying a parameter of the vehicle action for a future trip of the passenger.
In Example 62, the subject matter of Examples 49-61 includes, wherein means for modifying the future application of the vehicle action include means for modifying a parameter of the vehicle action for a different passenger.
In Example 63, the subject matter of Examples 49-62 includes, wherein the means for modifying the future application of the vehicle action include: means for collecting instances of distress across passengers with respect to the vehicle action; and means for changing a parameter of the vehicle action in response passing a statistical threshold with respect to the instances of distress.
In Example 64, the subject matter of Example 63 includes, the means for wherein collecting instances of distress across passengers include means for transmitting the set of biomechanical measurements to a server that correlates distress among passengers from several vehicles over several trips using the statistical threshold, the distress corresponding to vehicle maneuvers or route segments; and wherein the means for changing the parameter of the vehicle action in responses to passing the statistical threshold include means for receiving the parameter from the server with regard to the maneuver or a route segment.
Example 65 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement of any of Examples 1-64.
Example 66 is an apparatus comprising means to implement of any of Examples 1-64.
Example 67 is a system to implement of any of Examples 1-64.
Example 68 is a method to implement of any of Examples 1-64.
The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as “examples.” Such examples may include elements in addition to those shown or described. However, the present inventors also contemplate examples in which only those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.
All publications, patents, and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) should be considered supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.
In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second.” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.
The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments may be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is to allow the reader to quickly ascertain the nature of the technical disclosure and is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure.
This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its Own as a separate embodiment. The scope of the embodiments should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
