阅读说明：本技术 车辆乘员检测 (Vehicle occupant detection ) 是由 罗大威 卢建波 于 2017-08-11 设计创作，主要内容包括：一种车辆中的计算机,包括处理器和存储器,所述存储器存储可由所述处理器执行的指令。所述指令可以包括：接收车门微开的指示；从车辆中的旋转速率传感器接收传感器数据；以及基于所述指示和传感器数据来确定横穿事件。(A computer in a vehicle comprising a processor and a memory, the memory storing instructions executable by the processor. The instructions may include: receiving an indication that the vehicle door is ajar; receiving sensor data from a rotation rate sensor in a vehicle; and determining a crossing event based on the indication and the sensor data.)

1. A computer programmed to:

Receiving an indication that the vehicle door is ajar;

Receiving sensor data from a rotation rate sensor in a vehicle; and

A crossing event is determined based on the indication and the sensor data.

2. The computer of claim 1, wherein the indication comprises sensor data received via another sensor located at the door.

3. The computer of claim 1, wherein the indication is received from a body control module coupled to a plurality of door ajar sensors, wherein each door ajar sensor is associated with one of a plurality of vehicle doors.

4. the computer of claim 1, wherein the data is received by the computer in response to the indication.

5. The computer of claim 1, wherein the computer is further programmed to determine a window of interest with respect to the sensor data, wherein the window of interest is defined by a time interval associated with when the vehicle door is ajar.

6. The computer of claim 5, wherein the computer is further programmed to determine a rotation indicator from the data, wherein the rotation indicator indicates the crossing event.

7. The computer of claim 6, wherein the computer is further programmed to determine the crossing event based on the rotation indicator being greater than a first threshold or less than a second threshold.

8. The computer of claim 5, wherein the computer is further programmed to ignore a rotation indicator indicating the crossing event from the data when the rotation indicator coincides with an endpoint of the window of interest or when the rotation indicator is within a threshold time interval of the endpoint.

9. The computer of claim 1 wherein the rotation rate sensor is positioned and oriented in the vehicle to measure a roll rate of the vehicle relative to a longitudinal axis thereof.

10. The computer of claim 1, wherein the computer is further programmed to: receiving sensor data from a second rate of rotation sensor and an accelerometer; and executing dynamic vehicle model instructions using sensor data from the first rate of rotation sensor, the second rate of rotation sensor, and the accelerometer.

11. The computer of claim 10, wherein the computer is further programmed to: determining a weight indicator using the model instructions; determining whether the weight indicator is greater than a threshold; and determining the crossing event when the weight indicator is greater than the threshold.

12. The computer of claim 10 wherein the first yaw rate sensor is positioned and oriented in the vehicle to measure a roll rate of the vehicle relative to its longitudinal axis, wherein the second yaw rate sensor is positioned and oriented in the vehicle to measure a pitch rate of the vehicle relative to its lateral axis, wherein the accelerometer is positioned and oriented in the vehicle to measure movement along a vertical axis of the vehicle.

13. The computer of claim 1, wherein the crossing event comprises one of an occupant entry event or an occupant exit event.

14. The computer of claim 1, wherein the computer is further programmed to increment or decrement a counter based on determining the crossing event, wherein the computer is programmed to increment the counter when the computer determines an occupant entry event, and wherein the computer is programmed to decrement the counter when the computer determines an occupant exit event.

15. The computer of claim 1, wherein the sensor is part of a roll stability control system in the vehicle.

16. A system, comprising:

A first rotation rate sensor, wherein the first rotation rate sensor is associated with a motion sensing system in a vehicle; and

A computer programmed to:

Receiving an indication that the vehicle door is ajar;

Receiving sensor data from the sensor; and

A crossing event is determined based on the indication and the sensor data.

17. The system of claim 16, further comprising a door ajar sensor associated with one of a plurality of vehicle doors, wherein the indication is received by the computer via the door ajar sensor.

18. The system of claim 16, wherein the computer is further programmed to determine a window of interest with respect to the sensor data, wherein the window of interest is defined by a time interval associated with when the door is ajar, wherein the computer is further programmed to determine a rotation indicator from the data, wherein the rotation indicator indicates the crossing event.

19. The system of claim 16, wherein the first rate of rotation sensor is positioned and oriented in the vehicle to measure a roll rate of the vehicle relative to its longitudinal axis, wherein the motion sensing system further comprises a second rate of rotation sensor and an accelerometer, wherein the second rate of rotation sensor is positioned and oriented in the vehicle to measure a pitch rate of the vehicle relative to its lateral axis, wherein the accelerometer is positioned and oriented in the vehicle to measure movement along a vertical axis of the vehicle.

20. The system of claim 19, wherein the computer is further programmed to: receiving sensor data from the second rotation rate sensor and the accelerometer; and executing dynamic vehicle model instructions using sensor data from the first rate of rotation sensor, the second rate of rotation sensor, and the accelerometer, wherein the computer is further programmed to: determining a weight indicator using the model instructions; determining whether the weight indicator is greater than a threshold; and determining the crossing event when the weight indicator is greater than the threshold.

Background

The vehicle occupancy sensor comprises a seat sensor, a seat belt sensor and a camera. For example, seat sensors may be embedded or integrated with a seat base or a seat back and detect weight, pressure, proximity, etc. The seat belt sensor may detect the locked condition based on a position of the seat belt clip relative to the seat belt buckle. Cameras and image processing software may be used to image the interior of the vehicle and determine whether an occupant is present.

Drawings

FIG. 1 is a schematic illustration of a vehicle having an occupant detection system including a computer and one or more sensors.

FIG. 2 is a perspective view of a vehicle showing a vehicle coordinate system.

FIG. 3 is a flow chart illustrating a process of determining an occupant crossing event.

Fig. 4-18 are graphical depictions of sensor data received by a computer from one or more sensors.

FIG. 19 is a model that may be used by a computer to determine an occupant crossing event.

Fig. 20-25 show the output from a computer when executing instructions associated with the model shown in fig. 19.

