Vehicle remote parking assist systems and methods

Abstract

Vehicles and methods are disclosed for enabling vehicle occupants to maximize their time inside a vehicle during a remote parking operation, so as to limit exposure to adverse weather. An example vehicle includes a door, a sensor, and a processor. The processor is configured to determine a minimum open door angle for an occupant to exit, determine a vehicle path for execution of a remote parking operation, and, responsive to determining via the sensor during execution of the remote parking operation that the door is prevented from opening to the minimum door angle, pause execution of the remote parking operation.

Description

TECHNICAL FIELD

The present disclosure generally relates to vehicle remote parking assistance, and, more specifically, systems and methods to maximize occupant's time spent in the vehicle during a remote parking operation into a narrow parking space.

BACKGROUND

Modern vehicles may include the ability to remotely drive themselves with no or only minor control instruction from the user. Some vehicles may even be able to park themselves while an owner or driver watches from either inside or outside the vehicle and provides no or minimal motion control instruction. In these instances, the driver may initiate the remote parking operation, and the vehicle may proceed to position the vehicle in a parking spot using vehicle sensors.

SUMMARY

The appended claims define this application. The present disclosure summarizes aspects of the embodiments and should not be used to limit the claims. Other implementations are contemplated in accordance with the techniques described herein, as will be apparent to one having ordinary skill in the art upon examination of the following drawings and detailed description, and these implementations are intended to be within the scope of this application.

Example embodiments are shown enabling a driver and other occupants of a vehicle to remain in the vehicle during a remote parking operation executed by the vehicle into a narrow parking spot. An example disclosed vehicle includes a door, a sensor, and a processor. The processor is configured to determine a minimum open door angle for an occupant to exit, determine a vehicle path for execution of a remote parking operation, and responsive to determining via the sensor during execution of the remote parking operation that the door is prevented from opening to the minimum door angle, pause execution of the remote parking operation.

An example disclosed method includes determining a minimum open door angle of a door for an occupant to exit a vehicle. The method also includes determining a vehicle path for execution of a remote parking operation. And the method further includes, responsive to determining via a sensor during execution of the remote parking operation that the door is prevented from opening to the minimum open door angle, pausing execution of the remote parking operation.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention, reference may be made to embodiments shown in the following drawings. The components in the drawings are not necessarily to scale and related elements may be omitted, or in some instances proportions may have been exaggerated, so as to emphasize and clearly illustrate the novel features described herein. In addition, system components can be variously arranged, as known in the art. Further, in the drawings, like reference numerals designate corresponding parts throughout the several views.

FIGS. 1A-1C illustrate an example vehicle having a single occupant and performing a remote parking operation according to embodiments of the present disclosure.

FIGS. 2A-2D illustrate another example vehicle having two occupants and performing a remote parking operation according to embodiments of the present disclosure.

FIG. 3 illustrates a block diagram of electronic components of the vehicles of FIG. 1 and FIG. 2.

FIG. 4 illustrates a flowchart of an example method according to embodiments of the present disclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

While the invention may be embodied in various forms, there are shown in the drawings, and will hereinafter be described, some exemplary and non-limiting embodiments, with the understanding that the present disclosure is to be considered an exemplification of the invention and is not intended to limit the invention to the specific embodiments illustrated.

As noted above, embodiments herein are directed to vehicles, systems, and methods for providing occupants of a vehicle a maximum amount of time inside the vehicle when executing a remote parking operation into a narrow parking spot. In some scenarios in which there is rain, snow, cold temperatures, or other inclement weather, the driver and/or other occupants may wish to stay inside the vehicle as long as possible to avoid waiting outside the vehicle for the full remote parking operation to be carried out.

However, if the parking spot into which the vehicle is going to be parked is narrow, one or more doors of the vehicle may not be able to open to a sufficient distance for the driver and/or passengers to exit once parked. Embodiments disclosed herein may enable a driver and/or passengers to remain in the vehicle during the early stages of the remote parking operation. As the vehicle enters the parking space, the vehicle may determine the position of the vehicle and/or the environment to determine the last possible moment at which one or more vehicle doors can be opened safely and to a given open door angle. The vehicle may then pause to allow the occupant to exit through the door, and resume execution of the remote parking operation after the door has been closed and/or a continue command has been received.

