Patent Description:
Height restrictions on roads are in place to prevent vehicles having a certain height from colliding with overhead obstructions such as a low bridge or gantry. Generally, the height of a vehicle may be static and known. In this case, a driver of the vehicle may simply avoid taking routes which involve height limits with which the vehicle does not comply.

<CIT> discloses an apparatus that includes a controller coupled to a first sensor positioned on a first object external to a vehicle and configured to receive first information indicative of a height of the first object from the first sensor via Bluetooth Low Energy (BLE) and store second information corresponding to a height of the vehicle. The controller is further configured to receive third information corresponding to a height of an overhead obstacle positioned external to the vehicle and to compare at least one of the first information and the second information to the third information. The controller is further configured to generate an alert based on the comparison of the at least one of the first information and the second information to the third information.

<CIT> discloses a vehicle clearance alert system that includes at least one sensor or camera disposed at a vehicle and having an exterior field of view in a direction of travel of the vehicle. A control is responsive to the camera and is operable to determine a height dimension of a structure in the path of travel of the vehicle. The control is operable, responsive to (i) the determined height dimension of a structure in the path of travel of the vehicle and (ii) a height dimension of the vehicle, to determine if there is sufficient clearance between the structure and the vehicle for the vehicle to pass under the structure. Responsive to a determination that there is not sufficient clearance between the structure and the vehicle for the vehicle to pass under the structure, the alert system is operable to generate an alert to the driver of the vehicle.

<CIT> discloses a method for preventing the collision of a vehicle with an overhead obstacle, comprising mounting at least one sensor on a vehicle that includes a vehicle control system, wherein the sensor is in electrical communication with a processor located within and powered by the vehicle; determining a reference height, which is the height above ground level at which the at least one sensor is mounted on the vehicle; inputting the reference height into the processor; determining the height of the tallest portion of the vehicle above ground level; inputting the height of the tallest portion of the vehicle above ground level into the processor; using the sensor to measure the overhead distance between the lowest portion of an obstacle and the at least one sensor; using the processor to determine a measured height of the overhead obstacle, which is the reference height added to the distance between the overhead obstacle and the sensor; and communicating an alarm to an operator of the vehicle if the measured height of the overhead obstacle is less than the height of the tallest portion of the vehicle above ground level.

Aspects of the present disclosure are set out in the accompanying independent and dependent claims. Combinations of features from the dependent claims may be combined with features of the independent claims as appropriate and not merely as explicitly set out in the claims.

According to a first aspect of the invention, there is provided a collision prevention system for a vehicle, as defined by claim <NUM>.

According to a second aspect of the invention, there is provided a collision prevention method for a vehicle, as defined by claim <NUM>. Preferred embodiments are listed in the dependent claims.

A collision avoidance system or method according to the present disclosure may allow collisions associated with the dimension of the vehicle to be avoided.

Embodiments of this disclosure will be described hereinafter, by way of example only, with reference to the accompanying drawings in which like reference signs relate to like elements and in which:.

Embodiments of this disclosure are described in the following with reference to the accompanying drawings.

As described herein, the dimension of a vehicle is monitored by a sensor and compared with a dimension of an approaching obstacle detected by another sensor. The dimension of the vehicle monitored by the first sensor is a height of the vehicle and the dimension of the approaching obstacle detected by the second sensor is a height of the approaching obstacle. However, it will be appreciated that this may also be applied to other dimensions of the vehicle and the approaching obstacle. For instance, the dimension of the vehicle monitored by the first sensor may be a lateral dimension of the vehicle (e.g. in a direction substantially parallel to the ground and substantially perpendicular to a direction of travel of the vehicle). Similarly, the dimension of the approaching obstacle detected by the second sensor may be a lateral dimension associated with the lateral dimension of the vehicle monitored by the first sensor.

<FIG> shows a vehicle <NUM>. The vehicle <NUM> may, for instance be a car, truck, lorry or any other kind of road vehicle.

The vehicle <NUM> includes a first sensor <NUM>. The first sensor <NUM> is operable to monitor a height of the vehicle <NUM>. As noted above, the dimension monitored by the first sensor may not be the height of the vehicle but may instead be a lateral dimension of the vehicle (e.g. see the lateral dimensions <NUM>, <NUM> shown in <FIG>).