Detailed Description

An occupant detection system is described that includes a vehicle computer and one or more vehicle sensors. According to one illustrative example, a computer may be programmed to: receiving an indication that a door is ajar, receiving sensor data from a rotation rate sensor in the vehicle, determining a crossing event based on the indication and the sensor data.

According to at least one example of the foregoing, the indication includes sensor data received via another sensor located at the door.

According to at least one example of the foregoing, the indication is received from a body control module coupled to a plurality of door ajar sensors, wherein each door ajar sensor is associated with one of a plurality of vehicle doors.

According to at least one example of the foregoing, the data is received by the computer in response to the indication.

According to at least one example of the foregoing, the computer is further programmed to determine a window of interest with respect to the sensor data, wherein the window of interest is defined by a time interval associated with when the door is ajar.

According to at least one example of the foregoing, the computer is further programmed to determine a rotation indicator from the data, wherein the rotation indicator is indicative of the crossing event.

According to at least one example of the foregoing, the computer is further programmed to determine the crossing event based on the rotation indicator being greater than a first threshold or less than a second threshold.

According to at least one example of the foregoing, the computer is further programmed to ignore a rotation indicator indicative of the crossing event from the data when the rotation indicator coincides with an endpoint of the window of interest or when the rotation indicator is within a threshold time interval of the endpoint.

According to at least one example above, the yaw rate sensor is positioned and oriented in the vehicle to measure a roll rate of the vehicle relative to a longitudinal axis thereof.

According to at least one example of the foregoing, the computer is further programmed to: receiving sensor data from a second rate of rotation sensor and an accelerometer; and executing dynamic vehicle model instructions using sensor data from the first rate of rotation sensor, the second rate of rotation sensor, and the accelerometer.

according to at least one example of the foregoing, the computer is further programmed to: determining a weight indicator using the model instructions; determining whether the weight indicator is greater than a threshold; and determining the crossing event when the weight indicator is greater than the threshold.

According to at least one example of the foregoing, the first yaw rate sensor is positioned and oriented in the vehicle to measure a roll rate of the vehicle relative to its longitudinal axis, wherein the second yaw rate sensor is positioned and oriented in the vehicle to measure a pitch rate of the vehicle relative to its lateral axis, wherein the accelerometer is positioned and oriented in the vehicle to measure movement along a vertical axis of the vehicle.

According to at least one example of the foregoing, the crossing event includes one of an occupant entry event or an occupant exit event.

According to at least one example of the foregoing, the computer is further programmed to increment or decrement a counter based on determining the crossing event, wherein the computer is programmed to increment the counter when the computer determines an occupant entry event, and wherein the computer is programmed to decrement the counter when the computer determines an occupant exit event.

According to at least one example of the foregoing, wherein the sensor is part of a roll stability control system in the vehicle.

According to another illustrative example, a system comprises: a first rotation rate sensor, wherein the first rotation rate sensor is a motion sensing system in a vehicle; and a computer programmed to: receiving an indication that the vehicle door is ajar; receiving sensor data from the sensor; and determining a crossing event based on the indication and the sensor data.

According to at least one example of the foregoing, the system further includes a door ajar sensor associated with one of the plurality of vehicle doors, wherein the indication is received by the computer via the door ajar sensor.

According to at least one example of the foregoing, the computer is further programmed to determine a window of interest with respect to the sensor data, wherein the window of interest is defined by a time interval associated with when the door is ajar, wherein the computer is further programmed to determine a rotation indicator from the data, wherein the rotation indicator indicates the crossing event.

According to at least one example of the foregoing, the first rate of rotation sensor is positioned and oriented in the vehicle to measure a roll rate of the vehicle relative to its longitudinal axis, wherein the motion sensing system further comprises a second rate of rotation sensor and an accelerometer, wherein the second rate of rotation sensor is positioned and oriented in the vehicle to measure a pitch rate of the vehicle relative to its lateral axis, wherein the accelerometer is positioned and oriented in the vehicle to measure movement along a vertical axis of the vehicle.

according to at least one example of the foregoing, the computer is further programmed to: receiving sensor data from the second rotation rate sensor and the accelerometer; and executing dynamic vehicle model instructions using sensor data from the first rate of rotation sensor, the second rate of rotation sensor, and the accelerometer, wherein the computer is further programmed to: determining a weight indicator using the model instructions; determining whether the weight indicator is greater than a threshold; and determining the crossing event when the weight indicator is greater than the threshold.

According to at least one example, a computer programmed to perform any combination of the examples set forth above is disclosed.

According to at least one example, a computer-program product is disclosed that includes a computer-readable medium storing instructions executable by a computer processor, wherein the instructions include any combination of the examples of instructions set forth above.

Turning now to the drawings, wherein like numerals indicate like parts throughout the several views, there is shown an occupant detection system 10 for a vehicle 12 that includes a computer 14 that receives sensor data from a plurality of sensors (at least one of which is a rate of rotation sensor) and determines whether a user enters or exits a cabin 16 of the vehicle 12 based on the sensor data. The computer 14 may also use these signals to determine the number of occupants within the cabin 16. In at least one example, the sensors are part of an existing onboard motion sensing system 18; thus, the computer 14 may determine the entry and exit events (and the number of occupants in the vehicle 12) without significant changes or additional vehicle hardware. For example, the proposed occupant detection system 10 may utilize a set of instructions implemented in software, firmware, etc. to determine vehicle entry and exit events, thereby minimizing costs.

According to at least one example, the vehicle 12 may be an all-autonomous taxi that charges the passenger a taxi fee. The cost may be based at least in part on the number of occupants carried thereby and/or the distance traversed between the points carrying the occupants. For example, in a fully autonomous embodiment, the vehicle 12 may have neither a human driver nor a crew member traveling with the vehicle 12 (e.g., where the driver or crew member is present, the driver or crew member may determine the number of occupants, the total cost of taxi service, etc.). In a fully autonomous embodiment, computer 14 may be configured to perform such tasks. And as described below, computer 14 may be programmed to perform other suitable taxi functions.

