Intelligent vehicles and control logic for speed horizon generation and transition during one-pedal driving

Abstract

Method (100) for operating a motor vehicle (10), wherein the motor vehicle (10) comprises a powertrain operable for propelling the motor vehicle (10) and a driver input device operable for receiving vehicle control inputs from a driver of the motor vehicle (10), the method comprising: receiving (103), via a vehicle control unit from the driver via the driver input device, an acceleration command for the powertrain of the motor vehicle (10); determining (105), via the vehicle control unit from an acceleration table, an acceleration or torque request corresponding to the driver's acceleration command; and shaping (107) the acceleration or torque request based on an unsteady acceleration table.Determine (109, 111) compensated and uncompensated accelerations from the shaped requirement, wherein the compensated acceleration is based on an estimated road gradient and an estimated vehicle mass, and the uncompensated acceleration is based on a road gradient of zero and a nominal vehicle mass or the estimated vehicle mass;Calculating (115) a final velocity horizon profile (215) as: a velocity-controlled velocity profile based on uncompensated acceleration when the vehicle speed of the motor vehicle (10) is at a calibratable or near-zero vehicle speed, a mixture-controlled velocity profile based on a mixture of compensated and uncompensated accelerations when the vehicle speed is above the near-zero vehicle speed and below a predefined threshold vehicle speed, and a torque-controlled velocity profile based on uncompensated acceleration when the vehicle speed is above the predefined threshold vehicle speed;and sending a command signal via the vehicle control system to the drivetrain to output a requested axle torque based on the calculated final speed horizon profile.

Description