In order to provide this functionality to the driver and/or other vehicle occupants, the process may first include the driver starting an automated remote parking operation or maneuver. In some cases the vehicle may evaluate whether the intended parking spot is narrow and/or whether an end position of the vehicle when parked will result in one or more of the doors being prevented from opening. In some examples the vehicle operator may input which door(s) correspond to occupied vehicle seats, and thus which doors should be considered when performing the remote parking operation. Each door may have an associated open door angle, which corresponds to the angle at which the door should be opened to safely and comfortably allow the occupant to exit the vehicle. These angles can be default angles, or may be adjusted by the occupant or vehicle operator via one or more inputs.

As the vehicle executes the remote parking operation into the narrow parking spot, the vehicle may continuously monitor the position of the vehicle (and/or various components of the vehicle) with respect to the environment, including any adjacent vehicles or obstacles that cause the intended parking spot to be narrow. The vehicle may also project a position of the door(s) of the vehicle when opened to their corresponding open door angles, so as to determine the moment when the doors are no longer able to open. The vehicle may then stop execution of the remote parking operation (either at that point, or shortly before or after). The occupant may then open the door, exit the vehicle, and close the door. The vehicle may then proceed with executing the remote parking operation. If a second door was indicated as corresponding to an occupant, the vehicle may continue the remote parking operation by moving the vehicle into the narrow parking spot until the second door is nearly prevented from opening to its corresponding open door angle. The vehicle may then pause execution to allow the occupant to open the door, exit, and close the door. This process may be repeated for each door that is indicated as corresponding to an occupied seat (either by an operators selection, an automatic determination via one or more vehicle sensors, or via some other technique). After the final door has been closed, the vehicle may proceed to finish the remote parking operation by parking the vehicle in the intended parking spot.

FIGS. 1A-1C illustrate the remote parking operation process described above when only a single operator is present in the vehicle driver's seat. Vehicle 100 may be a standard gasoline powered vehicle, a hybrid vehicle, an electric vehicle, a fuel cell vehicle, or any other mobility implement type of vehicle. Vehicle 100 may be non-autonomous, semi-autonomous, or autonomous. Vehicle 100 includes parts related to mobility, such as a powertrain with an engine, a transmission, a suspension, a driveshaft, and/or wheels, etc. In the illustrated example, vehicle 100 may include one or more electronic components (described below with respect to FIG. 3).

As shown in FIG. 1, vehicle 100 may include one or more components including driver's side front door 102. Vehicle 100 may also include one or more other doors, such as a passenger's side front door, rear door(s), and a trunk or liftgate. Examples disclosed herein are shown with reference to a sedan having four doors and a trunk, however it should be understood that the principles disclosed herein can also apply to other vehicles having other numbers and/or orientations of doors.

Each door may have a particular minimum open door angle, which may refer to the angle at which the door opens to comfortably and safely allow an occupant to exit. This minimum open door angle may be a default value determined or set by a manufacturer, or may be set via input from a user of the vehicle.

In some examples, the minimum open door angle may be determined based on input received by a user via a user interface 112 of vehicle 100. Alternatively, the minimum open door angle may be set by having an operator of the vehicle move the door to a desired open angle, and storing the determined angle as the minimum open door angle for that door.

One or more determinations can be made based on the open door angle, in combination with other values such as the known door length from the pivot point, and other door characteristics. These values can allow the vehicle and/or processor 110 of vehicle 100 to predict a position of the door when opened to the open door angle.

Vehicle 100 may also include one or more sensors 104, which may be positioned at various places in and around vehicle 100. Sensors 104 may be ultrasonic, radar, video, image, or other types of sensors that are configured to determine the location of objects and obstacles in the environment surrounding vehicle 100. Sensors 104 may be used to determine a distance between the vehicle 100 and the objects in environment, including vehicles 132 and 134 in parking spots adjacent to the intended parking spot 130 of FIGS. 1A-1C.

Information from the sensors may be combined with or used in connection with known door characteristics, such as the door length and shape, to determine whether or not a door can be opened to a given door angle. For instance, the sensor data may be used in connection with known door characteristics to monitor the sides of the vehicle as the vehicle moves, to continuously determine what angle the door can be opened to without running into objects in the environment. In particular examples, the sensor information may be used to determine whether a given door can be opened to a minimum open door angle or not.