In fig. 1-2, the vehicle 12 is shown as a passenger car; however, the vehicle 12 may also be a truck, Sport Utility Vehicle (SUV), recreational vehicle, other human vehicle, or the like that includes the occupant detection system 10. Further, the vehicle 12 may operate in any suitable number of autonomous modes. For example, the vehicle 12 may operate in a fully autonomous mode (e.g., with level 5 autonomy) defined by the Society of Automotive Engineers (SAE), which operates in a level 0 to level 5 definition. For example, on a level 0 to 2, a human driver typically monitors or controls most driving tasks without the assistance of the vehicle 12. For example, at level 0 ("no automation"), a human driver is responsible for all vehicle operations. At level 1 ("driver assist"), the vehicle 12 sometimes assists in steering, accelerating, or braking, but the driver is still responsible for the vast majority of vehicle control. At level 2 ("partially automated"), the vehicle 12 may control steering, acceleration, and braking without human interaction under certain conditions. On level 3 to 5, the vehicle 12 assumes more driving-related tasks. At level 3 ("conditional automation"), the vehicle 12 may handle steering, acceleration, and braking, as well as monitoring the driving environment in certain situations. However, level 3 may require occasional driver intervention. At level 4 ("highly automated"), the vehicle 12 may handle the same tasks as level 3, but without relying on the driver to intervene in certain driving patterns. At level 5 ("fully automated"), the vehicle 12 may handle all tasks without any driver intervention.

Computer 14 may be a single computer (or multiple computing devices-e.g., shared to other vehicle systems and/or subsystems). Computer 14 may include a processor or processing circuit 22 coupled to a memory 24. For example, processor 22 may be any type of device capable of processing electronic instructions, non-limiting examples of which include a microprocessor, microcontroller or controller, Application Specific Integrated Circuit (ASIC), and the like-to name a few examples. Generally, computer 14 may be programmed to execute instructions stored in digital form, which may be stored in memory 24, that cause computer 14 to, among other things, receive sensor data from one or more vehicle sensors; receiving an indication that the vehicle door is ajar; determining that a user is entering or exiting the vehicle 12 using at least some of the sensor data; updating a counter that tracks the number of occupants within the car 16; and the like.

Memory 24 may include any non-transitory computer-usable or readable medium of one or more storage devices or articles of manufacture. Exemplary non-transitory computer usable storage devices include conventional computer system RAM (random access memory), ROM (read only memory), EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), and any other volatile or non-volatile media. Non-volatile media includes, for example, optical or magnetic disks and other persistent memory. Volatile media includes Dynamic Random Access Memory (DRAM), which typically constitutes a main memory. As discussed above, the memory 24 may store one or more computer program products, which may be embodied as software, firmware, etc. (e.g., such as software applications).

According to one example, sensor data is received from motion sensing system 18. System 18 may be adapted to receive sensor data from one or more vehicle systems including, but not limited to, a roll stability control system, an electronic stability control system, an advanced stability control system, an inertial navigation system (e.g., for a fully autonomous vehicle), an anti-lock braking system, and the like, or combinations thereof. For example, the system 18 may detect a loss in roll stability of the vehicle (e.g., due to a sudden steering change at high speed), and in response to such detection, may automatically apply the vehicle brakes to counteract the roll of the vehicle. System 18 may include a first accelerometer 26, a second accelerometer 28, a third accelerometer 30, a first rate of rotation sensor 32 (e.g., a roll rate sensor), a second rate of rotation sensor 34 (e.g., a yaw rate sensor), a third rate of rotation sensor 36 (e.g., a pitch rate sensor), and the motion sensing computer described above. In some examples, all or some of the sensors 26-36 may be packaged into a common cluster (e.g., which includes a so-called Inertial Measurement Unit (IMU)). The locations of the sensors 26 through 36 may be distributed or within a centralized location of the vehicle 12. Regardless of whether the sensors 26-36 are implemented in a single device, the sensors may be aligned with a first vehicle axis (e.g., a marked axis 'x') (e.g., a longitudinal axis along a vehicle centerline), a second vehicle axis (e.g., a marked axis 'y' (e.g., a transverse axis) perpendicular to the x-axis and extending laterally or transversely through the vehicle 12), and a third vehicle axis (e.g., a marked axis 'z' (e.g., a vertical axis) perpendicular to the x-axis and the y-axis), respectively, extending along the length of the vehicle 12. According to one example, the origin of the longitudinal, lateral and vertical axes coincides with the Center of Gravity (CG) of the vehicle. However, this is not required (e.g., other origin positions are also possible).

The rotation rate sensor may be a sensor that provides an electrical, magnetic, optical, or other suitable output based on changes in rotational position (about an axis) per unit time. The rotation rate sensors 32 to 36 may be gyro sensors, piezoelectric sensors, etc. or any combination thereof. According to at least one example, rotation rate sensor 32 is positioned and oriented to provide an output related to rotation about or relative to the x-axis (e.g., roll about the x-axis). And according to at least one example, rotation rate sensor 34 is positioned and oriented to provide an output related to rotation about or relative to the z-axis (e.g., yaw about the z-axis). And according to at least one example, rotation rate sensor 36 is positioned and oriented to provide an output related to rotation about or relative to the y-axis (e.g., pitch about the y-axis). System 18 may include other sensors and devices not listed herein as well-for example, including but not limited to wheel speed sensors, steering angle sensors, etc., as are known in the art.

As shown in fig. 1-and for purposes of explanation only-a vehicle forward direction (e.g., along the x-axis) may be considered a positive direction, a vehicle rightward direction (e.g., along the y-axis) may be considered a negative direction, and a vehicle downward direction (e.g., along the z-axis) may be considered a negative direction. Also, for purposes of explanation only, when the vehicle left side 42 rolls upward and the vehicle right side 44 rolls downward, the rotation or roll with respect to the x-axis may be considered a roll in a positive direction. Similarly, for purposes of explanation only, when the vehicle front side 46 is pitched down and the vehicle rear side 48 is pitched up, the rotation or pitch along the y-axis may be considered to be moving in a positive direction.

