WO2017030574A1

WO2017030574A1 - Wearable in-vehicle bladder detection

Info

Publication number: WO2017030574A1
Application number: PCT/US2015/045818
Authority: WO
Inventors: Dylan Verster; Ali Hassani; Gary Steven Strumolo; Pramita Mitra; David Melcher; Mark A. CUDDIHY; Craig John SIMONDS
Original assignee: Ford Global Technologies, Llc
Priority date: 2015-08-19
Filing date: 2015-08-19
Publication date: 2017-02-23

Abstract

A wearable sensor provides a measurement of an amount of liquid in a vehicle occupant' s bladder. Using the measurement, a determination is made of a predicted percentage of fullness of the occupant's bladder. The predicted bladder fullness to at least one of a human-machine interface of an in-vehicle computer and a mobile user device.

Description

WEARABLE IN-VEHICLE BLADDER DETECTION

BACKGROUND

[0001] Land-based passenger vehicles, apart from large commercial vehicles such as buses, typically lack restrooms. Thus, longer trips, especially involving multiple people, and especially where some of those people are very old or very young, can require multiple stops for use of restroom facilities. Even when necessary, the stops may be inefficient, and may unduly increase overall trip time. Further, stops may be made unnecessarily, e.g., to accommodate a vehicle passenger who in fact does not have an urgent need for a restroom. Unfortunately, vehicle passengers such as small children do not, and sometimes cannot, accurately communicate a level of need for a restroom.

DRAWINGS

[0002] Figure 1 is a block diagram of an exemplary in- vehicle bladder detection system.

[0003] Figure 2 is a view of a vehicle interior showing use of a bladder detection sensor in the system of Figure 1.

[0004] Figure 3 is a diagram of an exemplary process for predicting a degree of bladder fullness in a vehicle passenger.

[0005] Figure 4 is a diagram of another exemplary process for predicting a degree of bladder fullness in a vehicle passenger.

DESCRIPTION

INTRODUCTION

[0006] Figure 1 is a block diagram of an exemplary in- vehicle bladder detection system 100. A vehicle 101 includes a computer 105 that receives data from a wearable sensor 110 that is worn by a vehicle 101 passenger. The wearable sensor 110 is typically an ultrasonic sensor or the like, such as is known for various uses, including making measurements that may be used to determine a degree of fullness of a person's bladder. The computer 105 uses the data from the wearable sensor 110 to predict a degree of fullness of the bladder of the person wearing the sensor 110 (sometimes referred to herein as "the subject passenger"). The computer 105 may further provide the predicted degree of bladder fullness for display on a vehicle 101 human machine interface (HMI) 115, to a user device 150 such as a smart phone or the like, etc. Further, the computer 105 may make adjustments to vehicle operations based on the prediction, e.g., may alter a vehicle 101 route and/or provide recommended waypoints on a vehicle 101 route based on the predicted need of a vehicle 101 passenger for restroom facilities.

EXEMPLARY SYSTEM ELEMENTS

[0007] The vehicle 101 includes a vehicle computer 105 that includes a processor and a memory, the memory including one or more forms of

computer-readable media, and storing instructions executable by the processor for performing various operations, including as disclosed herein. For example, the computer 105 generally includes, and is capable of executing, instructions to predict a level of fullness of a bladder of a vehicle 101 passenger wearing the wearable sensor 110, to provide the prediction to the HMI 115, the user device 150, etc., to provide the prediction to a vehicle 101 navigation system for computation of waypoints and/or a new vehicle 101 route based on the prediction, etc.

[0008] The computer 105 is configured for communicating with one or more servers 125 and/or one or more portable user devices 150, via the network 120, which, as described below, may include various wired and/or wireless networking technologies, e.g., cellular, Bluetooth, wired and/or wireless packet networks, etc. Further, the computer 105 generally includes instructions for receiving data, e.g., from one or more wearable bladder sensors 110 and/or the human machine interface (HMI) 115, which may be one or more of an interactive voice response (IVR) system, a graphical user interface (GUI) including a touchscreen or the like, etc.