Processor 110 of vehicle 100 may be configured to carry out one or more functions or acts such as those described herein. Processor 110 may be part of on-board computing system 302 described with respect to FIG. 3.

In some examples, processor 110 may be configured to determine the minimum open door angle corresponding to one or more doors, wherein the minimum open door angle is the angle of the door for which an occupant is able to comfortably exit the vehicle. In FIGS. 1A-1C, this may include determining the minimum open door angle of door 102. The open door angle 106 is shown in FIG. 1B.

In some examples, the minimum open door angle may be determined based on a default value (e.g., 45 degrees). This may be defined by the manufacturer, and may depend on the make and model of the vehicle, as well as one or more characteristics of the particular door (front vs back, lift gate, etc.).

The minimum open door angle may also be input by a user via user interface 112. The user can specify a particular angle or other value corresponding to the amount that the door opens to allow the user to exit the vehicle.

Further, the minimum open door angle may be set through actuation of the door itself. The user may manually move the door to a particular open position that is comfortable for the user. The vehicle can then store the current angle of the door as the minimum open door angle corresponding to that door for later use.

In some examples, the minimum open door angle for a given door may be determined based on a detected occupant identity. For instance, the vehicle may store one or more profiles or accounts for various vehicle operators or passengers. A first profile may have a first minimum open door angle corresponding to the driver's side front door, and a second profile may have a second, different, minimum open door angle for the same door.

The processor may determine which particular profile to use based on the detection of a key FOB 124. The driver may have the key FOB in his or her pocket, purse, bag, or otherwise have it nearby. The vehicle can then determine an identity or profile corresponding to the key FOB 124, and responsively determine that the minimum open door angle for the door 102 should be set based on the detected identity.

In some examples, instead of or in addition to using the key FOB 124, one or more internal or external sensors may be used to detect whether a person is present in a given vehicle seat, and an identity corresponding to that person. For instance, an internal camera may be used with facial recognition software to determine the identity of the operator, and match it to a stored profile. Then based on the stored profile, the processor may determine the appropriate minimum open door angle. In addition, pressure sensors or occupancy sensors on the seats, cameras, and other sensors may be used to determine whether one or more other seats are occupied. Each door of vehicle 100 may have the same minimum open door angle, or may have a different open door angle.

Processor 110 may also be configured to determine that a remote parking operation has been initiated. The operation may be initiated via user interface 112, remote computing device 122, or via another source.

The operator of vehicle 100 may select one or more doors of vehicle 100 that correspond to occupied seats. For instance, when starting the remote parking operation the operator may select the front driver's side seat and the rear passenger side seat. Or rather than selecting the occupied seats, the operator may select one or more seats that correspond to doors which the operator of the vehicle wishes to have open to minimum open door angle prior to completing remote parking operation (e.g., if there is a large package in a seat that the operator wishes to remove before the car is fully parked and the door is prevented from opening far enough). The user interface 112 and/or remote computing device 122 may display a graphic showing an overhead view of vehicle 100, and the operator may select the seats and/or doors that should be opened prior to completing the remote parking operation.

Processor 110 may also determine a vehicle path 108 for execution of the remote parking operation. Vehicle path 108 may be a path along which vehicle 100 is intended to travel to enter the intended parking spot 130. The path 108 may be determined based on data gathered by one or more vehicle sensors, such as sensors 104.

In some examples, determining the vehicle path 108 may include determining that the intended parking spot 130 is narrow. This can include determining that one or more vehicle doors may be prevented from fully opening or opening to a minimum open door angle if the vehicle is parked in the intended parking spot. This can be determined based on data from sensor 104 interaction with vehicles 132 and 134 (or other objects in the environment), which are parked close to the parking spot 130. In some examples, the functions and actions disclosed herein may be carried out responsive to (or only after) determining that the intended parking spot 130 is narrow such that one or more vehicle doors will be prevented from opening to the minimum open door angle.

Vehicle path 108 is shown and described herein as including a reverse maneuver into parking spot 130. However it should be noted that other paths may be possible as well, such as driving forward into a spot, performing a parallel parking maneuver, or any other path or movement that results in the vehicle being parked in a spot in which one or more doors may be prevented from fully opening.