As also shown in fig. 1, the occupant detection system 10 may have other components (in addition to the computer 14 and sensors 26-36) including, but not limited to, a vehicle network connection 100 and an electronic control module 110 (e.g., shown here as a Body Control Module (BCM)). Vehicle network connection 100 may include any suitable wired or wireless in-vehicle communication network that enables communication between electronic devices such as computer 14, system 18, body control module 110, and the like. In at least one example, the connection 100 includes one or more of a Controller Area Network (CAN) bus, an ethernet, a Local Interconnect Network (LIN), a fiber optic connection, and the like. Other examples also exist. For example, connection 100 may comprise one or more discrete wired or wireless connections, either alternatively or in combination with, for example, a CAN bus.

The body control module 110 may include a computing device having a processor and memory (not shown). The processor and memory of BCM110 may be similar to processor 22 and memory 24 described above, except that the memory of BCM110 may store instructions unique to BCM110 that, when executed by the processor of BCM110, cause BCM110 to perform at least some functions unique to BCM 110. Non-limiting examples of BCM functions include monitoring and/or controlling electronic accessories in the vehicle 12, such as power windows, power rear view mirrors, climate control systems, vehicle anti-theft systems, vehicle door locks, and the like. In at least one example, the BCM110 receives sensor data from one or more sensors 121, 122, 123, 124 located at each of the vehicle doors, and the sensor data indicates whether the respective door is at least partially in a ajar state. As will be explained in more detail below, when it is determined that one of the doors D1, D2, D3, D4 is ajar, the computer 14 may determine (using at least one of the sensors 26-36) whether an occupant is entering or exiting the vehicle 12. Doors D1-D4 are exemplary; in other examples, more or fewer doors may be used. The sensors 121-124 may be proximity sensors, touch sensors, imaging devices or any other suitable sensors that the BCM110, the computer 14, and/or another computing device may use to determine that the doors are ajar and/or sufficiently open to allow a crossing event (e.g., an event in which a user crosses in and out of the vehicle 12). Thus, as used herein, a crossing event includes at least one of an occupant entry event or an occupant exit event. As used herein, an occupant entry event is an event in which a vehicle user (e.g., a human) enters or boards the vehicle 12 (e.g., enters the cabin 16). And as used herein, an occupant exit event is an event in which a vehicle user (e.g., the same or a different human) exits or boards the vehicle 12 (e.g., leaves the cabin 16).

Further, in the above description, computer 14, BCM110, and system 18 are described as separate computing devices or systems, each coupled to each other via network connection 100; however, other examples exist. For example, in at least one example, the computer 14 and the BCM110 are integral to each other-e.g., are the same device. In other examples, computer 14 may include hardware and/or functionality of BCM110, system 18, or any combination thereof.

FIG. 3 illustrates a process 300 for using the occupant detection system 10 to determine whether a user is entering or exiting the vehicle 12. The process begins at block 310, where computer 14 receives digital and/or analog sensor data from one or more of vehicle sensors 26-36, 121-124. In at least one example, computer 14 may monitor sensor data from at least door ajar sensors 121-124, and when computer 14 receives an indication that at least one of doors D1-D4 is ajar, the computer may be triggered to monitor sensor data from one or more of sensors 26-36 to determine whether an occupant entry event and/or an occupant exit event has occurred or is occurring.

Thus, according to one example of block 310, computer 14 may receive sensor data from each of sensors 121-124. And in one example, a digital one ('1') or the like can indicate a state in which the corresponding door is ajar, while a digital zero ('0') or the like can indicate a state in which the corresponding door is closed. (of course, the reverse embodiment may be performed). To illustrate block 310, consider an example in which the sensor 121 (associated with the vehicle door D1) sends a number '1' to the computer 14 to indicate that the door D1 is ajar. Alternatively or in combination therewith, the sensors 121 may send the same signal to the BCM110, which BCM110 in turn communicates this status to the computer 14 via the network connection 100. (Note: hereinafter, sensors 26-36, 121-124 may be described as communicating directly with computer 14, where it will be understood that sensor data may pass through other modules and systems before reaching computer 14-including, for example, but not limited to, through BCM110 and/or system 18).

In block 320, the computer 14 may determine whether the status of one of the vehicle doors is ajar. Continuing with the above example, in block 320, computer 14 determines the status of door D1 as ajar based on sensor data (e.g., the number '1') from sensor 121. Thus, according to one example, process 300 proceeds to block 330. Alternatively, if in block 320 the computer 14 determines that the status of all doors D1-D4 is closed, the process 300 may loop back and repeat block 310-e.g., continue to receive sensor data as described above.

In block 330, computer 14 may monitor and/or receive sensor data from at least one of sensors 26-36, for example, based on the door ajar status determined in block 320. The sensor data may pass through any suitable filter, such as a low pass filter, for example (this may occur via a filtering circuit (not shown) in the computer 14 or via software, for example). Alternatively or in combination with the low pass filtering in block 330, such filtering may be performed in block 350 as described below.

continuing with the above example, in block 330, the computer 14 may monitor the sensor data from the roll rate sensor 32 when the door ajar signal (or indication thereof) is high (e.g., the digital '1'). The sensor data may indicate angular velocity with respect to an amount of time. Further, the sensor data may be monitored as it is received (e.g., so-called real-time monitoring), stored in memory 24 for subsequent computer processing, and the like. As described in more detail below, computer 14 may evaluate sensor data from sensors 32 to determine whether there are any Rotational Indicators (RIs). The Rotation Indicator (RI) may be an electrical signal peak (e.g., a current or voltage peak) that is indicative of a rotational input of the vehicle 12 (e.g., based on a rotational input to a gyro sensor, such as sensor 32, etc., as also discussed below)). Thus, the Rotation Indicator (RI) may include a measurable desired signal in a total electrical signal (e.g., the electrical signal received from the sensor 32), where the total electrical signal (filtered or otherwise) includes the desired signal plus a so-called noise floor-e.g., the desired signal may have an amplitude that is suitably greater than noise (e.g., having a signal-to-noise ratio of 2: 1, 3: 1, etc.).