[0009] The sensor 110 is typically an ultrasonic sensor such as is known for detecting urinary retention, i.e., a degree of fullness of a person's bladder. The sensor 110 is generally provided with an attachment mechanism, e.g., a belt or the like, for fixing the sensor 110 to a vehicle 101 passenger. Given the size of a person's bladder and the high contrast of liquid versus soft tissue, the sensor 110 may need to move not at all, or only a few degrees (e.g., a few millimeters of travel over a person's body) for proper resolution and adequate measurements. To accomplish any necessary movement, the sensor 110 could include a calibrated actuator that changes its focal point over time, and moreover the sensor could be integrated into a seat manifold and/or a seatbelt including such an actuator.

Through use of adaptive learning, mentioned below, the computer 105 could improve and refine movements and placement of the sensor 110 for a particular vehicle 101 passenger. Further, the sensor 110 may include or be coupled to a communications mechanism, e.g., a transceiver operating according to a protocol such as Bluetooth, for communications with the vehicle 101 computer 105.

[00010] The network 120 represents one or more mechanisms by which a vehicle computer 105 may communicate with a server 125 and/or a user device 150. Accordingly, the network 120 may be one or more of various wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber) and/or wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms and any desired network topology (or topologies when multiple communication mechanisms are utilized). Exemplary communication networks include wireless communication networks (e.g., using Bluetooth, IEEE 802.11, etc.), local area networks (LAN) and/or wide area networks (WAN), including the Internet, providing data communication services.

[00011] The server 125 may be one or more computer servers, each generally including at least one processor and at least one memory, the memory storing instructions executable by the processor, including instructions for carrying out various steps and processes described herein. In general, the server 125 may be used for a variety of purposes, e.g., interacting with a vehicle 101 navigational system, providing data used for suggesting a vehicle 101 route and/or attributes thereof. The server 125 may include or be communicatively coupled to a data store 130 for storing data such as route information, potential waypoints including restroom facilities, etc. Thus, one possible operation of the server 125 in the system 100 is to receive an indication from a vehicle 101 computer 105 via the network 120 that a vehicle 101 passenger's bladder has a degree of fullness over a threshold value, that the vehicle 101 passenger is in need of a restroom within a specified amount of time, etc., and then to suggest waypoints to accommodate the need of the vehicle 101 passenger.

[00012] A user device 150, typically a mobile device carried by a user, may be any one of a variety of computing devices including a processor and a memory, as well as communication capabilities. For example, the user device 150 may be a portable computer, tablet computer, a smart phone, etc. that includes capabilities for wireless communications using IEEE 802.11, Bluetooth, and/or cellular communications protocols. Further, the user device 150 may use such communication capabilities to communicate via the network 120 including with a vehicle computer 105. A user device 150 could communicate with a vehicle 101 computer 105 the other mechanisms, such as a network in the vehicle 101, a known protocols such as Bluetooth, etc. Accordingly, a user device 150 may be used to carry out some of all operations herein ascribed to the computer 105, e.g., receiving data from a sensor 110, making a determination of bladder fullness, and providing the determination via a user interface of the user device 150. Further, a user device 150 could be used to supplement and/or replace the HMI 115 of the computer 105.

[00013] As seen in Figure 2, a vehicle 101 passenger may wear the wearable sensor 110. The sensor 110 is generally affixed to the passenger so as to rest against the passenger's abdomen, and may be worn under the passenger's clothing to facilitate ultrasonic scanning. The vehicle 101 HMI 115 displays the predicted level of fullness of the passenger's bladder.

EXEMPLARY PROCESS FLOWS

[00014] Figure 3 is a diagram of an exemplary process 300 for predicting a degree of bladder fullness in a vehicle passenger. [00015] The process 300 begins in a block 305, in which the computer 105 initiates measurements by the sensor 110. For example, a user could provide input from a device 152 the computer 105, e.g., via a smart phone app or the like, to initiate measurements in the sensor 110. Alternatively or additionally, the computer 105 could be programmed to periodically, e.g., every minute, every five minutes, etc., initiate measurements in the sensor 110. Initiating measurements in the sensor 110 could include providing a communication from the computer 105 to the sensor 110 to provide a measurement of an amount of detected liquid in a person's bladder, e.g., such measurement being taken in a known manner.

Further, the block 305 could include providing an identification of the subject passenger to the computer 105 and/or receiving input concerning and/or retrieving parameters relating to the subject passenger, such parameters provided for greater accuracy in assessing bladder fullness as described in more detail below.