The first sensor <NUM> may be located in any suitable position within or upon the vehicle <NUM>. For example the first sensor <NUM> may be located on a roof, side, or other exterior part of the vehicle <NUM>. The first sensor <NUM> may comprise any suitable sensor for monitoring the dimension (height, lateral dimension etc.) of the vehicle <NUM>, for example, the first sensor <NUM> may comprise a camera, an ultrasound sensor, a RADAR (Radio Detection and Ranging) sensor, or a LIDAR (Light Detection and Ranging) sensor.

The vehicle <NUM> also includes a second sensor <NUM>. The second sensor is operable to detect an approaching obstacle. In particular, the second sensor <NUM> is operable to detect a dimension (e.g. height, lateral dimension such as width) of the approaching obstacle. The dimension (height, in this example) of the approaching obstacle may represent a clearance dimension (height, in this example), above which collisions may, or will, occur.

The approaching obstacle may, for example, be an overhanging obstacle such as a low bridge or gantry, a tunnel, a road sign or a tree branch.

The second sensor <NUM> may, for example, be located toward the front of the vehicle <NUM>. The second sensor <NUM> may be any suitable sensor for determining the dimension (height, in this example) of the approaching obstacle. For instance, the second sensor may comprise a RADAR sensor a LIDAR sensor, an ultrasound sensor or a camera.

The vehicle <NUM> also includes a controller <NUM>. The controller <NUM> may be coupled to the first sensor <NUM> and the second sensor <NUM> by, for example, a data/control signal bus <NUM>. The bus may be part of a Car Area Network (CAN). The bus may comprise a wired and/or a wireless connection. As will be described in more detail below, the controller <NUM> is operable to receive signals from the first sensor <NUM> and the second sensor <NUM>, those signals indicating the dimension (height, in this example) of the vehicle <NUM> monitored by the first sensor <NUM> and the dimension (height, in this example) of the approaching obstacle detected by the second sensor <NUM>.

The controller <NUM> is operable to compare the dimension (height, in this example) of the vehicle <NUM> monitored by the first sensor <NUM> with the dimension (height, in this example) of the approaching obstacle detected by the second sensor <NUM> and, in response to that comparison, to determine whether a collision between the vehicle and the obstacle is possible. If it is determined that a collision is possible, the controller <NUM> is further operable to perform a collision prevention action. Types of collision prevention action may, for example, include:.

The vehicle <NUM> shown in <FIG> further includes one or more control units <NUM>. These control units <NUM> may be, for example, for controlling a sunroof or window of the vehicle as noted above. The one or more control units <NUM> may also be coupled to the controller <NUM> via the bus <NUM>.

<FIG> shows a schematic of the functional blocks of a collision prevention system for a vehicle of the kind shown in <FIG> shows that the system can include a plurality of sensors <NUM>. For instance, in <FIG>, the sensor 40A may represent the first sensor <NUM> and the sensor 40B may represent the second sensor <NUM>. It is envisaged that further sensors may be provided in the plurality of sensors <NUM>, other than the first sensor <NUM> and the second sensor <NUM>.

The controller <NUM> includes functional blocks <NUM>, <NUM> and <NUM>. The functional block <NUM> may act to receive the signals from the plurality of sensors <NUM> such as the signals relating to the monitored dimension (height, in this example) of the vehicle <NUM> and the detected dimension (height, in this example) of the approaching obstacle as noted above in respect of <FIG>. The signals received by the functional block <NUM> may then be passed to a data processing block <NUM>, in which the aforementioned comparison of the dimension (height, in this example) of the vehicle <NUM> monitored by the first sensor <NUM> with the dimension (height, in this example) of the approaching obstacle detected by the second sensor <NUM> may be performed. The result of this comparison may then be passed to a central processing unit <NUM>. The central processing unit <NUM> may then take action in response to the comparison performed by the functional block <NUM>. In particular, the central processing unit <NUM> may act to implement a collision prevention action as described herein.

<FIG> also includes a number of electronic components <NUM> of the vehicle <NUM>. Examples of such electronic components may include a sunroof or window control unit 50A of the vehicle <NUM>, a brake control unit 50B of the vehicle <NUM> and/or an alert unit 50C of the vehicle <NUM>, for producing an audible or visual alert for the driver of the vehicle <NUM>. The central processing unit <NUM> may be coupled to the vehicle electronic components <NUM> (e.g., using the bus <NUM> shown in <FIG>) and may be operable to send appropriate signals to the electronic components <NUM> for implementing one or more collision prevention actions in the event that the comparison result received from the functional block <NUM> indicates that a collision between the vehicle <NUM> and the approaching obstacle is possible.