This description refers generally to powertrain control systems for motor vehicles. Specifically, aspects of this description relate to speed horizon generation and transition for one-pedal driving in hybrid-electric and fully electric vehicles. Modern production vehicles, such as the contemporary automobile, are originally equipped with a powertrain that propels the vehicle and supplies its onboard electronics. In automobiles, for example, the powertrain typically consists of a drive motor that transmits the drive torque to the vehicle's drive system (e.g., differential, axles, wheels, etc.) via an automatic or manual transmission. Historically, motor vehicles were powered by internal combustion engines (ICEs) due to their availability, relatively low cost, light weight, and high efficiency. Examples of such engines include compression-ignition (CI) diesel engines, spark-ignition (SI) gasoline engines, two-, four-, and six-stroke designs, and rotary engines.Hybrid electric and fully electric vehicles (collectively referred to as "electrically powered vehicles"), on the other hand, use alternative energy sources to power the vehicle, thus minimizing or eliminating dependence on a fossil fuel-based engine for traction. A fully electric vehicle (FEV) – colloquially referred to as an "electric car" – is an electrically powered vehicle configuration that completely eliminates the internal combustion engine and its associated peripheral powertrain components, using a rechargeable energy storage system (RESS) and a traction motor to propel the vehicle. In a battery-powered FEV, the engine assembly, fuel supply system, and exhaust system of an internal combustion engine-based vehicle are replaced by one or more traction motors, a traction battery pack, and battery cooling and charging hardware. Hybrid electric vehicle (HEV) powertrains, on the other hand, utilize multiple traction sources to propel the vehicle, typically employing an internal combustion engine in conjunction with a battery- or fuel cell-powered traction motor.Since electric hybrid vehicles can draw their power from sources other than the engine, HEV engines can be switched off completely or partially while the vehicle is driven by the electric motor(s). As vehicle processing, communication, and sensor capabilities continue to improve, manufacturers will offer new and enhanced automated driving functions, with the ultimate goal of producing fully autonomous vehicles capable of operating across a range of vehicle types in both urban and rural environments. Such automated and autonomous functions may include adaptive cruise control (ACC), lane keeping assist and automated steering (“auto steer”), collision avoidance systems (CAS), intelligent parking assist systems (IPAS), and other advanced driver assistance systems (ADAS). Original equipment manufacturers (OEMs) are moving toward vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) “talking” cars with higher levels of driving automation, employing autonomous control systems to enable vehicle routing, including steering, lane changes, scenario planning, and more.Automated route generation systems utilize vehicle tracking and dynamics sensors, map and road condition data, and path prediction algorithms to derive routes with automatic prediction of lane center and lane changes. Computer-aided rerouting techniques automate the construction of alternative routes that can be updated based on real-time and virtual vehicle data. Many cars today are equipped with in-vehicle navigation systems that use a GPS (Global Positioning System) transceiver in conjunction with navigation software and geolocation mapping services to obtain information about road topography, traffic, and speed limits in conjunction with the vehicle's current location and surroundings. Autonomous driving and advanced driver assistance systems are often able to adapt automated driving maneuvers based on the road information received from the onboard navigation system. Ad-hoc network-based ADAS, for example, can use GPS and map data in conjunction with multi-hop geocast V2V and V2I data exchange to enable automated vehicle maneuvers and powertrain control.During both assisted and non-assisted vehicle operation, the resident navigation system can identify a recommended route based on an estimated shortest travel time or distance between the route origin and destination for a given journey. This recommended route can then be displayed as a map or as turn-by-turn directions on a geocoded and annotated map, with optional voice commands provided by the vehicle's audio system. DE 10 2016 206 814 A1 describes an improved vehicle control device that controls a vehicle without causing the vehicle occupants to experience any sensation of abnormality during acceleration and deceleration, and which achieves optimal control of the operating torque of a machine. A vehicle driving control sequence sets the target operating torque of the vehicle and determines a target machine torque and target machine speed from the target operating torque. Machine control is then performed according to the target parameters. To calculate each target parameter of the machine, the output torque of a torque converter is first calculated from the target operating torque to determine the operating state of a torque converter lock-up clutch. Furthermore, each target parameter is calculated according to a control rule that is set depending on the operating state of the torque converter lock-up clutch. DE 43 28 893 B4 describes a method and a device for accurately estimating gradients and for eliminating gradient estimation errors, taking into account error-causing conditions. The gradient on which the vehicle is traveling is estimated based on the vehicle speed and the engine speed. The result is fed into the gradient estimation unit via a low-pass filter and subsequently into the navigation unit. A noise suppressor is provided at the output of the gradient estimation unit to suppress interfering noise, for example, during gear changes or for a certain period after the gear change is completed by retrieving the "gear change" information from the automatic transmission control unit. The previously estimated gradient value is retained during the noise suppression period. DE 102 03 954 A1 describes a method for operating a motor vehicle, comprising the following steps: Detecting a propulsion request for the motor vehicle specified by a driver; Determining an adjustment parameter depending on a total vehicle weight and / or a road gradient; Determining a drive motor torque depending on the adjustment parameter and the propulsion request; Operating a drive motor of the motor vehicle depending on the drive motor torque. Accordingly, the object of the present invention is to provide an improved speed horizon generation and transmission for one-pedal driving. The problem is solved by the subject matter of the independent claim. This paper presents feedback-based vehicle control systems with associated control logic for speed horizon estimation, methods for manufacturing and operating such systems, as well as intelligent electrically powered vehicles with speed horizon generation and transition for improved one-pedal driving (OPD). As an example, a method for deriving a speed horizon for vehicle deceleration / acceleration control during OPD operation is presented, which uses predefined drivability targets as described by a vehicle-calibrated acceleration map and a vehicle-calibrated transient acceleration map. As used herein, the term "speed horizon" can be defined by an estimated speed behavior of a given vehicle (e.g.,Predicted future trajectories for achieving a target vehicle speed are derived over a predefined period (the "horizon"). In addition to achieving the vehicle's drivability goals, the derived speed horizon can be a function of a predefined set of vehicle parameters, such as an effective road load acting on the vehicle. This load is derived from nominal road load forces, which are created using a road load equation with coefficients representing kinetic friction, rolling friction, and drag, in conjunction with forces acting on the vehicle due to mass and gravity. The final derived speed profile can include a sequence of estimated future vehicle trajectories, which are used by a vehicle motion controller (VMC) to selectively modulate powertrain actuator commands based on future desired trajectories and measurements.The speed profile estimation and transition for optimized OPD operation can incorporate the following variables to achieve improved vehicle propulsion: (1) a driver-desired torque and / or acceleration; (2) a nominal road load based on vehicle parameters; (3) a term based on the effective road load (gradient, mass, etc.); and / or (4) any braking force present. These variables can be converted into one or more vehicle acceleration requests (e.g., using a nominal vehicle mass) and used to calculate a speed trajectory profile for controlling vehicle propulsion. This information can also be used to create a future speed profile horizon for use by the VMC as part of a feedback protocol.During speed horizon estimation, the effective road load can be used to set its overall effect to zero when switching from a speed control protocol to a torque control protocol. Speed ​​control can be defined as a range where nominal speed trajectory behavior is desired. In contrast, torque control can be defined as a range where the vehicle's drive torque is essentially or entirely defined by pedal maps. Among the accompanying benefits of at least some of the revealed concepts is an intelligent OPD-enabled vehicle with optimized speed horizon derivation, achieving a vehicle speed of zero with zero pedal travel and consistent tip-in response from zero speed or other desired speeds. Further benefits could include, for example, a VMC capable of interpreting driver input in both speed-dominated domains (low vehicle speeds) and torque-dominated domains (high vehicle speeds) to enable smooth operation and seamless transitions between domains.Interpreting the speed horizon can also enable a consistent pedal response regardless of road conditions (gradient) and vehicle mass, while integrating OPD operation with driver-controlled braking is possible without interrupting vehicle operation. In addition to the aforementioned advantages, the disclosed features can also help reduce system complexity and calibration time, improve powertrain response time, and prevent pedal dead when driving uphill and pedal jolt when driving downhill. Aspects of this description relate to the vehicle system's control logic, closed-loop control techniques, and computer-readable media (CRM) for improved speed horizon generation and transmission. An example presents a method for operating a motor vehicle, including ICE, HEV, and FEV powertrain configurations.The method according to the invention comprises, in any order and in any combination with any of the options and features disclosed above and below: receiving an acceleration command for the powertrain of the motor vehicle via a vehicle control unit from a driver via a driver input device; determining a torque and / or acceleration request corresponding to the driver's acceleration command via the vehicle control unit from a stored acceleration table; and shaping the torque / acceleration request based on a stored transient acceleration table.Determining compensated and uncompensated acceleration requirements from the shaped requirement, wherein the compensated acceleration requirement is based on an estimated road gradient and an estimated vehicle mass, and the uncompensated acceleration requirement is based on a zero road gradient and a nominal vehicle mass or the estimated vehicle mass. In one embodiment, the method also includes: calculating a final speed horizon profile as: a speed-controlled speed profile based on uncompensated acceleration when the vehicle speed is close to zero or another calibratable speed; a mixture-controlled speed profile based on a mixture of compensated and uncompensated accelerations when the vehicle speed is above close to zero and below a predefined threshold vehicle speed; and a torque-controlled speed profile based on uncompensated acceleration when the vehicle speed is above the predefined threshold vehicle speed.and transmitting one or more command signals via the vehicle control system to the powertrain to output a requested axle torque based on the calculated final speed horizontal profile. Further use cases of this description are directed toward closed vehicle control systems and intelligent motor vehicles with improved speed horizon generation and transition, e.g., for one-pedal driving. As used herein, the terms "vehicle" and "motor vehicle" can be used interchangeably and synonymously to include any relevant vehicle platform, such as passenger vehicles (ICE, HEV, FEV, fuel cell, fully and partially autonomous vehicles, etc.), commercial vehicles, industrial vehicles, tracked vehicles, all-terrain and off-road vehicles (ATVs), motorcycles, agricultural equipment, watercraft, aircraft, etc. By way of example, a motor vehicle comprises a vehicle body with a passenger compartment, several road wheels mounted on the vehicle body, and other standard original equipment. In electric vehicle applications, one or more electric drive motors operate alone (e.g.,in FEV powertrains) or in conjunction with an internal combustion engine assembly (e.g., in HEV powertrains) to selectively drive one or more of the road wheels and thereby propel the vehicle. A driver input device, which may be in the form of a single accelerator pedal, both an accelerator and a brake pedal, a joystick control, or a similarly suitable input device, is capable of receiving vehicle control inputs from the driver. To continue the discussion of the example above, the vehicle also includes an in-vehicle or external vehicle control unit programmed to receive a powertrain acceleration command from the driver via the driver input device and determine a torque and / or acceleration request from a stored acceleration table that corresponds to the driver's acceleration command. The vehicle control unit then shapes the request based on a stored transient acceleration table and simultaneously determines compensated and uncompensated acceleration requests from the shaped request. The compensated acceleration request is based on an estimated road gradient and an estimated vehicle mass, while the uncompensated acceleration is based on a road gradient of zero and a nominal vehicle mass or the estimated vehicle mass.The vehicle control unit then calculates a final speed horizon profile as: a speed-controlled speed profile based on uncompensated acceleration when the vehicle speed is close to zero; a mixture-controlled speed profile based on a mixture of compensated and uncompensated accelerations when the vehicle speed is above near zero and below a predefined threshold vehicle speed; and a torque-controlled speed profile based on uncompensated acceleration when the vehicle speed is above the predefined threshold vehicle speed. The control unit commands one or more actuators of the vehicle powertrain (e.g.,to output a requested axle torque to the drive motor(s) based on the calculated final speed horizontal profile. For each of the disclosed systems, methods, and vehicles, the vehicle control unit can receive one or more sensor signals from a speed sensor indicating the real-time vehicle speed. In this case, the control unit selects a vehicle control mode, either a speed control mode or a torque control mode, based on the real-time vehicle speed, the position of the driver input device, the rate of change of the driver input device position, and / or a measured road inclination. The command signal(s) transmitted to the powertrain can be based, at least in part, on the selected vehicle control mode. Optionally, the calculation of the final speed horizon profile, as a speed-controlled speed profile, can also be based on the real-time vehicle speed.Optionally, the final speed horizon profile can be calculated as a torque-controlled speed profile by eliminating ("fading out") the uncompensated acceleration from the mix when the vehicle speed exceeds a preset high vehicle speed. The final speed horizon profile can also be calculated as a speed-controlled speed profile based on a road gradient compensation value. For each of the disclosed systems, methods, and vehicles, the vehicle control unit can receive a deceleration command from the driver via the driver input device to reduce the vehicle speed and simultaneously determine a deceleration torque request corresponding to the driver's deceleration command based on the estimated road gradient and the estimated vehicle mass. In this case, the calculation of the final speed horizon profile as a torque-controlled speed profile can still be based on the deceleration torque request. Optionally, the vehicle control unit can receive one or more sensor signals from a brake sensor indicating a real-time braking torque applied to one or more of the vehicle's road wheels; the requested axle torque can be modified based on the real-time braking torque. For each of the disclosed systems, methods, and vehicles, a control unit can predict a future vehicle speed trajectory profile for the motor vehicle using a two-track bicycle model or a similarly suitable body model of the motor vehicle, and modify the requested axle torque to minimize any difference between this future vehicle speed trajectory profile and the final speed horizon profile. As a further option, a control unit can calculate a nominal road load vehicle force and an effective road load based on the estimated road gradient and the estimated vehicle mass. In this case, the calculation of the final speed horizon profile, as the torque-controlled speed profile, can be further based on the nominal road load vehicle force and the effective road load.The driver input device for receiving driver acceleration and deceleration commands may consist of a single accelerator pedal; as such, the motor vehicle may lack a brake pedal, and the requested axle torque may be part of a braking maneuver in a one-pedal driving operation. For each of the disclosed systems, methods, and vehicles, the vehicle control unit can receive the following: an estimated vehicle mass of the motor vehicle with a current payload from a mass estimation module; and an estimated road gradient of a road segment currently being traveled by the motor vehicle from a gradient estimation module. As a further option, the acceleration tables mentioned above can include an acceleration map file stored in memory, accessible by the control unit, which maps the vehicle speed and acceleration to the torque output of the powertrain. In this context, the transient acceleration tables mentioned above can include a stored map file for transient acceleration behavior, accessible by the control unit, which defines transient ranges between adjacent powertrain acceleration / torque outputs in the file.The calculation of a final velocity horizon profile may involve determining a force horizon based on a torque horizon, a braking demand horizon, and a nominal road load horizon, repeated for a predefined number (N) of steps in a predefined horizon. The above summary does not represent every embodiment or aspect of this description. Rather, the features and advantages mentioned above, as well as other features and associated advantages of this description, will be readily apparent from the following detailed description of illustrative examples and modes of implementation of the present description when considered in conjunction with the accompanying figures and the attached claims. Furthermore, this description expressly includes all combinations and subcombinations of the elements and features illustrated above and below. Fig.Figure 1 is a schematic representation of a representative electrically powered vehicle with a network of in-vehicle control units (controllers), sensor devices, and communication devices for performing speed horizon generation and domain-to-domain transitions for optimized one-pedal driving according to aspects of the disclosed concepts. Figure 2 is a flowchart illustrating a representative speed horizon estimation and transition control protocol that can correspond to stored instructions executable by a resident or remote controller, control logic circuit, programmable logic controller, or other integrated circuit (IC) or network of devices in accordance with aspects of the disclosed concepts.Figure 3 is a flowchart illustrating a representative velocity profile blending control protocol for velocity horizon estimation, which can correspond to memory-stored instructions executable by a resident or remote control unit, control logic circuit, programmable control unit, or other integrated circuit (IC) or network of devices according to aspects of the disclosed concepts. Figure 4 is a flowchart illustrating another representative velocity profile blending control protocol for velocity horizon estimation, which can correspond to stored instructions executable by a resident or remote control unit, control logic circuit, programmable control unit, or other integrated circuit (IC) or network of devices according to aspects of the disclosed concepts. With reference to the figures, in which the same reference numerals refer to the same features in the different views, Fig. 1 shows a representative automobile, generally designated 10, which is depicted here for discussion purposes as a sedan-style, electrically powered passenger vehicle. The automobile 10 shown—also referred to here as a “motor vehicle” or simply “vehicle”—is merely an exemplary application with which novel aspects of this description can be put into practice. Similarly, the integration of the present concepts into a fully electric vehicle powertrain should also be appreciated as a non-restrictive implementation of the disclosed novel features.As such, it will be understood that aspects and features of this description can be applied to other powertrain architectures, implemented for any logically relevant type of vehicle, and used for both OPD and non-OPD applications. Furthermore, only selected components of motor vehicles and vehicle control systems are shown and described in detail here. Nevertheless, the vehicles and systems described below may contain numerous additional and alternative features and other available peripheral components to perform the various methods and functions of this disclosure. The representative vehicle 10 of Fig. 1 is originally equipped with a vehicle telecommunications and information unit (“telematics”) 14, which communicates wirelessly (e.g., via cell towers, base stations, mobile switching centers, satellite services, etc.) with a remote or “off-board” cloud computing host service 24. Some of the other vehicle hardware components 16, generally shown in Fig. 1, include, by way of non-limiting examples, an electronic video display device 18, a microphone 28, one or more audio speakers 30, and various input controls 32 (e.g., buttons, knobs, pedals, switches, touchpads, joysticks, touchscreens, etc.). These hardware components 16 function, in part, as a human-machine interface (HMI) to enable a user to communicate with the telematics unit 14 and other systems and system components within the vehicle 10.The microphone 28 allows a vehicle occupant to input verbal or other acoustic commands; the vehicle 10 can be equipped with an embedded speech processing unit that uses software modules for audio filtering, processing, and analysis. Conversely, the loudspeaker 30 provides acoustic output to a vehicle occupant and can either be a standalone loudspeaker intended for use with the telematics unit 14 or it can be part of an audio system 22. The audio system 22 is operationally connected to a network interface 34 and an audio bus 20 to receive analog information and reproduce it as sound via one or more loudspeaker components. Communicatively coupled to the telematics unit 14 is a network connection interface 34, suitable examples of which include a twisted-pair / fiber optic Ethernet switch, an internal / external parallel / serial communication bus, a local area network (LAN) interface, a controller area network (CAN), a media-oriented system transmission (MOST), a local area link network (LIN) interface, and similar interfaces. Other suitable communication interfaces may be those that comply with ISO, SAE, and IEEE standards and specifications. The network connection interface 34 enables the vehicle hardware 16 to send and receive signals with each other and with various systems and subsystems, both within the vehicle body 12 (or "resident") and outside (or "remotely") the vehicle body 12. This allows the vehicle 10 to perform various vehicle functions, such as:The modulation of powertrain output, control of the vehicle transmission operation, selective activation of friction and regenerative braking systems, control of the vehicle steering, control of the charging and discharging of the vehicle's battery modules, and other automated driving functions. The telematics unit 14 receives and sends signals and data to / from, for example, a powertrain control module (PCM) 52, an ADAS module (Advanced Driver Assistance System) 54, a BPCM module (Battery Pack Control) 56, an SSIM module (Sensor System Interface) 58, a BSCM module (Brake System Control) 60, and various other vehicle control units, such as a TCM module (Transmission Control Module), ECM module (Engine Control Module), CCM module (Climate Control Module), etc. With continued reference to Fig. 1, the telematics unit 14 is an in-vehicle computing device that provides a mix of services both individually and through its communication with other networked devices. This telematics unit 14 generally consists of one or more processors 40, each of which can be implemented as a discrete microprocessor, an application-specific integrated circuit (ASIC), or a dedicated control module. The vehicle 10 can provide centralized vehicle control via a central processing unit (CPU) 36, which is operationally coupled with one or more electronic storage devices 38, each of which can take the form of a CD-ROM, a magnetic disk, an integrated circuit, flash memory, semiconductor memory (e.g., various types of RAM or ROM), etc., as well as a real-time clock (RTC) 42. Long-range vehicle communication capabilities with remote connected devices can be provided via one, more, or all of the cellular chipsets / components, a navigation and positioning chipset / component (e.g., GPS transceiver), or a radio modem, all of which are shown together in Figure 44. Short-range wireless connectivity can be provided via a near-field communication (NFC) wireless communication device 46 (e.g., a Bluetooth® unit or NFC transceiver), a dedicated short-range communication (DSRC) component 48, and / or a dual antenna 50. It should be understood that the vehicle 10 can be implemented without one or more of the components listed above or may optionally include additional components and functions as required for a particular end application.The various communication devices described above can be configured to exchange data as part of a periodic transmission in a V2V communication system or a vehicle-to-everything (V2X) communication system, e.g., vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P) and / or vehicle-to-device (V2D). The CPU 36 receives sensor data from one or more sensing devices, which may employ, for example, photodetection, radar, laser, ultrasound, optics, infrared, or other suitable technologies for automated driving operation, including short-range communication technologies such as DSRC or ultra-wideband (UWB). According to the example shown, the vehicle 10 can be equipped with one or more digital cameras 62, one or more distance sensors 64, one or more vehicle speed sensors 66, one or more vehicle dynamics sensors 68, and any necessary filtering, classification, fusion, and analysis hardware and software for processing raw sensor data. The type, placement, number, and interoperability of the distributed array of vehicle sensors can be individually or collectively adapted to a specific vehicle platform to achieve a desired level of autonomous vehicle operation. To propel the electrically powered vehicle 10, an electrified powertrain is capable of generating drive torque and transmitting it to one or more of the vehicle's wheels 26. The powertrain is generally represented in Fig. 1 by a rechargeable energy storage system (RESS), which may be in the form of a chassis-mounted traction battery pack 70 functionally connected to an electric traction motor 78. The traction battery pack 70 generally consists of one or more battery modules 72, each comprising a stack of battery cells 74, such as lithium-ion, lithium-polymer, or nickel-metal hydride battery cells of the pouch, can, or prismatic type. One or more electric machines, such as traction motor / generator (M) units 78, draw electrical power from the battery pack 70 of the RESS and optionally supply electrical power to it.An inverter module (PIM) 80 electrically connects the battery pack 70 to the motor / generator (M) unit(s) 78 and modulates the transmission of the electrical current between them. The battery pack 70 is configured such that module management, cell sensing, and module-to-module or module-to-host communication functionality are integrated directly into each battery module 72 and are performed wirelessly via a corresponding wireless cell monitoring unit (CMU) 76. The CMU 76 can be a microcontroller-based, printed circuit board (PCB) mounted sensor array with GPS transceiver and RF capability, located on or within the battery module housing. The battery module cells 74, the CMU 76, the housing, the coolant lines, the bus bars, etc., together form the cell module assembly. The disclosed configuration eliminates the need for separate, hard-wired electronic modules and serial connectors of the type used in a cell sensor board-based topology. During operation of the vehicle 10, the inputs from the driver and the control module generate various vehicle speed and torque commands with corresponding acceleration and deceleration responses. Regardless of whether the vehicle has an ICE, FEV, or HEV-based powertrain, and regardless of whether the vehicle is equipped with both a brake and accelerator pedal or only a single pedal, it may be desirable for the vehicle 10 to be capable of one-pedal operation (OPD). As the name suggests, OPD operation allows the driver to start, accelerate, drive, turn, decelerate, and / or stop the vehicle using a single pedal (accelerator pedal).The following describes techniques for OPD operation that enable vehicle standstill at zero pedal travel (no pedal travel) while maintaining high robustness to road conditions within a specific speed range. Drivability targets, as described by vehicle-calibrated acceleration curves and associated transient acceleration curves, and vehicle parameters, such as road load coefficients, effective road load, and nominal road load forces, are incorporated into the final speed horizon profile. Braking force requirements can also be included in the formulation, at least in some implementations. A future trajectory can be used by a vehicle motion controller (VMC) to optimize actuator commands based on future desired trajectories and measurements. The speed horizon generation and domain transition techniques described here help deliver normalized pedal response that is robust to road load and vehicle mass in real time, while providing OPD control at zero or near-zero vehicle speed. The presented speed horizon techniques can also help minimize or eliminate "dead pedal" on uphill climbs and "pedal jolt" on downhill climbs. A "dead pedal" scenario involves a tip-in maneuver with little or no drivetrain response during the initial accelerator pedal travel. Conversely, a "pedal jolt" scenario involves a tip-in maneuver with a disproportionate drivetrain response during the initial accelerator pedal travel.Speed ​​horizon domain-to-domain transition techniques help deliver consistent behavior between a normalized pedal response at near-zero vehicle speeds and a torque-based pedal response when the vehicle is traveling at higher speeds (e.g., above 10 kilometers per hour (km / h) or another calibratable target value). Additional benefits include a repeatable pedal response for any given road gradient and more consistent vehicle behavior that does not change due to the progression of a learned gradient. Furthermore, calibration times can be reduced by directly incorporating drivability metrics for acceleration and transient acceleration behavior, minimizing the need for additional drivability calibrations when creating speed profiles. As explained in more detail below in the discussion of Fig. 2, generating a speed horizon involves creating a speed profile that corresponds to a torque request from the driver, for example, to achieve one-pedal driving objectives. The driver's accelerator pedal input is first interpreted as a corresponding torque or acceleration request, based on a retrieval table containing an acceleration curve. The torque request derived from the table is then "shaped" using a retrieval table containing an associated transient acceleration curve, which defines the transient acceleration / torque between the points in the acceleration curve table. The shaped torque request is then interpreted in two versions of the acceleration request.A first version of the acceleration requirement can be calculated based on a current estimated road gradient and a current estimated vehicle mass. A second version can be calculated based on a road gradient of zero (0) and a nominal vehicle mass. A final speed profile can be calculated in one of three ways, depending on the vehicle's real-time speed: (1) at vehicle speeds near zero (e.g., about 1-3 km / h), the final speed profile controls the speed based on uncompensated acceleration behavior (i.e., the speed profile is not affected by road load or gradient); (2) at low vehicle speeds (e.g., about 3-10 km / h), the final speed profile controls the speed based on a mixture of compensated and uncompensated acceleration responses; and (3) at higher vehicle speeds (e.g., above about 10 km / h), the final speed profile controls the torque target (e.g., without compensation for road load, gradient, mass, etc.).In other words, at low vehicle speeds, the speed profile is based on the second version of the acceleration request, allowing the cruise control to compensate for variations in road camber and vehicle mass, so that the driver's pedal response matches the vehicle's response on level ground with nominal vehicle mass. At higher vehicle speeds, the speed profile transitions from the second version to the first; the speed profile is then based solely on the first version of the acceleration request at or above a torque transition point. After the complete transition to the first version, the vehicle's cruise control can be equivalent to torque control; when the control switches from cruise control to torque control (and vice versa), no undesirable jerk is perceptible to the vehicle's occupants. The final speed horizon profile can also be adjusted to compensate for driver-initiated vehicle deceleration, such as that applied via the brake pedal. A driver-initiated deceleration command can be interpreted as a corresponding driver-initiated braking torque request, which is then interpreted as a desired deceleration request. This desired deceleration request can then be combined with the desired acceleration request to calculate a final speed horizon profile that is consistent with both the accelerator and brake pedal inputs. As a further option, the actual applied braking torque at each wheel can be provided to the VMC, allowing the cruise control to manage the activation of one or more drive actuators, in addition to the friction brakes controlled by a brake controller, to achieve the desired speed tracking.The VMC can use a two-track bicycle model of the vehicle to predict future vehicle speed trajectories (horizons). The actual friction braking torque applied to each wheel can be provided to the model, allowing the prediction to "understand" the effect of the friction brakes on the overall vehicle speed. The drive axle torque can then be optimized to minimize the difference between these predicted future vehicle speed trajectories and the desired speed profile. This paper presents methods that translate driver acceleration and deceleration commands into vehicle drivability objectives, as described by appropriate acceleration and transient acceleration maps, resulting in a desired vehicle force. It also presents methods that define nominal road load vehicle forces and effective road load forces calculated from the measured and / or estimated road gradient and vehicle mass. Aspects of this disclosure include the calculation of nominal vehicle speed trajectories (no gradient with nominal mass) and effective vehicle speed trajectories (with estimated gradient and mass), and the calculation of a combined trajectory as a function of vehicle speed and gradient. The presented techniques can utilize the effective road load force as a function of vehicle speed, gradient, and other parameters.These techniques can be used to exit operating conditions where robustness to gradient and mass is required. The techniques presented can utilize the points mentioned above, in conjunction with a predefined set of vehicle parameters, to calculate a desired vehicle speed, which can be initialized using a measured vehicle speed. The presented techniques can predict future vehicle speed trajectories, which can be used by a vehicle motion controller to optimize actuator commands based on measurements of vehicle dynamics and future desired commands. With reference to the flowchart of Fig. 2, reference 100 generally describes an improved method or control strategy for performing a speed horizon estimation and transition to operating a motor vehicle, such as the vehicle 10 of Fig. 1, in order to execute a desired vehicle maneuver, such as one-pedal driving, according to aspects of the present description. Some or all of the operations shown in Fig. 2 and described in more detail below may represent an algorithm corresponding to processor-executable instructions, which may be stored, for example, in a main, auxiliary, or remote memory (e.g., memory device 38) and executed, for example, by an electronic controller, a processing unit, a logic circuit, or another module or device or network of modules / devices (e.g., a computer ...CPU 36) to perform one or all of the functions described above and below, which are related to the disclosed concepts. It should be noted that the order of execution of the presented operation blocks can be changed, additional operation blocks can be added, and some of the described operations can be modified, combined, or eliminated. The procedure 100 of Fig. 2 begins at terminal block 101 with storable, processor-executable instructions for a programmable control unit or control module, or a similarly suitable processor, to call an initialization procedure for a vehicle powertrain control protocol. This routine can be executed in real time, continuously, systematically, sporadically, and / or at regular intervals, e.g., every 10 or 100 milliseconds during the normal and ongoing operation of the vehicle 10. As a further option, terminal block 101 can be initialized in response to a user command prompt or a broadcast prompt signal received from a centralized host system "outside the vehicle" (e.g., the cloud computing service 24 of Fig. 1). After completion of the procedure shown in Fig.In the two control processes shown, procedure 100 can continue to terminal block 131 and be temporarily terminated, or optionally return to terminal block 101 and run in a continuous loop. Moving on to process block 103, procedure 100 receives a speed increase (or decrease) requested by the driver via an in-vehicle driver input device. According to the example shown, the driver depresses an accelerator pedal to input an acceleration command for the vehicle's powertrain. Upon receiving this command, subroutine process block 105 of Fig. 2 provides executable instructions to determine a driver torque request from a vehicle-calibrated acceleration table that corresponds to the acceleration command input by the driver. This acceleration table may contain an acceleration map file stored in memory and accessible to the controller, which maps a sequence of vehicle speeds and vehicle acceleration values ​​with a corresponding sequence of powertrain torque outputs.Raw data from the pedal travel, indicating a desired acceleration, are used to "look up" a torque request from the driver in the map file as a function of a measured vehicle speed and a pedal position of the accelerator pedal received from a pedal sensor. This “unformed” driver torque request is passed from subroutine process block 105 to subroutine process block 107 of Fig. 2, where it is “formed” using a vehicle-calibrated transient acceleration table. The transient acceleration table may contain a transient acceleration map file stored in memory and accessible to the controller. The transient map file may be a lookup table that defines the powertrain torque in transition regions between adjacent powertrain torque output values ​​in the acceleration map file. As a non-restrictive example, the transient map file may define a corresponding ramp rate (e.g., change in acceleration or torque per loop) between each pair of adjacent points in the acceleration map file as a function of the vehicle speed and the change in torque, i.e.,The difference between a target torque and an actual torque is identified. The driver's torque demand is shaped by incorporating these acceleration / torque ramp rate responses to add curvature to the torque demand profile. Procedure 100 proceeds with process blocks 109 and 111 to determine a driver-requested acceleration profile that corresponds to the shaped driver torque request profile from subroutine process block 107. For example, process block 109 calculates an "uncompensated" acceleration request profile from the shaped torque request profile, based on a road gradient of zero (0) and a nominal ("nom") vehicle mass or an estimated vehicle mass. In contrast, process block 111 calculates a "compensated" acceleration request profile from the shaped torque request, based on an estimated road gradient and the nominal or estimated vehicle mass (depending on what is used for the uncompensated calculation).Using the principles of Newtonian mechanics, the acceleration profile is calculated with a force variable F as the mathematical sum of the driver-defined torque, the applied braking torque, the road inclination force, and the road load force (ro + r1*v + r2*v^2, where v is the measured vehicle speed). Additionally, a mass variable m is either a preset target vehicle mass or an estimated / measured (real-time) vehicle mass. For process block 109, where the actual road inclination is not considered, the road inclination force input is set to zero. To complete the calculations in process block 111, a mass estimation module or suitable mass sensing device outputs an estimated vehicle mass of the vehicle in question with its current payload, as specified in data processing block 113. Data processing block 113 may also include a gradient estimation module or suitable gradient sensing device that transmits an estimated road gradient of a road segment currently being traveled by the vehicle in question. In this context, a real-time road gradient may be calculated using measurements from an in-vehicle sensor device, such as a three-axis accelerometer, or retrieved using real-time geolocation data, such as navigation system map information based on geodetic coordinates received from a Global Positioning System (GPS).The real-time vehicle mass, on the other hand, can be calculated using measurements from a combination of in-vehicle dynamic sensors, such as wheel speed sensors, accelerometers, etc., or predicted using model-based estimators, such as a Kalman filter (KF), extended KF, sigma point filters, etc., or using machine learning techniques. To continue the discussion of the desired acceleration profile, procedure 100 from Fig. 2 proceeds to process block 115 and determines a desired velocity profile based on the desired acceleration without compensation output by process block 109 and the desired acceleration with compensation output by process block 111. For at least some applications, process block 115 involves calculating a final velocity horizon profile as follows: (1) when the current vehicle speed of the vehicle in question is close to zero (e.g.,(1) if the vehicle speed is above a vehicle speed close to zero and below a predefined threshold vehicle speed (e.g., approximately 1-3 km / h), the final speed horizon profile is set to a speed-controlled speed profile that can be calculated primarily or exclusively based on the uncompensated acceleration; (2) if the vehicle speed is above a vehicle speed close to zero and below a predefined threshold vehicle speed (e.g., approximately 3-10 km / h), the final speed horizon profile is set to a mixture-controlled speed profile that can be calculated by mixing the compensated and uncompensated accelerations; (3) if the vehicle speed is above the predefined threshold vehicle speed (e.g.,If the speed is above approximately 10 km / h, the final speed horizon profile is set to a torque-controlled speed profile, which can be calculated based primarily or exclusively on the compensated acceleration. The calculation of the final speed horizon profile may involve performing a force blending procedure (effective / nominal) to determine an effective or a nominal force horizon. The calculation of a force horizon (effective (i)) may be based on a torque horizon, a nominal road load horizon, a braking demand horizon, and a horizon for the effect of road gradient. In contrast, the calculation of a force horizon (nominal (i)) may be based on a torque horizon, a nominal road load horizon, and a braking demand horizon; the road gradient effect is not considered in the nominal calculations. These calculations may be repeated for the N levels of the horizon: The output of each calculation is integrated to create the next horizon level in the speed profile.The calculations of the velocity horizon profile are described in more detail below in the discussions of Fig. 3 and Fig. 4. In process block 117, procedure 100 receives a speed reduction request from the driver via a vehicle-integrated driver input device. According to the illustrated example, the driver depresses a brake pedal to input a deceleration command for the vehicle's powertrain to reduce the vehicle's current speed to a desired target speed. Upon receiving this command, subroutine process block 119 of Fig. 2 provides processor-executable instructions to determine, from a vehicle-calibrated acceleration table, a desired deceleration value and a driver braking torque request corresponding to the deceleration command input from the driver. This deceleration torque request can be based, at least in part, on the estimated road gradient and vehicle mass output by data processing block 113.Similar to the driver's acceleration torque request, which is determined in subroutine process block 105, the driver's desired deceleration torque request can be calculated using the call tables with their associated acceleration and transient acceleration maps. Generally, these call tables provide torque values ​​that would bring the vehicle to a standstill when the pedal position is zero. The driver's desired deceleration and the corresponding braking torque request can be passed to process block 115 to calculate the final speed horizon profile as a torque-controlled speed profile. To complete the calculations in process block 115, a vehicle speed sensor outputs one or more sensor signals indicating the real-time speed of the vehicle in question in data process block 121. In addition to using real-time vehicle speed data to determine which of the available speed profiles should be used as the final speed horizon profile, procedure 100 can also select a vehicle control mode based on the real-time vehicle speed, as specified in process block 123. According to the example shown, the control mode can be set to either a speed control mode or a torque control mode.For cruise control mode, the transient acceleration behavior map files are interpreted as an acceleration request; brake pedal actuation is interpreted as a deceleration request and incorporated into the speed profile. For torque control mode, the torque request based on acceleration and the transient acceleration map is provided by the VMC. Mode selection can be based on real-time vehicle speed, the position of the driver input device (e.g., accelerator / brake pedal position), the rate of change of the driver input device position, and / or a measured road inclination. With further reference to Fig. 2, an integrated vehicle motion controller performs model-based predictive control analysis to determine a desired axle torque to achieve the driver's desired acceleration command (block 103) and / or deceleration command (block 117). To perform this model predictive control (MPC) technique, the integrated VMC aggregates and analyzes the shaped driver torque request output by subroutine process block 107, the desired speed profile output by process block 115, the vehicle control mode output by process block 123, and an actual real-time braking torque applied to the vehicle's road wheels, output via a brake torque sensor at data process block 127. The VMC can store a model of the vehicle, such as a two-track bicycle model, in which the torque commands are the control variables.The model can be derived using first principles, determined experimentally, or a combination of both. Optimization methods can be used to calculate the torque commands that minimize tracking error (i.e., the difference between the calculated velocity profile and the measured vehicle velocity) over the time horizon of interest (e.g., N seconds into the future). In torque control, the error between the torque request and the commanded controller torque can be taken into account. The desired axle torque at the vehicle's road wheels is output by process block 125 and transferred to the powertrain (e.g., from CPU 36 to PCM 52 and PIM 80) for execution of the axle torque in process block 129. In at least some implementations, a future vehicle speed trajectory profile for the vehicle in question can be predicted using a two-track bicycle model of the vehicle. The requested axle torque can be modified to minimize any difference between the future vehicle speed trajectory profile and the final speed horizon profile. After the desired axle torque has been executed, process 100 can proceed to terminal block 131 and terminate. Fig. 3 schematically shows a first option for the speed profile mixing method 200, which can be used with the speed horizon estimation and transition control protocol of Fig. 2. In this example, there is a single processing module—vehicle speed profile block (A) 202—which aggregates and analyzes a set of feedback inputs in a closed-loop control system and outputs a speed profile from these inputs. In the example shown in Fig. 3, there are seven inputs: a friction braking torque 201, a measured vehicle speed 203, an optional (but not necessary) control input 205, a driver-requested torque (horizon) 207, a reset speed profile 209, measured road inclination forces (mgsin(theta)) 211, and a previous speed profile 213.Process block 204 executes a lookup function “nD T(u)” where the road inclination force is multiplied by a constant in the range [x1,x2] (e.g., [0,1]), which is selected as a function of the vehicle speed and the measured inclination. Generally, the constant is set to zero if the vehicle speed is zero. From these inputs, the vehicle speed profile block (A) 202 calculates a speed horizon profile 215. Specifically, block (A) 202 uses the seven inputs listed above, as well as a set of road load forces (r0 + r1*v + r2 * v^2) (e.g., as input 205), to calculate a desired acceleration and, by integration, computes the speed horizon profile 215. The measured road inclination force(s) can be measured / calculated by onboard sensors, such as accelerometers, GPS, etc.This signal, like the measured vehicle speed, can be filtered to exclude certain frequency components. Fig. 4 schematically shows a second option for the speed profile mixing method 300, which can be used with the speed horizon estimation and transition control protocol of Fig. 2. In this example, there are three processing modules—block (B) 302 for the vehicle speed horizon (without gradient compensation), block (C) 304 for the vehicle speed horizon (with gradient compensation), and block (D) 306 for merging the vehicle speed horizons—which combine and analyze a set of feedback inputs from the closed-loop control system and output a speed profile from these inputs. Similar to Fig. 3, the example shown in Fig.The system has four inputs: a friction braking torque 301, a measured vehicle speed 303, an optional (but not necessary) control input 305, a driver-requested torque (horizon) 307, a reset speed profile 309, measured road inclination forces (mgsin(theta)) 311, and a previous speed profile 313. From these inputs, the first vehicle speed horizon block (B) 302 outputs an uncompensated speed horizon profile (without gradient) 315, and the second vehicle speed horizon block (C) 304 outputs a compensated speed horizon profile (with gradient) 317. The vehicle speed horizon mixing block (D) 306 mixes the compensated and uncompensated speed horizon profiles 317, 315 and outputs the speed horizon profile 319. In Fig. 4, the vehicle speed horizon block (B) 302 uses the same inputs as mentioned above with reference to the vehicle speed profile block (A) 202 of Fig. 3, except that the road inclination force 311 is multiplied by zero (0) and is therefore not part of the calculation of the uncompensated speed horizon profile 315. In comparison, the vehicle speed horizon block (C) 304 in Fig. 4 uses the same inputs as the vehicle speed profile block (A) 202; however, the road inclination force 311 is entered directly without being multiplied by a constant. Vehicle speed horizon mixing block (D) 306 combines the profiles from blocks (B) and (C) 302, 304 in the following form: where the merging constant c is a function of the measured vehicle speed and the measured road gradient (e.g. c = 0 is the vehicle speed 0 km / h.) Aspects of this description can, in some embodiments, be implemented by a computer-executable program of instructions, such as program modules, commonly referred to as software applications or application programs, and executed by any controller or the controller variants described herein. Software can, in non-limiting examples, include routines, programs, objects, components, and data structures that perform specific tasks or implement specific types of data. The software can provide an interface that enables a computer to respond according to an input source. The software can also work in conjunction with other code segments to initiate a variety of tasks in response to received data in conjunction with the source of the received data. The software can be stored on a variety of storage media, such as CD-ROM, magnetic disk, and semiconductor memory (e.g., memory chips).B. different types of RAM or ROM). Furthermore, aspects of this description can be practiced with a wide variety of computer system and computer network configurations, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframes, and the like. Additionally, aspects of this description can be applied in distributed computing environments where tasks are performed by resident and remote devices connected via a communication network. In a distributed computing environment, program modules can reside in both local and remote computer storage media, including storage devices. Therefore, aspects of this description can be implemented in conjunction with various hardware, software, or a combination thereof in a computer system or other processing system. Each of the methods described herein can provide machine-readable instructions for execution by: (a) a processor, (b) a controller, and / or (c) any other suitable processing device. Each algorithm, software, control logic, protocol, or method disclosed herein may be embodied as software stored on a tangible medium, such as flash memory, solid-state memory, hard disk, CD-ROM, digital versatile disk (DVD), or other storage devices. Alternatively, the entire algorithm, control logic, protocol, or method, and / or parts thereof, may be executed by a device other than a controller and / or be embodied in firmware or dedicated hardware in an available manner (e.g., implemented by an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a field-programmable logic device (FPLD), discrete logic, etc.).Although specific algorithms are described with reference to the flowcharts shown here, many other methods can alternatively be used to implement the exemplary machine-readable instructions.

Claims

Method (100) for operating a motor vehicle (10), wherein the motor vehicle (10) comprises a powertrain operable for propelling the motor vehicle (10) and a driver input device operable for receiving vehicle control inputs from a driver of the motor vehicle (10), the method comprising: receiving (103), via a vehicle control unit from the driver via the driver input device, an acceleration command for the powertrain of the motor vehicle (10); determining (105), via the vehicle control unit from an acceleration table, an acceleration or torque request corresponding to the driver's acceleration command; and shaping (107) the acceleration or torque request based on an unsteady acceleration table.Determine (109, 111) compensated and uncompensated accelerations from the shaped requirement, wherein the compensated acceleration is based on an estimated road gradient and an estimated vehicle mass, and the uncompensated acceleration is based on a road gradient of zero and a nominal vehicle mass or the estimated vehicle mass;Calculating (115) a final velocity horizon profile (215) as: a velocity-controlled velocity profile based on uncompensated acceleration when the vehicle speed of the motor vehicle (10) is at a calibratable or near-zero vehicle speed, a mixture-controlled velocity profile based on a mixture of compensated and uncompensated accelerations when the vehicle speed is above the near-zero vehicle speed and below a predefined threshold vehicle speed, and a torque-controlled velocity profile based on uncompensated acceleration when the vehicle speed is above the predefined threshold vehicle speed;and sending a command signal via the vehicle control system to the drivetrain to output a requested axle torque based on the calculated final speed horizon profile. Method (100) according to claim 1, further comprising: receiving a sensor signal indicating a real-time vehicle speed of the motor vehicle (10) via the vehicle control system from a speed sensor; and selecting a vehicle control mode as a speed control mode or as a torque control mode based on the real-time vehicle speed, a position of the driver input device, a rate of change of the position of the driver input device and / or a measured or estimated road inclination, wherein the command signal transmitted to the powertrain is further based on the selected vehicle control mode. Method (100) according to claim 2, wherein the calculation of the final speed horizon profile as a speed-controlled speed profile is still based on the real-time vehicle speed. Method (100) according to claim 1, further comprising: Receiving, via the vehicle control system from the driver via the driver input device, a deceleration command to reduce the vehicle speed of the motor vehicle (10); and Determining a deceleration torque or deceleration requirement corresponding to the driver's deceleration command, based on the estimated road gradient and the estimated vehicle mass. Method (100) according to claim 4, wherein the calculation of the final speed horizon profile as a torque-controlled speed profile is further based on the deceleration torque or deceleration requirement corresponding to the deceleration command of the driver. Method (100) according to claim 1, further comprising receiving a sensor signal from a brake sensor via the vehicle control system, indicating a real-time braking torque applied to a road wheel of the motor vehicle (10), wherein the requested axle torque is modified based on the real-time braking torque. Method (100) according to claim 1, wherein the calculation of the final speed horizon profile as a speed-controlled speed profile is further based on a road gradient compensation value. Method (100) according to claim 1, further comprising: predicting a future vehicle speed trajectory profile for the motor vehicle (10) using a two-track bicycle model of the motor vehicle (10); and modifying the requested axle torque to minimize any possible difference between the future speed profile of the vehicle (10) and the final speed horizon profile. Method (100) according to claim 1, further comprising calculating a nominal road load-vehicle force and an effective road load based on the estimated road gradient and the estimated vehicle mass, wherein the calculation of the final speed horizon profile as the torque-controlled speed profile is further based on the nominal road load-vehicle force and the effective road load. Method (100) according to claim 1, further comprising: receiving, via the vehicle control system from a mass estimation module, the estimated vehicle mass of the motor vehicle (10) with a current payload; and receiving the estimated road gradient of a road section currently being traveled by the motor vehicle (10) via the vehicle control system from a gradient estimation module.

Images