[00016] Next, in a block 310, the computer 105 receives data from the sensor 110, e.g., indicating an amount of liquid in a person's bladder.

[00017] Next, in a block 315, the computer 105 determines whether it has received a query from a user, e.g., from a user device 150, to provide an indication of the subject passenger's bladder fullness.

[00018] Next, in a block 320, the computer 105 assesses the subject passenger's bladder fullness. For example, the computer 105 may be used to use Gaussian models or other known models and/or equations of bladder fullness as is known to provide an estimate of bladder fullness. For example, a predicted bladder fullness may be expressed in terms of a percentage, e.g., eighty percent full. The model of bladder fullness may use such parameters as the subject passenger' s age, gender, height, and/or weight. Such parameters may be provided to the vehicle computer 105, e.g., via the HMI 115 and/or a user device 150, by a user, and may be stored in the computer 105 memory. Additionally or alternatively, such parameters for a subject passenger could be stored in the server 125 data store 130, and could be retrieved by the computer 105 according to an identifier for the subject passenger. Whether stored locally on the computer 105 or remotely at the server 125 such parameters could be used to dynamically improve prediction performance of a stochastic model.

[00019] Next, in a block 325, the computer 105 may provide the assessment to the HMI 115, a user device 150, etc. the computer 105 may also provide the assessment to the server 125, where may be stored in the data store 130. A user, e.g., via the computer 105 or a user device 150, could provide further input to be provided to the server 125 to allow for adaptive learning and refinement with respect to a particular subject passenger or calculations of bladder fullness more generally. Accordingly, the computer 105 may receive updates of one or more models, e.g., a plurality of models corresponding to different parameters, form the server 125, and/or may be programmed to make such updates. Further, as mentioned above, the assessment of bladder fullness of the subject passenger made in the block 320 may be used as a basis for vehicle 101 operations. For example, if the assessment is at or above a threshold level, e.g., 80 percent, the vehicle computer 105 may request that a vehicle 101 navigation system provide a route, or modify an existing route, to indicate one or more waypoints having restroom facilities based on the detected need of the subject passenger.

[00020] Next, in a block 330, the computer 105 determines whether the process 300 is to continue. For example, a user could provide input stopping measurements from the sensor 110, the computer 105 could detect that the sensor 110 has been removed from the subject passenger, etc. alternatively or additionally, the process 300 may not continue if the vehicle 101, including the computer 105, is powered off and/or stopped. In any case, if the process 300 continues, the block 310 is executed. Otherwise, the process 300 ends following the block 330.

[00021] Figure 4 is a diagram of another exemplary process 400 for predicting a degree of bladder fullness in a vehicle passenger. The process 400 begins in a block 405, which is similar to the block 305. Further, a block 410, following the block 405, is likewise similar to the block 310 described above.

[00022] In a block 420, following the block 410, the computer 105, in a manner similar to that described above with respect to the block 320, makes an assessment of bladder fullness of the subject passenger. For example, the computer 105, instead of making the assessment in response to a query as described above with respect to the process 300, could make the bladder fullness assessment periodically, e.g., every five minutes, every 10 minutes, etc.

[00023] Next, in a block 422, the computer 105 determines whether the assessed bladder fullness level of the block 420 exceeds a predetermined threshold, e.g., 80 percent. If so, then a block 425 is executed next. Otherwise, the process 400 proceeds to a block 430.

[00024] In a block 425, which may follow the block 422, the computer 105 provides the assessment of the block 422, e.g., in a manner similar to that described above with respect to the block 325. The process 400 and proceeds to the block 430.

[00025] In the block 430, in a manner similar to that described above with respect to the block 330, it is determined whether the process 400 continues. If so, then the block 410 is executed next. Otherwise, the process 400 ends.

CONCLUSION

[00026] As used herein, the adverb "substantially" means that a shape, structure, measurement, quantity, time, etc. may deviate from an exact described geometry, distance, measurement, quantity, time, etc., because of imperfections in materials, machining, manufacturing, etc.

[00027] The term "exemplary" is used herein in the sense of signifying an example, e.g., a reference to an "exemplary widget" should be read as simply referring to an example of a widget.