For purposes of illustration only, fig. 4-8 include sensor data from the sensors 26-34 indicating that a user entered the vehicle 12 from the left (e.g., via the doors D1 or D3). More specifically, fig. 7 shows longitudinal acceleration data (received from sensor 26) along the x-axis, fig. 6 shows lateral acceleration data (received from sensor 28) along the y-axis, fig. 5 shows vertical acceleration data (received from sensor 30) along the z-axis, fig. 4 shows roll rate data (received from sensor 32) relative to the x-axis, and fig. 8 shows yaw rate data (received from sensor 34) relative to the z-axis. A Rotation Indicator (RI) (e.g., a voltage peak) is labeled in fig. 4 and 8. It will be appreciated that the axial acceleration data may also provide a corresponding Rotation Indicator (RI) as shown in fig. 5-7. In one example of block 330, the computer 14 may monitor and/or receive sensor data from only the sensors 32-e.g., measuring roll rate data along the vehicle longitudinal axis (x-axis). In other examples, computer 14 may use sensor data from more than one of sensors 26-36.

in block 340 following block 330, the computer 14 may re-determine the status of the vehicle door (e.g., the same door of block 320) -e.g., whether it remains ajar. Continuing with the above example, computer 14 may again determine whether the status of door D1 is ajar (e.g., whether the status is still a digital '1') based on sensor data from sensor 121. If computer 14 determines that the door remains ajar, computer 14 loops back and repeats block 330 (e.g., continues to receive and/or monitor sensor data, such as sensor data from sensor 32 or from sensor 32 and/or any combination of other sensors 26-30, 34-36). However, if the computer 14 determines that the status of the door D1 is closed (e.g., the number '0') based on the sensor data from the sensor 121, the process 300 proceeds to block 350.

When the computer does ultimately determine that the status of door D1 is closed, block 330 may cease receiving and/or monitoring, and computer 14 may identify a time interval or window of interest for the sensor data received and/or monitored in block 330. For example, the attention window may include sensor data collected from the beginning of the state of door D1 being ajar until the state of door D1 is determined to be closed. As explained above, it may be a continuous stream of analog data-or may also be sampled, filtered, etc. It should be appreciated that for purposes of the occupancy detection system 100, the computer 14 may reduce the likelihood of false positive crossing event determinations by disregarding sensor data from one or more of the sensors 26-36 when each of the vehicle doors D1-D4 is closed.

In block 350, computer 14 may determine that the likelihood of a crossing event is increased by determining whether at least one of the Rotation Indicators (RI) is greater than a first threshold (THR1) or less than a second threshold (THR2) during the window of interest. The thresholds THR1 and/or THR2 may be predetermined, stored in memory 24, and/or based on various criteria (e.g., such as vehicle criteria (e.g., vehicle make, model, suspension system, etc.) and/or vehicle user criteria (e.g., mass, size, etc.)). Further, the first and second thresholds THR1 and THR2 may be unique to a particular vehicle door-e.g., the THR1 of door D1 may be different from the THR1 of door D3 (or door D2 or door D4), and so on. Thus, in at least one example, the computer memory 24 stores a plurality of different first and second thresholds.

More specifically, in block 350, if the Rotation Indicator (RI) is greater than the threshold THR1 or less than the threshold THR2, the process 300 may proceed to block 390. If the Rotation Indicator (RI) associated with the attention window is not greater than the threshold THR1 or less than the threshold THR2 (or it is determined that no Rotation Indicator (RI) at all is in the attention window), the process 300 may loop back and repeat block 310. For example, the absence of any Rotation Indicator (RI) during the window of interest may indicate that doors D1-D4 have opened, but that no user has traversed the opening door.

Fig. 9-16 are examples showing rotation rate data 130 from the roll rate sensor 32 for different conditions during an exemplary window of interest (e.g., when the respective door state is indicated as ajar). In each figure, a digital signal 132 is shown, which is indicative of the window of interest (and which overlaps with rotation rate data 130). FIG. 9 shows rotation rate data associated with occupant entry via door D1 and a Rotation Indicator (RI) less than a second threshold THR 2. For illustrative purposes only, THR2 is here-0.30 volts (V) (however, any value suitably greater than system noise 134 (e.g., vehicle driveline noise) may be used instead for door D1 or any other vehicle door). FIG. 10 shows rotation rate data associated with occupant entry via door D2 and a Rotation Indicator (RI) greater than a first threshold THR 1. For illustrative purposes only, THR1 is here +0.30 volts (V) (however, any value suitably greater than system noise 134 may be used instead for door D2 or any other vehicle door). FIG. 11 shows rotation rate data associated with occupant entry via door D3 and a Rotation Indicator (RI) less than a second threshold THR 2. And FIG. 12 shows rotation rate data associated with occupant entry via door D4 and a Rotation Indicator (RI) greater than a first threshold THR 1. With respect to the rotation rate data shown in fig. 12, it should be noted that the Rotation Indicator (RI) may not be as unique as the Rotation Indicator (RI) shown in fig. 9-11 (e.g., the rotation indicator shown in fig. 12 may have a lower signal-to-noise ratio). During the validation test, which included collecting the sensor data shown in fig. 9-16, the vehicle seat inside door D4 was fitted with instrumentation that interfered with the entry of the test occupant; if the equipment is not so positioned, the SNR shown in FIG. 12 would be expected to be greater.

FIG. 13 shows rotation rate data associated with an occupant exiting via door D1 and a Rotation Indicator (RI) greater than a first threshold THR 1. FIG. 14 shows rotation rate data associated with an occupant exiting via door D2 and a Rotation Indicator (RI) less than a second threshold THR 2. FIG. 15 shows rotation rate data associated with an occupant exiting via door D3 and a Rotation Indicator (RI) greater than a first threshold THR 1. And FIG. 16 shows rotation rate data associated with an occupant exiting via door D4 and a Rotation Indicator (RI) less than a second threshold THR 2. Again, if the instrumentation is not positioned on the seat near door D4, it is expected that the SNR shown in fig. 16 may be greater.