In <FIG>, block <NUM> represents a user request. The user request <NUM> may, for example, be a request to open a window or sunroof of the vehicle <NUM>. The incorporation of the user request <NUM> into a method described in more detail below in relation to, for example, <FIG>.

<FIG> shows a vehicle <NUM> approaching an obstacle <NUM>. The approaching obstacle <NUM> has a height h. The heigh h corresponds to a clearance height from the ground <NUM>. Accordingly, for example, the height h may be the height of an underside of a tree branch, or the height of the underside of low bridge or gantry or road sign from the ground <NUM>.

<FIG> again shows the first sensor <NUM> and the second sensor <NUM> of the vehicle <NUM> as well as the sunroof or window control unit <NUM>.

The vehicle <NUM> has a static height component y and a non-static height component x. The total height of the vehicle <NUM> may be denoted as z where z = y + x.

In operation, the first sensor <NUM> may be operable to determine the height z.

This may, for instance, be achieved by knowledge of the static height component y, to which the first sensor <NUM> may add the value of x based over upon actual observations of dynamic changes (represented by x) in the total height z of the vehicle <NUM> or by possible changes that may occur in x as the vehicle <NUM> approaches the obstacle <NUM>. By way of example, if a passenger <NUM> of the vehicle <NUM> were to place their head of other parts of their body through the sunroof or window of the vehicle <NUM>, the total height of the vehicle z may change. It will be appreciated that similar considerations may apply to a lateral dimension of the vehicle, should the passenger put their head through an open side window of the vehicle. In this example, the first sensor <NUM> may detect the new total height z of the vehicle according to the height of the passengers head <NUM> above the ground <NUM> and accordingly may evaluate a new value of the total height z of the vehicle <NUM> and communicate this actual value to the controller <NUM>.

In another example, the system may anticipate the possible new total height z (or lateral dimension) of the vehicle <NUM> in the event that the passenger <NUM> were to extend their head through the sunroof or window of the vehicle <NUM>, albeit that at that moment the passenger <NUM> has not (yet) placed their head through the sunroof or window (e.g. the sunroof or window of the vehicle <NUM> is currently closed). This may be achieved either by the first sensor <NUM> reporting a value of z that includes the static height y plus an anticipated possible change (x) in the total height z in the event that the passenger <NUM> actually goes ahead and places their head through the sunroof or window. Alternatively, the first sensor <NUM> may simply report the actual present value of z, and anticipated changes (x) in the total height (for example, if the passenger <NUM> actually goes ahead and places their head through the sunroof or window) may be factored in at the controller <NUM>, as part of the determination of whether a collision is possible.

In either event, the first sensor <NUM> is operable to communicate the total height z of the vehicle to the controller <NUM> so that the comparison of the total height z with the height h of the approaching obstacle <NUM> may be performed.

In order to allow sufficient time for the collision prevention action to be performed, the second sensor <NUM> may need to determine the value of h of the approaching obstacle <NUM> at a given distance. It would be appreciated that this distance may vary according to the speed of the vehicle <NUM>. A typical value for the distance from the approaching obstacle <NUM> at which the height h needs to be determined would be around <NUM>-<NUM> meters although, again, it will be appreciated that this distance may vary according to the specific situation.

<FIG> shows a vehicle <NUM> encountering an approaching obstacle <NUM>. <FIG> is similar to <FIG>, except that the deviation of the total height z of the vehicle <NUM> from the nominal static height y of the vehicle <NUM> results from the mounting of a load <NUM> (for instance, luggage or other objects) upon the vehicle <NUM>, where the load <NUM> extends beyond the roof of the vehicle <NUM>. In this sense, the load <NUM> may have a static component x which extends above the nominal height y. Nevertheless, it will be appreciated that the additional height of the load <NUM> beyond the nominal static height y of the vehicle <NUM> represents an additional increase in the total height of the vehicle z. It may also be appreciated that the height of the load <NUM> may change in real time if the load <NUM> is not securely mounted upon the vehicle <NUM>. Again, the first sensor <NUM> is operable to observe the height difference x produced by the load <NUM> and communicate the value of the total height z of the vehicle <NUM> to the controller <NUM>, typically in real time. Anticipated changes may also be factored in, as noted above. The value of the total height z of the vehicle <NUM> may again be communicated to the controller <NUM> so that the comparison of the total height z of the vehicle <NUM> with the height h of the approaching obstacle <NUM> may be performed.