Processor 110 may then begin executing the remote parking operation by causing vehicle 100 to travel along the determined path 108. During execution, processor 110 may monitor the relative position of vehicle 100 and/or objects in the environment (e.g., vehicles 132 and 134 in FIGS. 1A-1C).

Then, for each door determined to correspond to an occupant, or for which the operator wishes to have open prior to completion of the remote parking operation, the processor may determine whether the door can open to its corresponding minimum door angle or whether it is prevented from doing so by the environment around the vehicle.

This may include determining the current angle to which the door can be opened, and monitoring a change in that value as the vehicle moves along path 108. For instance, when door 102 is fully opened, it may be opened to 80 degrees. The operator 120 of vehicle 100 may set the minimum open door angle to 45 degrees. As vehicle 100 travels along path 108 and reaches the position shown in FIG. 1B, processor 110 may determine that the open door angle would be less than 45 degrees if the vehicle continues along path 108.

Processor 110 may then pause execution of the remote parking operation responsive to determining via the sensors 104 that the door 102 is prevented from opening to the corresponding minimum door angle. In some examples, this may include pausing execution a short time before the door is prevented from opening to the minimum open door angle. Further, in some cases the minimum open door angle may be set to a slightly larger value (e.g., 46 degrees), such that the vehicle can pause execution of the remote parking operation when the door is prevented from opening to 46 degrees, yet is still able to open to 45 degrees as requested by the operator.

In some examples, there may be a threshold stopping time or stopping distance required by the vehicle to stop during execution of the remote parking operation. As such, processor 110 may be configured to pause execution of the remote parking operation responsive to determining that the door will be prevented from opening to the minimum open door angle after the threshold stopping time (e.g., the processor may add a threshold delay such that the vehicle stops moving before it reaches the position at which the door is prevented from opening to the minimum open door angle).

Pausing execution of the remote parking operation may include stopping the vehicle movement, and waiting for an additional command or input in order to continue execution.

In some examples, processor 110 may also provide an alert to the occupant that the remote parking operation has been paused, and that the occupant should exit the vehicle before the remote parking operation will continue. This gives the occupant the opportunity to exit the vehicle at the last possible moment during the remote parking operation before the door will be prevented from opening to the minimum open door angle. This provides the occupant with the least amount of time outside the vehicle exposed to bad weather or other adverse conditions.

Processor 110 may then continue the remote parking operation after receiving or responsive to receiving one or more inputs, such as from remote computing device 122. In some examples, the additional input may be from the detection of opening and closing of a door, such as the door corresponding to the minimum open door angle which caused the vehicle to pause execution of the remote parking operation. Alternatively, the input may come from the user interface 112. The operator may allow a rear passenger to exit the vehicle and close the door, and then input a command via the user interface 112 to continue execution of the remote parking operation.

In some examples, performing a remote parking operation may require continuous input from an operator. This may be done via the remote computing device 122, wherein operator 120 presses a button the remote computing device to cause the remote parking operation to begin or continue after pausing.

In the event only one door of the vehicle is indicated as corresponding to an occupied seat, processor 110 may finish the remote parking procedure after receiving the additional input. This is shown in FIG. 1C.

FIGS. 2A-2D illustrate a second scenario similar to that shown in FIGS. 1A-1C, however vehicle 200 in FIGS. 2A-2D includes an operator in the driver's seat and a passenger in the rear right seat. As such, when performing the remote parking operation there are two doors that have separate minimum open door angles, and the vehicle pauses and continues the operation two times.

As can be seen in FIGS. 2A-D, the vehicle begins the remote parking operation by determining and following the vehicle path 208. The remote parking operation then continues until a processor of vehicle 200 determines that vehicle 200 should pause to allow first door 202A to open to the first minimum open door angle 206A. The passenger 220A may then exit the vehicle and close door 206A. This is shown in FIG. 2B.

The remote parking operation may then continue as shown in FIG. 2C responsive to receiving an additional input (e.g., opening and closing of door 206A, input from a remote computing device of the operator, a user interface of vehicle 200, or some other source), until the processor of vehicle 200 determines that vehicle 200 should pause to allow second door 202B to open to the second minimum open door angle 206B. Operator 220B may then exit the vehicle and close door 206B. Operator 220B may also provide appropriate input via a remote computing device 222 to cause the vehicle 200 to continue the remote parking operation. Vehicle 200 may then continue the remote parking operation and finish as shown in FIG. 2D.