An overview of exemplary scenarios that may be determined by computer 14 corresponding to fig. 9-16 is set forth below in table I. Accordingly, the computer 14 may use the respective door ajar signals (e.g., from the sensors 121-124), the attention window, the one or more Rotation Indicators (RI), and the first and second thresholds (THR1, THR2) to determine whether a crossing event is an entry event or an exit event.

TABLE I

fig. 17 and 18 show aspects of fig. 9 and 13, respectively, in more detail. For example, fig. 17 shows sensor data of the sensor 32 before and after a window of interest (WOI). Further, fig. 17 shows at least one Rotation Indicator (RI) that computer 14 should ignore, e.g., based on its proximity and/or coincidence with a start endpoint 136 (of the WOI) and/or a stop endpoint 138 (of the WOI). That is, computer 14 may be programmed with instructions to ignore Rotation Indicators (RIs) outside of the window of interest (WOI) (e.g., before starting endpoint 136 and after terminating endpoint 138) and Rotation Indicators (RIs) that occur within its threshold time interval. For example, the Rotation Indicator (RI) near termination point 138 (in fig. 17) may be a result of door D1 moving to the closed position. Thus, while the sensor data of the sensor 32 may have a resolution suitable for determining a rate of rotation associated with the weight of an occupant entering and/or exiting the vehicle 12, it may also be suitably sensitive to detecting impacts and/or other forces applied to the vehicle 12 (such as closing a door). The threshold time interval may be +/-0.5 seconds of either of the endpoints 136, 138; of course, this is merely an example; other interval values less than or greater than 0.5 seconds may alternatively be used.

Fig. 18 depicts similar information (as shown in fig. 17) except that the sensor data is related to the occupant exiting the vehicle 12 via the door D1 (e.g., see fig. 13 and the above explanation). Again, Rotation Indicators (RIs) determined by computer 14 to be outside of the window of interest (WOI) and/or within a threshold time interval of endpoints 136, 138 may be ignored. Although not shown in fig. 17-18, sensor data may be received by the computer 14 that includes instances of multiple Rotation Indicators (RIs) occurring within a single window of interest (WOI) -where two or more occupants have entered the vehicle 12 during the window, or where two or more occupants have exited the vehicle 12 during the window, or where one or more occupants have entered during the window and also one or more occupants have exited, etc. By counting the Rotation Indicators (RI) that are greater than the first threshold (THR1) and less than the second threshold (THR2) (e.g., as shown in table I), the computer 14 may determine the number of occupants within the vehicle 12 at any given time, as will be explained below.

Before describing an example of block 390 in process 300 (fig. 3), block 360 will be described. In at least one example, block 360 may also follow block 320 (e.g., after computer 14 determines that the door is ajar). Thus, the instructions associated with blocks 360-380 may occur at least partially concurrently with respect to execution of the instructions associated with blocks 330-350.

block 360 may be similar to block 330 described above; therefore, a detailed description thereof will not be given. In at least one example of block 360, computer 14 receives data from at least sensor 30 (e.g., measuring motion along the z-axis), sensor 32 (e.g., measuring roll rate relative to the x-axis), and sensor 36 (e.g., measuring pitch rate relative to the y-axis). In other examples, sensor data from any combination of other sensors (e.g., sensors 26, 28, or 34) may also be used.

After block 360, the process 300 proceeds to block 370. In at least one example, block 370 may be the same as block 340; therefore, a renewed description will not be made here. When computer 14 determines in block 370 that the door (e.g., door D1) is no longer ajar, the process proceeds to block 380. When block 370 determines that the door of block 320 (e.g., D1) remains ajar, process 300 may loop back and repeat block 360 (e.g., continue to receive and/or monitor any combined sensor data, e.g., from sensors 30-36).

In block 380, computer 14 determines whether the Weight Indicator (WI) is greater than a third threshold (THR 3); this will be described in detail below. The Weight Indicator (WI) may be associated with the weight of an occupant entering or exiting the vehicle 12. Since the occupant (or vehicle user) may assume a minimum or threshold weight, a Weight Indicator (WI) may be used in one example to mitigate false positive determinations of crossing events. For example, if the Weight Indicator (WI) exceeds the threshold (THR3), the process 300 proceeds to block 390. If the Weight Indicator (WI) is less than or equal to the third threshold (THR3), the process 300 may loop back and repeat the process 300 from the beginning (e.g., loop back to block 310).

According to block 380, the computer 14 may be programmed to determine a crossing event (e.g., an occupant entry or exit event) by executing dynamic vehicle model instructions stored in the memory 24. The model may be used to assert or validate the determination made in block 350, or it may be used as a separate process to determine a traversal event. As will be explained below, in at least the illustrated example, it is used to verify a positive determination in block 350 (e.g., because block 390 may require blocks 350 and 380 to be true before proceeding to block 400).

In the following description, at least a portion of the model instructions may be implemented using Matlab Simulink (TM); however, this is only one example. Of course, other modeling techniques may alternatively be used. In fig. 19, a schematic diagram of a vehicle model 140 is shown, where the mass m represents the mass of the vehicle 12-for example, the vehicle 12 is modeled as having three degrees of freedom (e.g., translation (Z) along the Z-axis, rotation (roll) about the x-axis, and rotation (θ) (pitch) about the y-axis). In the corners of the model 140, predetermined locations A, B, C and D are shown, where the segment AB (e.g., distance Bf or Bf/2+ Bf/2) corresponds to the front side 46 of the vehicle 12, and the segment CD (e.g., distance Br or Br/2+ Br/2) corresponds to the rear side 48 of the vehicle 12 (e.g., thus, the segment AC (e.g., distances a and b, or a + b) corresponds to the left side 42, and the segment BD (also e.g., distance a + b) corresponds to the right side 44).