The total height z of the vehicle <NUM>, actual or anticipated, may thus be monitored in real time and any changes in the total height z of the vehicle <NUM> may be communicated to the controller <NUM>. The first sensor <NUM> may be operable to monitor the total height of the vehicle <NUM> by periodically sensing the height of the vehicle <NUM> at regular time intervals. By way of example only, the time intervals may be <NUM> seconds, <NUM> seconds, <NUM> second or any other suitable time interval. When shorter time intervals are used, this may allow the collision prevention system of this disclosure to react more quickly to real time changes in the total height z of the vehicle <NUM>, although this may come at the cost of increased processing overhead.

Although <FIG> have been explained in relation to height, it will be appreciated that the same principles may be applied to other dimensions such as a lateral dimension of the vehicle and a lateral dimension of the approaching obstacle.

<FIG> shows a collision prevention method <NUM>. The method <NUM> includes a number of different branches, starting at steps <NUM>, <NUM>, <NUM>. Note that these branches may be performed in parallel.

A first branch of the method <NUM> starts at step <NUM>. The first branch corresponds to the operation of the second sensor <NUM> of the vehicle <NUM>. In step <NUM>, data from the second sensor <NUM> may be processed and then in step <NUM>, the height h of an approaching obstacle may be determined from the data processed in step <NUM>. As the height h of the approaching object is determined at step <NUM>, this first branch of the method <NUM> may continually return to step <NUM> to process more data from the second sensor <NUM>. In this way, any changes in the height h may be detected, and the heights of newly approaching objects may also be detected and determined.

A second branch of the method <NUM> starts at step <NUM>. The second branch corresponds to the operation of the first sensor <NUM> of the vehicle <NUM>. At step <NUM>, data from the first sensor <NUM> may processed. At step <NUM>, the total height of the vehicle <NUM> may be determined using the data processed in step <NUM>. As already described above, the total height may or may not, at this stage, factor in an anticipated possible change in the height of the vehicle <NUM>. As the total height of the vehicle <NUM> is determined at step <NUM>, this second branch of the method <NUM> may continually return to step <NUM> to process more data from the first sensor <NUM>. In this way, any real time changes in the total height of the vehicle <NUM> may be detected.

At steps <NUM> and <NUM>, a comparison of the height h of the approaching obstacle <NUM> determined in step <NUM>, with the height of the vehicle <NUM> determined in step <NUM> is made. For instance, in step <NUM>, the total height of the vehicle <NUM> may be adjusted to include an anticipated, possible total height in the vehicle <NUM> as noted above, assuming that this has not yet already been factored into the total height reported by the first sensor <NUM>. Step <NUM> may also involve determining a safe height threshold compared to the height h of the approaching obstacle reported by the second sensor <NUM>. By way of example, the safe height threshold may be computed as a percentage of the height h, or (e.g. the safe height threshold may be <NUM>%, <NUM>%, <NUM>%, or <NUM>% etc. of the approaching obstacle height), or may be associated with an absolute difference between the height of the vehicle <NUM> and the height of the approaching obstacle (e.g. the threshold may be <NUM>, <NUM>, <NUM> etc. less than the approaching obstacle height). It is envisaged that the safe height threshold could be programmable, e.g. according to the type of vehicle. The comparison of the height of the vehicle <NUM> with the height of the approaching obstacle <NUM> may be performed in step <NUM>. For instance, the total height z of the vehicle <NUM>, possibly including any possible, anticipated changes in the total height as described above, may be compared with the safe height threshold described above. The result of this comparison may be reported to step <NUM>, to be described below.

A third branch of the method <NUM> starts at step <NUM>. The third branch corresponds to the operation of the controller <NUM> and any vehicle electronic components <NUM> of the kind described above in relation to <FIG>.

At step <NUM> a determination is made by the controller <NUM> as to whether the sunroof or window on the vehicle <NUM> is open. While <FIG> is explained here in relation to a sunroof or window of the vehicle, it will be appreciated that the method of <FIG> may also be applied to a window of the vehicle <NUM>. If the sunroof or window is determined to be open, then the method <NUM> may pass to step <NUM>. Step <NUM> may involve the performance of a collision prevention action such as the application of the brakes of the vehicle <NUM> and/or the production of a warning alert to the driver of the vehicle <NUM>, in response to a determination in step <NUM> that a collision is possible. For a further description of the actions which may be taken if it is determined in step <NUM> that the sunroof or window is already open, see <FIG>.