In some examples the position along paths 108 and/or 208 at which the vehicle stops and pauses the remote parking operation may be predetermined. For instance, the sensors 104 may be used to predict the position along the path 108 and/or 208 at which the vehicle may have to stop. These predicted positions may then be used to pause the operation of the remote parking operation. In these cases, the sensors 104 may or may not continuously monitor the position of the vehicle relative to the surroundings.

In some examples, during execution of the procedures disclosed herein, the operator may be provided with status updates as the vehicle proceeds to execute the remote parking operation. For instance, the operator may be provided information regarding the current angle to which one or more vehicle doors can open, such as a percentage the door(s) can be opened, a countdown to when the vehicle will pause execution to allow the occupant to exit, a scale of ease of exit based on one or more known characteristics of the occupant, corresponding minimum open door angle, and objects in the environment, and more.

Further, while examples are disclosed herein with reference to a remote parking operation, it should be understood that the concepts disclosed herein may be applicable to other vehicle operations, and any situation in which an operator may wish to perform an automatic assist or actively controlled maneuver for which the operator must leave the vehicle to complete the task remotely. This may include operations such as a remote trailer assist maneuver, in which the vehicle automatically moves to assist the operator in attaching a trailer.

FIG. 3 illustrates an example block diagram 300 showing electronic components of vehicles 100 and 200, according to some embodiments. In the illustrated example, the electronic components 300 include an on-board computing system 302, an infotainment head unit 320, a communications module 330, sensors 340, electronic control unit(s) 350, and vehicle data bus 360.

The on-board computing system 202 may include a microcontroller unit, controller or processor 110 and memory 312. The processor 110 may be any suitable processing device or set of processing devices such as, but not limited to, a microprocessor, a microcontroller-based platform, an integrated circuit, one or more field programmable gate arrays (FPGAs), and/or one or more application-specific integrated circuits (ASICs). The memory 312 may be volatile memory (e.g., RAM including non-volatile RAM, magnetic RAM, ferroelectric RAM, etc.), non-volatile memory (e.g., disk memory, FLASH memory, EPROMs, EEPROMs, memristor-based non-volatile solid-state memory, etc.), unalterable memory (e.g., EPROMs), read-only memory, and/or high-capacity storage devices (e.g., hard drives, solid state drives, etc.). In some examples, the memory 312 includes multiple kinds of memory, particularly volatile memory and non-volatile memory.

The memory 312 may be a non-transitory computer-readable media on which one or more sets of instructions, such as the software for operating the methods of the present disclosure, can be embedded. The instructions may embody one or more of the methods or logic as described herein. For example, the instructions reside completely, or at least partially, within any one or more of the memory 312, the computer-readable medium, and/or within the processor 110 during execution of the instructions.

The terms “non-transitory computer-readable medium” and “computer-readable medium” include a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. Further, the terms “non-transitory computer-readable medium” and “computer-readable medium” include any tangible medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a system to perform any one or more of the methods or operations disclosed herein. As used herein, the term “computer readable medium” is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals.

The infotainment head unit 320 may provide an interface between vehicle 100 and a user. The infotainment head unit 320 may include one or more input and/or output devices, such as display 322, and user interface 112, to receive input from and display information for the user(s). The input devices may include, for example, a control knob, an instrument panel, a digital camera for image capture and/or visual command recognition, a touch screen, an audio input device (e.g., cabin microphone), buttons, or a touchpad. The output devices may include instrument cluster outputs (e.g., dials, lighting devices), actuators, a heads-up display, a center console display (e.g., a liquid crystal display (LCD), an organic light emitting diode (OLED) display, a flat panel display, a solid state display, etc.), and/or speakers. In the illustrated example, the infotainment head unit 320 includes hardware (e.g., a processor or controller, memory, storage, etc.) and software (e.g., an operating system, etc.) for an infotainment system (such as SYNC® and MyFord Touch® by Ford®, Entune® by Toyota®, IntelliLink® by GMC®, etc.). In some examples the infotainment head unit 320 may share a processor with on-board computing system 302. Additionally, the infotainment head unit 320 may display the infotainment system on, for example, a center console display of vehicle 100.