The model 140 shown in fig. 19 may also include a vertical force F (x, y) that may be applied to the vehicle 12 by an entering or exiting occupant within the boundaries defined by positions A, B, C and D. Vertical directional forces (e.g., corresponding to vehicle tires and suspension systems) are also modeled-i.e., forces FA along axis-z 5, FB along axis-z 6, FC along axis-z 9, and FD along axis-z 8, respectively, where axes-z 5, -z6, -z8, and-z 9 are parallel to the z-axis.

The model may be governed by exemplary equations (1) through (7).

Equation (1)

Equation (2)

Equation (3)

Equation (4)

Equation (5)

Equation (6)

Equation (7)

In the above equation, is the axial acceleration along the z-axis and is (for example) related to the axial velocity relative thereto. I0 is the instantaneous moment of inertia about the y-axis (pitch moment of inertia) and the instantaneous moment of inertia about the x-axis (roll moment of inertia), respectively, and is the angular acceleration about the y-axis and the x-axis, respectively. Further, KS1, KS2, KS3, and KS4 may be spring constants associated with the vehicle tires and the vehicle suspension system, and C1, C2, C3, and C4 may be damping constants associated with the vehicle tires and the vehicle suspension system. Both spring and damping constants are known in the art; these constants may be any suitable values. The positions x and y may define the position where the force F is applied. Exemplary values of x and y are shown in table II below. These particular locations may correspond to four different vehicle seats in a test vehicle (e.g., such as vehicle 12) that may be used to generate the previously illustrated sensor data (e.g., fig. 4-18).

TABLE II

Coordinates of the object	x	y
			Left front	0.1	-0.5
Right front	0.1	0.5
			Left back	-1.3	-0.5
Right back	-1.3	0.5

Tables III and IV set forth some illustrative values for some of the other parameters of equations (1) through (7). It should be appreciated that these parameters may be equal to or approximate the corresponding parameters of the test vehicle described above; these parameters are merely examples showing how the dynamic model instructions operate; other suitable parameters may alternatively be used.

TABLE III

Parameter(s)	Value of
		fFront track (Bf)	1.6667(m)
rRear track (Br)	1.6708(m)
		CG to front axle a	1.1752(m)
CG to rear axle b	1.6898(m)
		s1Left front suspension stiffness Ks1	100(KN/m)
s2Right front suspension stiffness Ks2	100000(N/m)
		s3Left rear suspension stiffness Ks3	100(KN/m)
s4Right rear suspension stiffness Ks4	100000(N/m)
		Moment of inertia of roll	1500(kg·m^2)
Servicing quality (m)	2110(kg)
		Moment of inertia in pitch	4321(kg·m^2)

TABLE IV

Using Matlab, the response curves 150, 152, 154, 156 shown in fig. 20-23 may be generated using the dynamic model instructions and parameters set forth above, respectively, to confirm that if computer 14 executes similar instructions (e.g., according to block 380 of process 300), then computer 14 may determine whether the user is entering or leaving vehicle 12. In fig. 20 to 23, the generated response curves 150 to 156 cover the Rotation Indicator (RI) in the sensor data received via the roll rate sensor 32.

According to one example, as shown in equations (8) and (9), the model instructions of the examples illustrated above may be used to derive a transfer function equation from the roll rate response of the body 12 based on occupant weight (modeled as a step input). In this example, these two equations may be associated with gate D2; however, these equations are merely examples. Similar transfer function equations may be determined by computer 14 for occupants entering or exiting other doors (e.g., D1, D3, D4, etc.).

Equation (8) enters

Equation (9) departs

Equations (8) and (9) may be a laplace transform of the roll rate signal, and w(s) may be a laplace transform of the occupant weight. According to one example of the model command, if the start time is set to 0 (t), the step response using equations (8) and (9) may be expressed as equation (10), where γ (t) may be defined as and where during the entering, a is 0.0003333, b is 8.354, c is 185.6, and where during the leaving, a is-0.0003333, b is 29.7, c is 185.6.

Equation (10)

The occupant weight (W) (e.g., the magnitude of the respective step inputs as shown in fig. 24-25) may be identified by applying the homogeneity of the linear time-invariant system. Fig. 24 shows the step response 160 for an occupant entering via door D2 according to the above-described transformation. And fig. 25 shows the step response 162 of the occupant exiting via door D2 according to the transformation described above. The nature of linear time invariant systems is well known to the skilled person; accordingly, these will not be discussed herein. Thus, in at least this example (e.g., for a particular door), the size (e.g., weight indicator, WI) may be defined by equation (11).

Equation (11) where Ψ may be the maximum of the absolute values of the roll rates obtainable from the test vehicle, where ω may be the maximum of the absolute values of the roll rates, but may be calculated using equation (10). Of course, equations (8) through (11) may again relate to occupant ingress or egress via door D2, but computer 14 may derive similar equations and use them for occupant Weight Indicators (WI) associated with occupants entering or exiting via at least one of the other doors D1, D3 through D4, and so forth.

Once the Weight Indicator (WI) is determined, computer 14 may compare it to a predetermined third threshold (THR3) in block 380 (fig. 3). And as described above, if the Weight Indicator (WI) is greater than the threshold value (THR3), the process 300 may proceed to block 390. If the Weight Indicator (WI) is less than or equal to the third threshold (THR3), the process 300 may loop back and repeat block 310.

In block 390, if the Weight Indicator (WI) is greater than the threshold (THR3) and the rotation indicator determined in block 350 is at least one of: greater than the first threshold (THR1) or less than the second threshold (THR2), the process 300 proceeds to block 400. Block 390 may ensure that the Rotation Indicator (RI) loop of process 300 is not completed and likewise that the Weight Indicator (WI) loop is not completed, and vice versa. Thus, if neither the rotation indicator nor the weight indicator indicate a crossing event, the process 300 proceeds from block 390 to block 330 or block 350 to complete the analysis, respectively.