The collision prevention action performed is the prevention of the opening of the sunroof or window if it is determined in step <NUM> that, for example, a passenger putting their head through the sunroof or window of the vehicle may cause the total height of the vehicle <NUM> to meet or exceed the safe height threshold. Accordingly, if the sunroof or window is determined in step <NUM> to be currently closed, the method <NUM> may pass to step <NUM>.

In step <NUM>, a determination is made by the controller <NUM> as to whether there has been a user (driver, passenger. ) request to open the sunroof or window. This user request may correspond to a request <NUM> of the kind described above in relation to <FIG>.

If, in step <NUM>, it is determined that no such user request has been received, then the method <NUM> may loop back to step <NUM>. In this way, the controller may periodically monitor for any user requests <NUM> to open the sunroof or window. On the other hand, if it is determined in step <NUM> that there is a user request to open the sunroof or window, the method <NUM> may pass to step <NUM>.

The parts of the method <NUM> shown in box <NUM> in <FIG> correspond to the processing of a user request to open the sunroof or window, and the performance of a collision prevention action involving denying the user request to open the sunroof or window, if this may cause a collision (e.g. were a passenger to put their head through the open sunroof or window).

In step <NUM>, the outcome of the determination made in step <NUM> is received in conjunction with the indication from step <NUM> that there has been a request to open the sunroof or window.

In step <NUM>, a determination is made as to whether it is safe to allow the sunroof or window to be opened. In particular, if the determination in step <NUM> indicated that a collision is possible (e.g. that the anticipated change x in height z associated with a passenger possibly putting their head through the open sunroof or window may lead to a collision), then the method <NUM> may pass to step <NUM>.

In step <NUM>, the collision prevention action is taken. The collision prevention action involves denying the user request <NUM> to open the sunroof or window of the vehicle <NUM>. This may, for instance, be implemented by disabling the in-vehicle controls which operate the sunroof or window. It is also envisaged that the collision prevention action may further involve applying the brakes of the vehicle <NUM> and/or generating an collision alert for a driver of the vehicle <NUM>. The alert may, for instance, be an audible and/or visual alert.

On the other hand, if at step <NUM> it is determined that it is safe to open the sunroof or window (e.g. the height h of any approaching obstacles is high enough that no collision would occur if a passenger were to put their head through the open sunroof or window, or if no approaching obstacles have been detected), then the method <NUM> may pass to step <NUM>.

At step <NUM>, it is determined that no collision prevention action is required and, consequently, at step <NUM>, the controller <NUM> allows the sunroof or window to be opened. This may, for instance, be implemented by the controller signaling a sunroof or window control unit 50A of the kind shown in <FIG> to open the sunroof or window.

Following step <NUM>, the method <NUM> may loop back to step <NUM>.

Note the <FIG> is similar to <FIG>, except that <FIG> shows in more detail the actions which may be taken if it is determined in step <NUM> that the sunroof or window is already open. Accordingly, the following steps in <FIG> correspond to the following steps in <FIG> and the description of these steps will not be repeated here:.

As described previously, step <NUM> in <FIG> (which corresponds to step <NUM> in <FIG>) is reached if, in step <NUM>, it is determined that the sunroof or window is currently closed. Note that in step <NUM> of <FIG>, if it determined that there has been a user request to open the sunroof or window, then the method <NUM> may proceed as described above in relation to the steps in box <NUM> in <FIG>.

On the other hand, if it is determined in step <NUM> that the sunroof or window is currently open, then the method <NUM> may pass to step <NUM>.

The parts of the method <NUM> shown in box <NUM> in <FIG> correspond to the performance of a collision prevention action involving applying a brake of the vehicle and/or producing a collision alert for a driver of the vehicle.

In step <NUM>, the outcome of the determination made in step <NUM> is received in conjunction with the indication from step <NUM> that the sunroof or window is currently open. Unlike in <FIG>, since the sunroof or window is already open, the option to prevent opening of the sunroof or window does not exist. Nevertheless, the controller <NUM> has the option to perform a collision prevention action involving applying a brake of the vehicle <NUM> and/or producing a collision alert for a driver of the vehicle <NUM>.

In step <NUM>, a determination is made as to whether a collision may occur. This determination may be based on the determination in step <NUM>, which indicated that a collision is possible (e.g. that the anticipated change x in height z associated with a passenger possibly putting their head through the open sunroof or window may lead to a collision).