Communications module 330 may include wired or wireless network interfaces to enable communication with one or more internal or external systems, devices, or networks. Communications module 330 may also include hardware (e.g., processors, memory, storage, etc.) and software to control the wired or wireless network interfaces. In the illustrated example, communications module 330 may include a Bluetooth® module, a GPS receiver, a dedicated short range communication (DSRC) module, an Ultra-Wide Band (UWB) communications module, a WLAN module, and/or a cellular modem, all electrically coupled to one or more respective antennas.

The cellular modem may include controllers for standards-based networks (e.g., Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Code Division Multiple Access (CDMA), WiMAX (IEEE 802.16m); and Wireless Gigabit (IEEE 802.11ad), etc.). The WLAN module may include one or more controllers for wireless local area networks such as a Wi-FI® controller (including IEEE 802.11 a/b/g/n/ac or others), a Bluetooth® controller (based on the Bluetooth® Core Specification maintained by the Bluetooth® Special Interest Group), and/or a ZigBee® controller (IEEE 802.15.4), and/or a Near Field Communication (NFC) controller, etc. Further, the internal and/or external network(s) may be public networks, such as the Internet; a private network, such as an intranet; or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to, TCP/IP-based networking protocols.

Communications module 330 may also include a wired or wireless interface to enable direct communication with an electronic device (such as remote computing device 122). An example DSRC module may include radio(s) and software to broadcast messages and to establish direct connections between vehicles and between vehicles and one or more other devices or systems. DSRC is a wireless communication protocol or system, mainly meant for transportation, operating in a 5.9 GHz spectrum band.

Sensors 340 may be arranged in and around vehicle 100 and/or 200 in any suitable fashion. Sensors 340 may include backup camera 342, and one or more sensors 104 such as those described above. In some examples, backup camera 232 and/or one or more of a RADAR and/or LIDAR may be used to determine a position, speed, and heading of vehicle 100 with respect to an external object, such as nearby cars or structures. This may assist in determining whether or not one or more doors are able to open to a minimum open door angle.

The ECUs 350 may monitor and control subsystems of vehicles 100 and 200. ECUs 350 may communicate and exchange information via vehicle data bus 360. Additionally, ECUs 350 may communicate properties (such as, status of the ECU 350, sensor readings, control state, error and diagnostic codes, etc.) to and/or receive requests from other ECUs 350. Some vehicles may have seventy or more ECUs 350 located in various locations around the vehicle communicatively coupled by vehicle data bus 360. ECUs 350 may be discrete sets of electronics that include their own circuit(s) (such as integrated circuits, microprocessors, memory, storage, etc.) and firmware, sensors, actuators, and/or mounting hardware. In the illustrated example, ECUs 350 may include the telematics control unit 352 and the body control unit 354.

The telematics control unit 352 may control tracking of the vehicle 100, for example, using data received by a GPS receiver, communication module 330, and/or one or more sensors 340. The body control unit 354 may control various subsystems of the vehicle. For example, the body control unit 354 may control a trunk latch, windows, power locks, power moon roof control, an immobilizer system, and/or power mirrors, etc.

Vehicle data bus 360 may include one or more data buses, in conjunction with a gateway module, that communicatively couple the on-board computing system 302, infotainment head unit 320, communications module 330, sensors 340, ECUs 350, and other devices or systems connected to the vehicle data bus 360. In some examples, vehicle data bus 360 may be implemented in accordance with the controller area network (CAN) bus protocol as defined by International Standards Organization (ISO) 11898-1. Alternatively, in some examples, vehicle data bus 360 may be a Media Oriented Systems Transport (MOST) bus, or a CAN flexible data (CAN-FD) bus (ISO 11898-7) or a combination of CAN and CAN-FD.

FIG. 4 illustrates a flowchart of an example method 400 according to embodiments of the present disclosure. Method 400 may enable a vehicle occupant to maximize his or her time inside the vehicle during a remote parking operation, for example where there is adverse weather, by pausing execution of the remote parking operation at the last moment before the occupant is prevented from exiting the vehicle.

The flowchart of FIG. 4 is representative of machine readable instructions that are stored in memory (such as memory 212) and may include one or more programs which, when executed by a processor (such as processor 110) may cause vehicle 100 and/or 200 to carry out one or more functions described herein. While the example program is described with reference to the flowchart illustrated in FIG. 4, many other methods for carrying out the functions described herein may alternatively be used. For example, the order of execution of the blocks may be rearranged or performed in series or parallel with each other, blocks may be changed, eliminated, and/or combined to perform method 400. Further, because method 400 is disclosed in connection with the components of FIGS. 1-3, some functions of those components will not be described in detail below.