In block 400, computer 14 may increment or decrement a previously initialized counter. The counter may comprise programming logic and/or instructions stored in memory 24 or may be implemented as circuitry, to name a few non-limiting examples. During initialization, the counter may be set to zero (0); initialization may occur, for example, at a manufacturing facility or an authorized service center. Thus, for example, when an entry event is determined, the counter may be incremented by one (1). And the counter may be decremented by one (1) when a leave event is determined. Of course, in some cases, the counter may be incremented or decremented by more than one (as explained above-e.g., if multiple Rotation Indicators (RI) so indicate, so does one or more Weight Indicators (WI)). Other suitable increases and decreases are also possible.

Table V below shows one example of an increase and decrease based on one example of the vehicle 12, where the vehicle 12 includes four doors D1-D4 leading to four adjacent vehicle seats (e.g., a front left seat, a rear left seat, a front right seat, and a rear right seat). The table shows that if computer 14 determines entry or exit with respect to one of the doors, computer 14 may increment by +1 or-1 accordingly.

TABLE V

After block 400, the process 300 may loop back to block 310 and continue to monitor sensor data from the vehicle sensors 26-36, 121-124 as previously described. Optionally, process 300 may end.

It should be appreciated that process 300 may be performed when the vehicle ignition status is on or off. In this manner, the computer counter may track the number of occupants in any state. Further, it should be appreciated that the counter may be reset by the computer 14 at any suitable time-including, for example, by authorized service personnel or even when other vehicle data indicates to the computer 14 that the passenger compartment 16 is free of occupants. For example, if the camera or other imaging device determines that the car 16 is empty (and the counter of the computer 14 indicates that the car 16 is occupied by at least one user), the computer 14 may reset the counter. Other suitable reset implementations also exist.

In other examples, the computer 14 may determine the crossing event and/or count the occupants without determining both the Rotation Indicator (RI) and the Weight Indicator (WI). In at least one example process, only one of the rotation or weight indicators may be determined. For example, the determination of other indicators may be omitted.

In another example, one or more Rotation Indicators (RI) may be determined, for example, in turn, and then a Weight Indicator (WI) may be determined. Or the order may be reversed. Still other examples exist.

In at least some examples, the computer 14 detection of occupants, determination of number of occupants, determination of occupant weight, and the like may be used to improve the athletic performance of the vehicle. Alternatively, this type of information may be used to improve vehicle fuel economy (e.g., by providing information to a real-time calibration system of the vehicle powertrain). Alternatively, such information may be used to improve vehicle emergency services (e.g., by providing information to a vehicle crash alert system in response to a collision or crash). Further, this type of information may be used to alert one or more occupants when the occupant remains or otherwise remains in the vehicle (e.g., once the vehicle reaches its destination-e.g., in a taxi embodiment). These are merely examples; other examples exist.

Thus, an occupant detection system for a vehicle has been described. The system includes a computer that receives sensor data from one or more vehicle sensors. The sensor may comprise at least one rotation rate sensor. Using the sensor data, the computer is programmed to determine whether an occupant is entering or exiting the vehicle. Thereafter, the computer may increment or decrement the counter as needed.

In general, the described computing systems and/or devices may employ any of a number of computer operating systems, including, but in no way limited to, the following versions and/or variations of the operating system: ford application, AppLink/Smart Device Link middleware, Automotive operating system, Linux operating system, the iOS operating system published by Apple Inc. of Cuttinol, Calif., the Blackberry OS published by Blackberry Inc. of Toyoro, Canada, as well as the Android operating system developed by Google, Inc. and the Open Handcast Alliance or CAR infotainment platform supplied by QNX Software Systems. Examples of a computing device include, but are not limited to, an on-board computer, a server, or some other computing system and/or device.

Computing devices typically include computer-executable instructions that may be executed by one or more computing devices, such as those listed above. The computer executable instructions may be programmed as embedded software that may run in a so-called real-time operating system. Generally, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes those 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 computer-readable storage medium (also referred to as a processor-readable medium) includes any non-transitory (e.g., tangible) medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media may include, for example, optical or magnetic disks and other persistent memory. Volatile memory may include, for example, Dynamic Random Access Memory (DRAM), which typically constitutes a main memory. Such instructions may be transmitted by one or more transmission media, including coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to a processor of a computer.

A database, data warehouse, or other data storage described herein may include various mechanisms for storing, accessing, and retrieving various data, including a hierarchical database, a set of files in a file system, a proprietary format application database, a relational database management system (RDBMS), and so forth. Each such data storage device is typically included within a computing device employing a computer operating system, such as one of the operating systems described above, and is accessed via a network in any one or more of a variety of ways. The file system may be accessed from a computer operating system and may include files stored in various formats. RDBMS employs the Structured Query Language (SQL) in addition to languages used to create, store, edit and execute stored programs, such as the PL/SQL language described above.

In some examples, system elements may be embodied as computer readable instructions (e.g., software) on one or more computing devices (e.g., servers, personal computers, etc.), stored on computer readable media (e.g., disks, memory, etc.) associated therewith. The computer program product may include such instructions stored on a computer-readable medium for performing the functions described herein.

The processor is implemented via a circuit, chip, or other electronic component, and may include one or more microcontrollers, one or more Field Programmable Gate Arrays (FPGAs), one or more application specific circuits ASICs, one or more Digital Signal Processors (DSPs), one or more client integrated circuits, or the like. As described below, the processor instructs the vehicle component to actuate based on the sensor data. The processor may be incorporated into the controller from an electronic control unit.

the memory (or data storage) is implemented via a circuit, chip, or other electronic component, and may include one or more of the following: read Only Memory (ROM); random Access Memory (RAM); a flash memory; an electrically programmable memory (EPROM); an electrically erasable programmable memory (EEPROM); an embedded multimedia card (eMMC); a hard disk drive; or any volatile or non-volatile medium, etc. The memory may store data collected from the sensors.

The disclosure has been described in an illustrative manner, and it is to be understood that the terminology which has been used is intended to be in the nature of words of description rather than of limitation. Many modifications and variations of the present disclosure are possible in light of the above teachings, and the disclosure may be practiced otherwise than as specifically described.