If, in step <NUM>, it is determined that no collision is possible (e.g. because there are no approaching obstacles or because the height h of the obstacle is such that the safe height threshold is not met or exceeded), the method <NUM> may loop back to step <NUM>. In this way, the method <NUM> may continue to monitor for possible collisions.

On the other hand if, in step <NUM>, it is determined that a collision is possible, the method <NUM> may pass to step <NUM>. In step <NUM>, the controller <NUM> may determine that a collision prevention action is required.

In step <NUM>, the controller <NUM> may implement the collision prevention action. As described above, the collision prevention action may involve applying the brakes of the vehicle. To implement this, the controller <NUM> may, for instance, send a command signal to a brake control unit 50B of the vehicle <NUM> (as described in <FIG>) to apply the brakes of the vehicle <NUM>. As an alternative, or in addition to the application of the brakes, the controller <NUM> may also implement the collision prevention action involving producing a collision alert for a driver of the vehicle <NUM>. The alert may, for instance, be an audible alert (such as an alarm sounds or pre-recorded verbal warning) and/or visual alert (such as a warning light or symbol appearing on the dashboard of the vehicle).

Note the <FIG> is similar to <FIG> and <FIG>, except that <FIG> involves the application of the brakes of the vehicle and/or the production of a collision alert for a driver of the vehicle, without necessarily involving the operation of the sunroof or window of the vehicle. Accordingly, the following steps in <FIG> correspond to the following steps in <FIG> and the description of these steps will not be repeated here:.

A third branch of the method <NUM> in <FIG> may start at step <NUM>.

As in <FIG>, the parts of the method <NUM> shown in box <NUM> in <FIG> correspond to the performance of a collision prevention action involving applying a brake of the vehicle and/or producing a collision alert for a driver of the vehicle. However, the collision prevention action may include any of the application of the brakes of the vehicle <NUM>, the production of collision alert for a driver of the vehicle <NUM>, and includes the denial of a user request <NUM> (such as a request to open a sunroof or window of the vehicle <NUM>.

In step <NUM>, the outcome of the determination made in step <NUM> is received by the controller <NUM>. As describe previously, step <NUM> may involve determining whether a sunroof or window of the vehicle is open and then tailoring the collision prevention action accordingly. However, for the remainder of the description, it will be assumed that the operation of the sunroof or windows is not factored into the determination and performance of a collision prevention action. In that sense, <FIG> may be applied to <FIG>, in which the height of the vehicle is associated with a load <NUM> placed on the vehicle. Nevertheless, the method <NUM> may still factor in anticipated possible changes in the height of the load, as noted previously.

In step <NUM>, the controller may determine whether a collision is possible, based upon the indication from step <NUM> received by the controller in step <NUM>. If, in step <NUM>, it is determined that a collision is not possible (e.g. because there are no approaching obstacles or because the height h of the obstacle is such that the safe height threshold is not met or exceeded), then the method <NUM> may loop back to <NUM>. In this way, the method <NUM> may continue to monitor for possible collisions.

On the other hand if, at step <NUM> it is determined that a collision is possible, the method <NUM> may pass to step <NUM>. In step <NUM>, the controller <NUM> may determine that a collision prevention action is required.

Claim 1:
A collision prevention system for a vehicle (<NUM>), the system comprising:
a first sensor (<NUM>) operable to monitor a dimension of the vehicle (<NUM>);
a second sensor (<NUM>) for detecting a dimension of an approaching obstacle (<NUM>); and
a controller (<NUM>) couplable to the first sensor (<NUM>) and the second sensor (<NUM>);
wherein the controller (<NUM>) is operable to:
compare the dimension of the vehicle (<NUM>) monitored by the first sensor (<NUM>) with the dimension of the approaching obstacle (<NUM>) detected by the second sensor (<NUM>); and
in response to a determination that the comparison of the dimension of the vehicle (<NUM>) with the dimension of the approaching obstacle (<NUM>) indicates a collision between the vehicle (<NUM>) and the obstacle (<NUM>) is possible, performing a collision prevention action,
characterized in that the collision prevention action comprises a pre-emptive collision prevention action to prevent a dimension of the vehicle (<NUM>) increasing beyond a safe dimension threshold associated with the dimension of the approaching obstacle (<NUM>) as the vehicle (<NUM>) approaches the obstacle (<NUM>), the pre-emptive collision prevention action comprising denying a driver or passenger (<NUM>) request to open a window or sunroof of the vehicle (<NUM>).