Method 400 may start at block 402. At block 404, method 400 may include determining one or more occupied seats of the vehicle. This can include receiving input at a user interface of the vehicle indicating which seats are occupied by a passenger. Alternatively, the operator may input one or more unoccupied seats where the vehicle operator wishes to have a door opened prior to completing the remote parking operation, so as to remove a large box or object from the seat. This may be referred to as “selected seats”. In other examples, one or more vehicle sensors may automatically determine whether one or more seats are occupied. For example, the sensors may include pressure sensors coupled to the seats, and/or camera(s) configured to detect the presence of an occupant.

At block 406, method 400 may include determining a minimum open door angle for each door corresponding to an occupied seat determined in block 404. As noted above, the minimum open door angle may correspond to the angle at which the door opens to allow an occupant to comfortably enter and exit the vehicle. The minimum open door angle for a given door may be a default value, or may be set or changed by an occupant. In some examples, the minimum open door angle may correspond to a profile associated with a given occupant, and the vehicle may determine a minimum open door angle for a door corresponding to the occupant based on the profile of the occupant.

At block 408, method 400 may include determining a vehicle path for a remote parking operation. The vehicle path may be a path along which the vehicle is expected to intended to travel when executing the remote parking operation.

At block 410, method 400 may include initiating execution of the remote parking operation. During execution, the vehicle may control the movement of the vehicle by automatically causing the vehicle to accelerate, decelerate, turn, brake, and perform one or more other vehicle functions.

At block 412, method 400 may include determining whether a door (e.g., one or more of the doors determined at block 406) is prevented from opening to its corresponding open door angle. This may be done by making use of data gathered by one or more vehicle sensors, including cameras, ultrasonic sensors, radar, etc. As the remote parking operation is executed, the vehicle may travel along the determined vehicle path. Where there are objects in the environment, such as adjacent vehicles, the door may eventually be prevented from opening fully, and/or opening to the minimum open door angle.

If, during execution of the remote parking operation, the door(s) can still be opened to the minimum open door angle, method 400 may include waiting at block 412 for a change in status, and continuing to execute the remote parking operation.

However if a door is prevented from opening to its corresponding minimum open door angle, method 400 may proceed to block 414. At block 414, method 400 may include pausing execution of the remote parking operation. The vehicle may be controlled to stop movement, in order to allow the occupant corresponding to the door to open the door and exit the vehicle.

At block 416, method 400 may include determining whether input has been received to continue execution of the remote parking operation. The input may include determining that the door has been opened and closed, and/or that some time delay has passed, or that the area surrounding the vehicle is free from obstacles (such as the occupant who recently exited). In some examples, the input may be received from a remote computing device, such as an occupant's smart phone or other device used to control the remote parking operation.

If the input to continue has been received, method 400 may continue to block 418. At block 418, method 400 may include determining whether all seats determined to be occupied (at block 404) are now unoccupied. This can also include determining whether all doors that correspond to the occupied seats have been opened and closed. In other words, block 418 may include determining whether all occupants have had an opportunity to exit before their corresponding door is prevented from opening to its minimum open door angle.

If there are still one or more occupants in the vehicle, method 400 may proceed to block 420. AT block 420, method 400 may include continuing execution of the remote parking operation, and proceeding back to block 412. The process may then repeat for each additional door indicated by the occupants as corresponding to a door intended to be opened prior to completing the remote parking operation.

When all seats are unoccupied, or when all doors indicated by the driver have been afforded the opportunity to open and close to their minimum open door angle prior, method 400 may proceed to block 422. At block 422, method 400 may include finishing execution of the remote parking operation. This may include fully parking the vehicle in its intended parking spot, even if one or more doors are thereby prevented from opening to their corresponding minimum open door angle. Method 400 may then end at block 424.

In this application, the use of the disjunctive is intended to include the conjunctive. The use of definite or indefinite articles is not intended to indicate cardinality. In particular, a reference to “the” object or “a” and “an” object is intended to denote also one of a possible plurality of such objects. Further, the conjunction “or” may be used to convey features that are simultaneously present instead of mutually exclusive alternatives. In other words, the conjunction “or” should be understood to include “and/or”. The terms “includes,” “including,” and “include” are inclusive and have the same scope as “comprises,” “comprising,” and “comprise” respectively.