[00028] Computing devices such as those discussed herein generally each include instructions executable by one or more computing devices such as those identified above, and for carrying out blocks or steps of processes described above. For example, process blocks discussed above are embodied as

computer-executable instructions.

[00029] Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java™, C, C++, Visual Basic, Java Script, Perl, HTML, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media. A file in a computing device is generally a collection of data stored on a computer readable medium, such as a storage medium, a random access memory, etc.

[00030] A computer-readable medium includes any medium that participates in providing data (e.g., instructions), which may be read by a computer. Such a medium may take many forms, including, but not limited to, non- volatile media, volatile media, etc. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes a main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.

[00031] In the drawings, the same reference numbers indicate the same elements. Further, some or all of these elements could be changed. With regard to the media, processes, systems, methods, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claimed invention.

[00032] Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent to those of skill in the art upon reading the above description. The scope of the invention should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the arts discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the invention is capable of modification and variation and is limited only by the following claims.

[00033] All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those skilled in the art unless an explicit indication to the contrary in made herein. In particular, use of the singular articles such as "a," "the," "said," etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.

Claims

1. A system for a vehicle, comprising:

a wearable sensor that is configured to be affixed to a person occupying a vehicle seat to provide a measurement of an amount of liquid in the person's bladder; and

an in- vehicle computer that includes a processor and a memory, the memory storing instructions executable by the computer such that the computer is programmed to:

receive the measurement of an amount of liquid in a vehicle occupant's bladder from a wearable sensor;

determine, using the measurement, a predicted percentage of fullness of the occupant's bladder; and

provide the predicted bladder fullness to at least one of a human-machine interface of the in- vehicle computer and a mobile user device.

2. The system of claim 1, wherein the computer is further programmed to retrieve from the memory a parameter governing determining the predicted bladder fullness, and to use the parameter in determining the predicted bladder fullness.

3. The system of claim 1, wherein the computer is further programmed to determine whether the predicted bladder fullness exceeds a threshold, and to make a request to a vehicle navigation system for waypoints including restrooms if the predicted bladder fullness exceeds the threshold.

4. The system of claim 1, wherein the computer is further programmed to determine whether the predicted bladder fullness exceeds a threshold, and to provide the predicted bladder fullness to at least one of a human-machine interface of the in- vehicle computer and a mobile user device only if the threshold is exceeded.

5. The system of claim 1, wherein the computer is further programmed to provide the predicted bladder fullness to a remote server.

6. The system of claim 1, wherein the determination of predicted bladder fullness is made using a Gaussian distribution.

7. The system of claim 1, wherein the determination of predicted bladder fullness is made using a model provided from a remote server.

8. A system for a vehicle, comprising an in-vehicle computer that includes a processor and a memory, the memory storing instructions executable by the computer such that the computer is programmed to:

receive a measurement of an amount of liquid in a vehicle occupant's bladder from a wearable sensor;

determine, using the measurement; a predicted percentage of fullness of the occupant's bladder; and

provide the predicted bladder fullness to at least one of a human-machine interface of the in-vehicle computer and a mobile user device.

9. A method, comprising:

receiving a measurement of an amount of liquid in a vehicle occupant's bladder from a wearable sensor;

determining, using the measurement, a predicted percentage of fullness of the occupant's bladder; and

providing the predicted bladder fullness to at least one of a

human-machine interface of an in-vehicle computer and a mobile user device.

10. The method of claim 9, further comprising retrieving a parameter governing determining the predicted bladder fullness, and using the parameter in determining the predicted bladder fullness.

11. The method of claim 9, further comprising determining whether the predicted bladder fullness exceeds a threshold, and making a request to a vehicle navigation system for waypoints including restrooms if the predicted bladder fullness exceeds the threshold.

12. The method of claim 9, further comprising determining whether the predicted bladder fullness exceeds a threshold, and providing the predicted bladder fullness to at least one of a human-machine interface of the in-vehicle computer and a mobile user device only if the threshold is exceeded.

13. The method of claim 9, further comprising providing the predicted bladder fullness to a remote server.

14. The method of claim 9, wherein the determination of predicted bladder fullness is made using a Gaussian distribution.

15. The method of claim 9, wherein the determination of predicted bladder fullness is made using a model provided from a remote server.