The above-described embodiments, and particularly any “preferred” embodiments, are possible examples of implementations and merely set forth for a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiment(s) without substantially departing from the spirit and principles of the techniques described herein. All modifications are intended to be included herein within the scope of this disclosure and protected by the following claims.

Claims

1. A vehicle comprising: a door;a sensor; anda processor configured to: determine, based on a user input received by a vehicle user interface, a minimum open door angle for an occupant to exit;determine a vehicle path for execution of a remote parking operation; andresponsive to determining via the sensor during execution of the remote parking operation, and before the vehicle has reached a final parking position, that the door is prevented from opening to the minimum door angle, pause execution of the remote parking operation.

2. The vehicle of claim 1, wherein the processor is further configured to provide an alert indicating the occupant should exit the vehicle before the vehicle will proceed to the final parking position.

3. The vehicle of claim 1, wherein the processor is further configured to: determine that the door has opened and closed; and responsively resume execution of the remote parking operation.

4. The vehicle of claim 1, wherein the processor is further configured to: determine a first door and a second door corresponding to a first occupant and a second occupant;determine a first minimum open door angle for the first door, and a second minimum open door angle for the second door;responsive to determining via the sensor during execution of the remote parking operation that the first door is prevented from opening to the first minimum door angle, pause execution of the remote parking operation;resume execution of the remote parking operation responsive to determining that the first door has opened and closed;responsive to determining via the sensor during execution of the remote parking operation that the second door is prevented from opening to the second minimum door angle, pause execution of the remote parking operation; andresume execution of the remote parking operation responsive to determining that the second door has opened and closed.

5. The vehicle of claim 1, wherein the processor is further configured to continue execution of the remote parking operation responsive to receiving input from the occupant via a remote computing device.

6. The vehicle of claim 1, wherein the processor is further configured to receive input indicating which door corresponds to the occupant.

7. The vehicle of claim 1, wherein the processor is further configured to determine the minimum door angle based on a detected occupant identity.

8. The vehicle of claim 7, wherein the detected occupant identity is determined based on an occupant profile stored on a key FOB detected by the vehicle.

9. The vehicle of claim 1, wherein the processor is further configured to: detect a current open door angle of the door; andstore the current open door angle in a vehicle memory as the minimum door angle.

10. A method comprising: determining, based on a user input received by a vehicle user interface, a minimum open door angle of a door for an occupant to exit a vehicle;determining a vehicle path for execution of a remote parking operation; andresponsive to determining via a sensor during execution of the remote parking operation, and before the vehicle has reached a final parking position, that the door is prevented from opening to the minimum open door angle, pausing execution of the remote parking operation.

11. The method of claim 10, further comprising providing an alert indicating the occupant should exit the vehicle before the vehicle will proceed to the final parking position.

12. The method of claim 10, further comprising: determining that the door has opened and closed; and responsively resuming execution of the remote parking operation.

13. The method of claim 10, further comprising: determining a first door and a second door corresponding to a first occupant and a second occupant;determining a first minimum open door angle for the first door, and a second minimum open door angle for the second door;responsive to determining via the sensor during execution of the remote parking operation that the first door is prevented from opening to the first minimum door angle, pausing execution of the remote parking operation;resuming execution of the remote parking operation responsive to determining that the first door has opened and closed;responsive to determining via the sensor during execution of the remote parking operation that the second door is prevented from opening to the second minimum door angle, pausing execution of the remote parking operation; andresuming execution of the remote parking operation responsive to determining that the second door has opened and closed.

14. The method of claim 10, further comprising resuming execution of the remote parking operation responsive to receiving input from the occupant via a remote computing device.

15. The method of claim 10, further comprising receiving input indicating which door corresponds to the occupant.

16. The method of claim 10, wherein the detected occupant identity is determined based on an occupant profile stored on a key FOB detected by the vehicle.

17. The method of claim 10, further comprising: detecting a current open door angle of the door; andstoring the current open door angle in a vehicle memory as the minimum door angle.

18. The method of claim 10, further comprising determining the minimum door angle based on a detected occupant identity.