Vehicle longitudinal motion request system for providing motion requests and constraints based on requests from multiple requesters

Abstract

A vehicle longitudinal motion request system for providing motion requests and constraints based on requests from a plurality of requesters. A motion system for a vehicle includes an arbitration module configured to arbitrate a request and one or more constraints received from each of a plurality of feature request modules to generate a resulting request and one or more resulting constraints; a profile generation module configured to determine whether to modify at least one of the resulting request and the one or more resulting constraints, and output i) the resulting request or a modified version of the resulting request as a first profile request, and outputting ii) the one or more resulting constraints or a modified version of the one or more resulting constraints as one or more profile constraints; and a vehicle motion control module configured to control one or more actuators of the vehicle based on the first profile request and the one or more profile constraints.

Description

[0001] Introduction

[0002] The information provided in this section is for the purpose of presenting in general the background of the present disclosure. To the extent that it is described in this section, the work of the currently named inventors, as well as aspects that may not otherwise qualify as prior art at the time of filing, are neither expressly nor implicitly regarded as prior art against the present disclosure.

[0003] The present disclosure relates to a vehicle motion request and control system that operates based on requests from multiple requesters.

[0004] The host vehicle may include various motion control systems for assisting a driver during, for example, partial or fully autonomous operation. For example, the host vehicle may include a cruise control system, an adaptive cruise control system, a hands-free driving system, a one-pedal driving system, etc. Each of these systems provides at least some level of speed and acceleration (or deceleration) control assistance as well as other assistance. Cruise control and adaptive cruise control systems operate to maintain a set speed. The adaptive cruise control system also operates to maintain a safe distance from a vehicle in front of the host vehicle. The hands-free driving system operates to autonomously drive the host vehicle, for example, on a highway, including controlling the speed, acceleration, deceleration, and steering of the host vehicle. The one-pedal driving system operates to automatically decelerate the host vehicle when the vehicle operator releases the accelerator pedal. The host vehicle may automatically apply the brakes without the driver stepping on the brake pedal. Summary of the Invention

[0005] A motion system for a vehicle. The motion system includes: an arbitration module configured to arbitrate a set of target motion requests and one or more constraints received from each of a plurality of feature request modules to generate a resulting target motion request and one or more resulting constraints; a profile generation module configured to determine whether to modify one or more of the resulting constraints, construct a desired motion profile based on at least one of the resulting target motion request and the ultimately resulting constraints, and output i) the desired motion profile as a first profile request, and output ii) one or more of the resulting constraints or a modified version of one or more of the resulting constraints as one or more profile constraints; and a vehicle motion control module configured to control one or more actuators of the vehicle based on the first profile request and the one or more profile constraints.

[0006] In other features, the arbitration module is configured to arbitrate requests and one or more constraints received from each of the feature request modules based on one or more feature requirements to generate a resulting request and one or more resulting constraints.

[0007] Among other features, the arbitration module is configured to arbitrate each received request and one or more constraints from the feature request module based on a detected system (e.g., hardware) fault to generate a resulting request and one or more resulting constraints.

[0008] Among other features, the arbitration module is configured to arbitrate each received request and one or more constraints from the feature request module based on an acceleration response map to generate a resulting request and one or more resulting constraints.

[0009] Among other features, the vehicle motion control module is configured to monitor at least one state of the vehicle and generate a behavior signal indicating the achievement of the at least one state. The arbitration module is configured to arbitrate each received request and one or more constraints from the feature request module based on the achieved behavior signal to generate a resulting request and one or more resulting constraints.

[0010] Among other features, the profile generation module is configured to generate a profile request based on the resulting request or a modified version of the resulting request, where the profile request includes a first profile request. The vehicle motion control module is configured to control one or more actuators of the vehicle based on the profile request.

[0011] Among other features, the profile request includes a speed request, an acceleration request, and a jerk request.

[0012] Among other features, the profile generation module is configured to output a first profile request based on an acceleration response map.

[0013] Among other features, the vehicle motion control module is configured to output at least one hardware constraint. The profile generation module is configured to output a first profile request based on the at least one hardware constraint.

[0014] Among other features, the feature request module is configured to: i) receive a first profile request and one or more profile constraints from the profile generation module, and ii) generate a request and one or more constraints generated by each in the feature request module based on at least one of the first profile request and the one or more profile constraints.

[0015] Among other features, the first profile request is a speed request. The one or more profile constraints include an acceleration constraint and a jerk constraint.

[0016] Among other features, a motion request and control method for a vehicle is disclosed. The method includes: arbitrating a received set of target motion requests and one or more constraints from each in a feature request module to generate a resulting target motion request and one or more resulting constraints; determining whether to modify one or more of the resulting constraints, constructing a desired motion profile based on at least one of the resulting target motion request and the ultimately resulting constraints, and outputting i) the desired motion profile as a first profile request, and outputting ii) one or more of the resulting constraints or a modified version of one or more of the resulting constraints as one or more profile constraints; and controlling one or more actuators of the vehicle based on the first profile request and the one or more profile constraints.

[0017] Among other features, the method further includes arbitrating a received request and one or more constraints from each in a feature request module based on one or more feature requirements to generate a resulting request and one or more resulting constraints.

[0018] Among other features, the method further includes arbitrating a received request and one or more constraints from each in a feature request module based on a detected system (e.g., hardware) fault to generate a resulting request and one or more resulting constraints.

[0019] Among other features, the method further includes arbitrating a received request and one or more constraints from each in a feature request module based on an acceleration response map to generate a resulting request and one or more resulting constraints.

[0020] Among other features, the method further includes: monitoring at least one state of the vehicle and generating a behavior signal indicating the achievement of the at least one state; and arbitrating a received request and one or more constraints from each in a feature request module based on the achieved behavior signal to generate a resulting request and one or more resulting constraints.

[0021] Among other features, the method further includes: generating a profile request based on the resulting request or a modified version of the resulting request, where the profile request includes a first profile request; and controlling one or more actuators of the vehicle based on the profile request. The profile request includes a speed request, an acceleration request, and a jerk request.

[0022] Among other features, a profile generation module is configured to output a first profile request based on the resulting constraints, and the resulting constraints can be modified by an acceleration response map.

[0023] Among other features, a vehicle motion control module is configured to output at least one hardware constraint. The profile generation module is configured to output a first profile request based on the at least one hardware constraint.

[0024] Among other features, the feature request module is configured to: i) receive a first profile request and one or more profile constraints from the profile generation module, and ii) generate a request and one or more constraints generated by each in the feature request module based on at least one of the first profile request and the one or more profile constraints.

[0025] The present application provides the following technical solutions:

[0026] 1. A motion system for a vehicle, the motion system comprising:

[0027] An arbitration module configured to arbitrate requests and one or more constraints received from each of a plurality of feature request modules to generate a resulting request and one or more resulting constraints;

[0028] A profile generation module configured to determine whether to modify at least one of the resulting request and the one or more resulting constraints, and output i) the resulting request or a modified version of the resulting request as a first profile request, and output ii) the one or more resulting constraints or a modified version of the one or more resulting constraints as one or more profile constraints; and

[0029] A vehicle motion control module configured to control one or more actuators of the vehicle based on the first profile request and the one or more profile constraints.

[0030] 2. The motion system according to technical solution 1, wherein the arbitration module is configured to arbitrate requests and one or more constraints received from each of a plurality of feature request modules based on one or more feature requirements to generate a resulting request and one or more resulting constraints.

[0031] 3. The motion system according to technical solution 1, wherein the arbitration module is configured to arbitrate requests and one or more constraints received from each of a plurality of feature request modules based on detected hardware failures to generate a resulting request and one or more resulting constraints.

[0032] 4. The motion system according to technical solution 1, wherein the arbitration module is configured to arbitrate requests and one or more constraints received from each of a plurality of feature request modules based on an acceleration response map to generate a resulting request and one or more resulting constraints.

[0033] 5. The motion system according to technical solution 1, wherein:

[0034] The vehicle motion control module is configured to monitor at least one state of the vehicle and generate a behavior signal indicating the achievement of the at least one state; and

[0035] The arbitration module is configured to arbitrate requests received from each of a plurality of feature request modules and one or more constraints based on the implemented behavior signals to generate a resulting request and one or more resulting constraints.

[0036] 6. The motion system according to technical solution 1, wherein:

[0037] The profile generation module is configured to generate a plurality of profile requests based on the resulting request or a modified version of the resulting request, wherein the plurality of profile requests includes a first profile request; and

[0038] The vehicle motion control module is configured to control one or more actuators of the vehicle based on the plurality of profile requests.

[0039] 7. The motion system according to technical solution 6, wherein the plurality of profile requests includes a speed request, an acceleration request, and a jerk request.

[0040] 8. The motion system according to technical solution 1, wherein the profile generation module is configured to output the first profile request based on an acceleration response map.

[0041] 9. The motion system according to technical solution 1, wherein:

[0042] The vehicle motion control module is configured to output at least one hardware constraint; and

[0043] The profile generation module is configured to output the first profile request based on at least one hardware constraint.

[0044] 10. The motion system according to technical solution 1, wherein the plurality of feature request modules are configured to: i) receive the first profile request and one or more profile constraints from the profile generation module, and ii) generate requests and one or more constraints generated by each of the plurality of feature request modules based on at least one of the first profile request and the one or more profile constraints.

[0045] 11. The motion system according to technical solution 10, wherein:

[0046] The first profile request is a speed request; and

[0047] The one or more profile constraints include an acceleration constraint and a jerk constraint.

[0048] 12. A method for motion request and control of a vehicle, the method comprising:

[0049] Arbitrate requests received from each of a plurality of feature request modules and one or more constraints to generate a resulting request and one or more resulting constraints;

[0050] Determine whether to modify at least one of the resulting request and one or more resulting constraints, and output i) the resulting request or a modified version of the resulting request as a first profile request, and output ii) one or more resulting constraints or a modified version of one or more resulting constraints as one or more profile constraints; and

[0051] Control one or more actuators of the vehicle based on the first profile request and one or more profile constraints.

[0052] 13. The method according to claim 12, further comprising arbitrating requests received from each of a plurality of feature request modules and one or more constraints based on one or more feature requirements to generate a resulting request and one or more resulting constraints.

[0053] 14. The method according to claim 12, further comprising arbitrating requests received from each of a plurality of feature request modules and one or more constraints based on a detected hardware fault to generate a resulting request and one or more resulting constraints.

[0054] 15. The method according to claim 12, further comprising arbitrating requests received from each of a plurality of feature request modules and one or more constraints based on an acceleration response map to generate a resulting request and one or more resulting constraints.

[0055] 16. The method according to claim 12, further comprising:

[0056] Monitor at least one state of the vehicle and generate a behavior signal indicating the achievement of the at least one state; and

[0057] Arbitrate requests received from each of a plurality of feature request modules and one or more constraints based on the achieved behavior signal to generate a resulting request and one or more resulting constraints.

[0058] 17. The method according to claim 12, further comprising:

[0059] Generate a plurality of profile requests based on the resulting request or a modified version of the resulting request, wherein the plurality of profile requests includes the first profile request; and

[0060] Control one or more actuators of the vehicle based on the plurality of profile requests,

[0061] Among them, the multiple profile requests include a speed request, an acceleration request, and a jerk request.

[0062] 18. The method according to claim 12, wherein the profile generation module is configured to output a first profile request based on an acceleration response map.

[0063] 19. The method according to claim 12, wherein:

[0064] The vehicle motion control module is configured to output at least one hardware constraint; and

[0065] The profile generation module is configured to output a first profile request based on at least one hardware constraint.

[0066] 20. The method according to claim 12, wherein the multiple feature request modules are configured to: i) receive a first profile request and one or more profile constraints from the profile generation module, and ii) generate requests and one or more constraints generated by each of the multiple feature request modules based on at least one of the first profile request and the one or more profile constraints.

[0067] The further applicable fields of the present disclosure will become clear according to the detailed description, claims, and drawings. The detailed description and specific examples are only for illustrative purposes and are not intended to limit the scope of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] The present disclosure will be more fully understood according to the detailed description and the drawings, wherein:

[0069] Figure 1 is a functional block diagram of an example host vehicle of a speed-based control system including examples according to the present disclosure, the speed-based control system including a vehicle motion request module;

[0070] Figure 2 is a functional block diagram of an example vehicle longitudinal motion request and control (or speed-based control) system including an arbitration module and a profile generation module according to the present disclosure;

[0071] Figure 3 is a functional block diagram of an example vehicle motion request and control system including an arbitration module, a profile generation module, and a vehicle motion control system according to the present disclosure;

[0072] Figure 4 illustrates an example method for generating motion requests and constraints for a vehicle motion control system according to the present disclosure;

[0073] Figure 5is a diagram illustrating an example according to the present disclosure when generating a speed profile in a specific format based on changes in pedal position and target speed; and

[0074] Figure 6 illustrates a method for generating speed, acceleration, and jerk profiles according to the present disclosure.

[0075] In the drawings, reference numerals may be reused to identify similar and / or identical elements. Detailed Description

[0076] The host vehicle may include multiple motion requesters, which may request, for example, to drive at a requested speed. For example, the host vehicle may include a cruise control system, an adaptive cruise control system, a hands-free driving system, a one-pedal driving system, or other motion request systems. The host vehicle may also include a device that receives a driver acceleration request, such as an accelerator pedal sensor that detects the position of the accelerator pedal and maps it to a desired acceleration based on the Vehicle Technical Specification (VTS). Each of these motion requests may be provided to the controller in the form of a speed (or rate) request. The driver acceleration or torque request may be converted into a speed request. The vehicle may include any number of motion control systems that generate corresponding speed requests.

[0077] One example implementation for processing speed requests includes a converter that converts the speed requests into torque requests, respectively. When multiple requests are received simultaneously, an arbiter performs an arbitration function to determine which one of the one or more requests is to be satisfied. Then, a torque profile generator generates a torque profile to be followed based on the satisfied one or more requests. The controller controls the vehicle's devices based on the torque profile. The devices may include one or more motors and / or engines. Sensors detect the state of the devices, and the output of the sensors (e.g., vehicle motion) is then used as feedback to adjust the requested torque profile and / or the control of the devices to satisfy the one or more requests.

[0078] The described implementation has associated drawbacks. For example, each requester can have its own unique request format and corresponding converters and closed-loop controls for controlling the device. Thus, when each requester prepares its own torque request for arbitration, the same operations are performed multiple times and multiple sets of vehicle models and open-loop or closed-loop controllers are used. There are also inefficiencies and inaccuracies in converting the target vehicle motion (or speed request) into total vehicle torque. The conversion and control have high associated control design, coding, testing, deployment, maintenance, calibration and thus high engineering costs, as well as high hardware RAM, ROM throughput consumption. If all the models and the same type of controllers are not identical, there may also be inconsistent performance associated with the requests, which can lead to poor driving quality, especially when switching between different request types. Additionally, acceleration response plots such as the Target Acceleration Response Map (ARM) and the Target Transition Acceleration Response Map (tARM, which can also be referred to as the Target Jerk Response Map (JRM)) and corresponding performance metrics must be converted to axle torque for use in the driver torque request system. The acceleration response plot, also known as the vehicle speed horizon, defines the target speed profile curve by zero acceleration. The ARM refers to the rate of change in the vehicle motion between the initial acceleration period and the deceleration period. The tARM refers to the change in acceleration (or acceleration rate) during the initial acceleration period and the change in acceleration (or acceleration rate) during the deceleration period. In some cases, the tARM may not be utilized and only the pre-ARM for the initial acceleration period and the post-ARM for the deceleration period are used. The pre-ARM refers to different ARM values for the initial and final stages of acceleration. The described implementation also requires a known and accurate vehicle mass, which may affect performance.

[0079] There are also complexities when converting acceleration-based performance targets to axle torque before arbitrating all torque requests. Traditional motion request systems operate based on torque-based requests and present the repeated conversion from acceleration to torque in an offline or real-time manner. When the conversion occurs offline, they lose the ability to compensate for changes in road / environment conditions (such as road grade, road surface friction, and wind direction and intensity) and vehicle attributes (such as vehicle mass, tire radius, drag coefficient). Whether the conversion operates offline or in real-time, each torque requester may need to use a dynamic vehicle model and an open-loop or closed-loop controller to convert the desired vehicle motion to axle torque. Thus, a vehicle can include multiple dynamic vehicle models and / or implement open-loop and closed-loop controllers with corresponding algorithms and calibrations on corresponding platforms. The conversion can occur at multiple vehicle models and / or controllers. Potentially, the repetitive work regarding designing, coding, testing, deploying, and maintaining the dynamic vehicle model and any particular type of open-loop and closed-loop controller may result in significant waste of engineering resources and resources of the embedded control module (such as RAM, ROM, and throughput). By enabling the execution of repetitive and similar calibrations, it may lead to calibration efforts and errors, which may provide contradictory results.

[0080] The examples set forth herein include a vehicle longitudinal motion request architecture for providing motion requests and constraints based on requests from multiple requesters. Although the following examples are mainly described with respect to longitudinal motion requests, speed, acceleration, jerk, etc., the examples are also applicable to lateral motion requests, speed, acceleration, jerk, etc. The current torque-based architecture is inefficient, complex, not robust, has associated redundancies, and is expensive to calibrate. The examples disclosed herein include receiving speed requests and constraints from multiple requesters. A requester refers to a vehicle motion request system, such as a cruise control system, an adaptive cruise control system, a hands-free driving system, a single-pedal driving system, or other motion request systems. A requester can also refer to a driver torque request device or module, such as an acceleration module that generates a speed request signal based on the position of an accelerator pedal. Constraints include acceleration constraints and jerk constraints. The acceleration and jerk constraints can include acceleration and jerk limits that are not to be exceeded. The disclosed architecture includes a supervisory control layer, an arbitration module, and a profile generation module that feedback the implemented behavior, hardware constraints, and detected faults to the requesters, as further described below.

[0081] The examples set forth herein further include a profile generation module configured to construct a motion profile (i.e., a rate reference profile of the motion to be followed). In an embodiment, rate / velocity, acceleration, and jerk profiles are generated. In an embodiment, a vehicle rate / velocity range (or rate / velocity profile) having a specific format and using target rates and motion constraints (e.g., acceleration maximum and minimum constraints, and jerk maximum and minimum constraints) is generated. This specific format provides an efficient way to generate vehicle motion profiles / ranges with minimized random access memory (RAM), read-only memory (ROM), and throughput consumption, and provides sufficient motion reference information for various types of control methods (e.g., proportional integral derivative (PID), linear quadratic regulator (LQR), and model predictive control (MPC)). Rate and motion constraints (e.g., acceleration constraints and jerk constraints) can be obtained from vehicle technical specifications, an online request module, or via local and / or remote inputs. The examples eliminate the inefficiencies of converting acceleration and jerk metrics to axle torque (e.g., repeated conversions using repeated vehicle models and repeated control methods), and thereby reduce algorithm and calibration efforts.

[0082] Figure 1 A host vehicle 100 is shown including a velocity-based control system 101 that includes an example. The velocity-based control system 101 includes a vehicle motion request module 102. The velocity-based control system 101 includes a vehicle control module 103 that implements the vehicle motion request module 102. The vehicle motion request module 102 generates motion requests and constraints based on motion requests and constraints received from multiple requesters, as further described below. As an example, the motion requests can include velocity, acceleration, and jerk requests, and the constraints can include velocity, acceleration, and jerk constraints. Modules 102, 103 can perform various operations based on interactions with the driver of the host vehicle 100. The vehicle control module 103 can perform autonomous operations based on interactions including responses received from the driver.

[0083] The vehicle 100 further includes one or more power sources 105, a telematics module 106, an infotainment module 107, other control modules 108, and a propulsion system 110. The vehicle control module 103 can control the operation of the vehicle 100 and modules 102, 106, 107, 108, and the propulsion system 110. The power source 105 can include one or more battery packs, generators, converters, control circuits, terminals for high-voltage loads and low-voltage loads, etc., and one or more battery sensors 111 for detecting the state of the power source 105, including voltage, current level, state of charge, etc.

[0084] The telematics module 106 provides wireless communication services within the vehicle 100 and wirelessly communicates with service providers, back offices, central offices, cloud-based networks, enterprises, and devices external to the vehicle 100. The telematics module 106 may support Bluetooth Low Energy (BLE), Near Field Communication (NFC), cellular, legacy (LG) Transmission Control Protocol (TCP), Long Term Evolution (LTE), and / or other wireless communications and / or operate according to BLE, NFC, cellular, and / or other wireless communication protocols. The telematics module 106 may include one or more transceivers 112 and a navigation module 114 having a Global Positioning System (GPS) and GNSS (or Global Navigation Satellite System) receiver 116. The transceivers 112 wirelessly communicate with network devices internal and external to the vehicle 100, the network devices including cloud-based network devices, central stations, back offices, and portable network devices. The transceivers 112 may perform pattern recognition, channel addressing, channel access control, and filtering operations.

[0085] The navigation module 114 executes navigation applications to provide navigation services. The navigation services may include a location identification service to identify the location where the vehicle 100 is located. The navigation services may also include guiding the driver and / or steering the vehicle 100 to a selected location. The navigation module 114 may communicate with a central station to collect map information indicating the level of traffic, the identification and location of transportation objects (e.g., the location and type of signs), path information, the location of turns, lane identification, ramp locations, etc. As an example, if the vehicle 100 is an autonomous vehicle, the navigation module 114 may guide the vehicle control module 103 along a selected route to a selected destination. The GPS and GNSS receivers 116 may provide vehicle state measurement information such as the rate and / or direction (or heading) of the vehicle 100 and other vehicles and objects (e.g., pedestrians and bicyclists) and / or global clock timing information. The GPS and GNSS receivers 116 may generate GPS signals provided to the vehicle control module 103. The GPS signals and the corresponding vehicle state measurement information may be delayed (i.e., have an associated latency) when received at the vehicle control module 103.

[0086] The infotainment module 107 may include and / or be connected to an audio system 122 and / or a video system, the video system including one or more displays (one display 120 is shown). The display 120 and the audio system 122 may be part of a human-machine interface. The display may include a cluster and / or a central console display, a head-up display, etc. Messages may be displayed, audibly played, and / or indicated via the display 120, the audio system 122, and / or via one or more other output devices. The infotainment module 107 may provide various proactive messages and information. The infotainment module 107 may, for example, direct a vehicle operator to a location near a turn to change lanes, and / or display other information.

[0087] The propulsion system 110 may include one or more torque sources, such as one or more electric motors and / or one or more engines (e.g., internal combustion engines). In Figure 1 the example shown, the vehicle 100 includes an engine 130 and one or more electric motors 132. The torque sources are independently controlled. The propulsion system 110 includes an electric motor control system 134 and an electric motor control module 136, the electric motor control system 134 including one or more electric motors 132, and the electric motor control module 136 may control the operation of one or more electric motors 132 based on signals from the vehicle control module 103.

[0088] The modules 102, 103, 107, 108 may communicate with each other via one or more buses 117 (such as a Controller Area Network (CAN) bus and / or other suitable interfaces). The vehicle control module 103 may control the operation of vehicle modules, devices, and systems based on feedback from the sensors 150.

[0089] The sensors 150 may include external sensors, internal sensors, vehicle state sensors, and other sensors. For example, as shown, the sensors 150 may include radar and / or lidar sensors 152, external imaging sensors (e.g., cameras) 154, wheel speed sensors 156, acceleration sensors (e.g., longitudinal and lateral acceleration sensors) 158, rate sensors (e.g., longitudinal and lateral rate sensors) 160, inertial measurement sensors 162, yaw rate sensors 164, and other sensors 166. The other sensors 166 may include wheel angle sensors and / or other vehicle state sensors and / or motion detection sensors.

[0090] External sensors can be used to detect objects outside the vehicle 100 and / or in the path of the vehicle 100. Internal sensors can include internal imaging sensors (e.g., cameras) and microphones or microphone arrays, which can be used to monitor the driver's body activities, eye movements, and / or gaze direction and / or interact with the driver. The internal sensors can also be used to detect gestures made by the driver, detect the orientation of the driver's body, detect the driver's speech, etc.

[0091] The vehicle motion request module 102 can include an arbitration module 172 and a profile generation module 174. The vehicle control module 103 can further include a feature request module (or requester) 176, a mode selection module 178, and a vehicle motion control module 179. The arbitration module 172 performs arbitration operations to determine which motion requests are to be satisfied, as described further below with respect to Figures 2-3 The profile generation module 174 generates motion requests (or profiles) and constraints based on the output of the arbitration module 172. The motion requests can include profiles of the generated (or target) vehicle states (e.g., a target profile of the vehicle speed). The vehicle motion control module 179 controls the actuators of the vehicle (e.g., the engine 130, the motor 132, the braking system 177, etc.) based on the motion requests and constraints generated by the profile generation module 174. Although modules 102 and 179 are shown as being implemented by the same vehicle control module (or controller) 103, modules 102 and 179 can be implemented by separate control modules (or controllers).

[0092] The mode selection module 178 can select a vehicle operation mode. As an example, the vehicle control module 103 can operate in a fully or partially autonomous mode and can control the propulsion system 110, the braking system 177, and the steering system 201. The steering system 201 includes a steering wheel angle sensor 203. In an embodiment, the vehicle control module 103 controls the operation of systems 101, 110, 177, and 201 based on interactions with the vehicle occupant (or driver). The vehicle control module 103 can i) perform autonomous operations such as steering, braking, accelerating, etc., and / or ii) display and / or audibly play messages and / or output messages and / or corresponding signals via other output devices.

[0093] The vehicle 100 can further include a memory 180. The memory 180 can store sensor data 182, parameters 184, applications 186, algorithms 188, historical data 190, and other data 192. The parameters can include, for example, sensor parameters and data from the sensors 150. The applications 186 can include applications executed by modules 102, 103, 107, 108.

[0094] Although the memory 180 and the vehicle control module 103 are shown as separate devices, the memory 180 and the vehicle control module 103 may be implemented as a single device. The memory 180 may also store historical data 190 and other data 192, such as driver driving patterns, data collected by and / or generated by modules 102, 103, traffic data, navigation data, map data, GPS data, path data, sensor data, etc.

[0095] The vehicle control module 103 may control the operation of the propulsion system 110, the video system including the display 120, the audio system 122, the braking system 177, the steering system 201, and / or other devices and systems according to parameters set by modules 102, 103, 107, 108. The vehicle control module 103 may set at least some of the parameters based on signals received from the sensors 150.

[0096] The vehicle control module 103 may receive electrical power from the power supply 105, and the electrical power may be supplied to the propulsion system 110, the braking system 177, the steering system 201, etc. The electrical power supplied to the motor 132, the braking system 177, the steering system 201, and / or their actuators may be controlled by the vehicle control module 103 to, for example, adjust: motor speed, torque, and / or acceleration; braking pressure; steering wheel angle; pedal position, etc. This control may be based on the outputs of the sensors 150, the navigation module 114, the GPS and GNSS receivers 116, and the data and information stored in the memory 180.

[0097] Modules 102 and / or 103 may determine various parameters, including vehicle speed and acceleration, yaw rate, inertial momentum, wheel angle, steering wheel angle, gear state, accelerator position, brake pedal position, and / or other information. Modules 102, 103 may further determine lane boundaries, lane position, road position, turning position, speed limit, object position, environmental conditions, etc.

[0098] Figure 2Illustrated is a vehicle longitudinal motion request and control (or speed-based control) system 200, which includes a feature request module (or motion requester) 176, a vehicle motion request module 102 (or final motion reference request), and a vehicle motion control system 204. Although the system 200 is mainly described with respect to longitudinal requests and control, the system 200 is also configured for lateral motion requests and control. The requester 176 can be, for example, a cruise control system requester, an adaptive cruise control system requester, a hands-free driving system requester, a single-pedal driving system requester, or other motion system requesters. The requester 176 can also be a driver acceleration requester. Each of the requesters 176 provides a speed (or rate) request, as well as acceleration and jerk constraints, to the arbitration module 172. The driver acceleration requester converts the driver acceleration request into a speed request, as well as acceleration and jerk constraints, which are provided to the arbitration module 172.

[0099] The arbitration module 172 arbitrates the motion requests (e.g., speed requests) received from the feature request module 176 and generates a resulting (or final) motion request, which is provided to the profile generation module 174. The arbitration is further described below. The vehicle motion request module (or system) 102 further includes an acceleration response map module 206, which generates an ARM and a tARM (or JRM - jerk response map), which includes global limits indicating the acceleration and deceleration behavior that the vehicle should follow, and is provided to the profile generation module 174. The profile generation module 174 generates a profile request (e.g., a speed request within a range), which is provided to the vehicle motion control module 179 of the vehicle motion control system 204. The vehicle motion control module 179 controls the operation of the device 210 based on the profile request and a selected control method (e.g., open-loop controller, PID controller, and MPC controller). One or more sensors 212 monitor the state of the device 210 and provide feedback information to the vehicle motion control module 179. In an embodiment, one or more sensors 212 provide a feedback value to the vehicle motion control module 179, which adjusts the torque request based on the speed error (e.g., the difference between the profile request and the feedback value). In an embodiment, the vehicle motion control module 179 implements a single vehicle model. The sensors 212 can include a vehicle speed sensor, a motor and / or engine speed sensor, a wheel speed sensor, etc.

[0100] In an embodiment, each of the feature request modules 176 provides a corresponding speed request and / or acceleration and jerk constraints, all of which may be in the same format. The vehicle motion control system 204 operates as a single global set of open-loop and closed-loop controllers for the implemented corresponding features. This simplifies design, coding, testing, deployment, maintenance, calibration, and engineering costs, and improves the vehicle longitudinal motion request and the hardware RAM, ROM, and throughput of the control system 200. The described system utilizes one global vehicle model and a global set of open-loop and closed-loop controllers to provide consistent performance among all requests for better driving quality, especially when switching between different request types.

[0101] Figure 3A vehicle motion request and control system 300 is shown. The vehicle motion request and control system 300 includes a feature layer, a command interpreter layer, and a supervisory control layer. The feature layer includes a feature request module 176, an acceleration response map module 206, and a feature requirement module 302. The feature request module 176 receives a feature requirement 304 from the feature requirement module 302. As several examples, the feature requirements can include a set (or reference, target) speed, a one-pedal driving deceleration or acceleration rate as a function of the accelerator pedal and speed, a deceleration rate based on the brake pedal, an autonomous control request, etc. The feature requirements can be generated and / or determined based on driver input 306, which can also include sources for acceleration and jerk constraints for each feature request model 176, the primary and secondary priorities of the motion requests of 176. The feature request module 176 can further receive a response 308 from the vehicle motion request module 102, which includes types (such as hardware constraints) of honor (acceptance), partial honor (actuator range constrained by type and value), rejection (arbitration failure, propulsion actuator failure) from the vehicle motion control system 204, and other constraints, such as the acceleration constraint 310 and the jerk constraint 344 generated by the profile generation module 174. The feature request module 176 generates a motion request (such as a speed request) 314 and constraints, such as an acceleration constraint 316 and a jerk constraint 318, based on the feature requirement 304, the response 343 to all requesters made by the arbitration module 172, the response 308 from the vehicle motion control module 179, the acceleration constraint 310, and the jerk constraint 344. The response 308 can include, for example, the maximum and minimum available torques of available torque sources, the maximum and minimum acceleration and / or deceleration values, the maximum and minimum jerk values, the maximum and minimum rates, etc. The response 308 can indicate when one or more devices (such as motors) are not working or not working properly, and thus limit the amount of available acceleration, deceleration, etc. Similarly, 308 is a response to requests of 340, 342, 312, and 310 and 344, 343 are responses to all requesters 176. Depending on the response 343 (e.g., acceptance, partial acceptance, or rejection), the requesters 176 can adjust their motion and constraints accordingly.

[0102] The command interpreter layer includes an arbitration module 172 and a profile generation module 174. The arbitration module 172 i) determines which motion requests 314 to accept based on feature requirements 304, reported faults, calibration values, and status values, and ii) selects a winner among the motion requests under consideration, and iii) generates an arbitrated motion request (or arbitrated speed request) 322 and corresponding constraints, such as an acceleration constraint 324 and a jerk constraint 326, which are provided to the profile generation module 174. In an embodiment, the motion request 322, acceleration constraint 324, and / or jerk constraint 326 are generated based on the winner of the arbitration module 314 and its corresponding motion request (e.g., speed request) 314 and constraints (such as acceleration constraint 316 and jerk constraint 318) or not from the ARM and tARM of the acceleration response map module 206 as specified by the feature requirement model 302. A fault may refer to a fault regarding a hardware component, such as a fault regarding a motor or a sensor. A status value may refer to the achieved vehicle speed, achieved vehicle acceleration (or deceleration), and / or achieved vehicle jerk.

[0103] The fault mode module 320 detects hardware and software (e.g., sensors, actuators, open-loop or closed-loop controllers, embedded control modules, and software implementations) faults and may report the faults, along with calibration values and status values, to the arbitration module 172. When there is one or more faults, the arbitration module 172 may determine that one or more features cannot be implemented and thus one or more of the motion requests 314 cannot be satisfied and avoid accepting motion requests from one or more corresponding feature request modules 176.

[0104] Based on the motion request 322, acceleration constraint 324, jerk constraint 326, the output of the fault mode module 320, and the response 308, the profile generation module 174 generates a motion request profile 340, an acceleration request profile 342, a jerk request profile 312, an acceleration constraint 310, and a jerk constraint 344. In an embodiment, the motion request profile 340, acceleration request profile 342, jerk request profile 312, acceleration constraint 310, and / or jerk constraint 344 are generated based on the motion request (or arbitrated speed request) 322 and corresponding constraints (such as the acceleration constraint 324 and jerk constraint 326 of the winner identified by the arbitration module 172) and the ARM and tARM from the acceleration response map module 206 as specified by the feature requirement module 302.

[0105] As an example, when the driver stops pressing on the brake pedal and starts pressing on the accelerator pedal of the vehicle to request a target speed greater than the current vehicle speed, the shift profile generation module limits how the speed, acceleration, and jerk profiles (or requests) are generated. The shift profile generation module 174 transitions from decelerating the vehicle to accelerating the vehicle in a smooth manner such that the vehicle does not experience a "clunk" as defined by the acceleration constraint 324 and the jerk constraint 326. This is an example when limiting the generated profile. The limitation can be performed by generating speed, acceleration, and / or jerk profiles as well as acceleration and jerk constraints.

[0106] The supervisory control layer includes a vehicle motion control system 204, and the vehicle motion control system 204 includes a vehicle motion control module 179 and sensors 212. The vehicle motion control module 179 generates a set of torque requests for all available propulsion actuators and an implemented behavior feedback signal 330 that indicates the status values of the entire control, actuation, sensing path. The vehicle motion control module 179 may not honor one or more of the received requests and / or one or more of the received constraints. For example, if the vehicle motion control module 179 operates in a particular mode for which the requests and / or constraints are not suitable for it, the vehicle motion control module 179 may not satisfy the requests and / or constraints. For example, if the vehicle motion control module 179 operates in a traction control mode, the acceleration request may not be satisfied. If a request and / or constraint is not satisfied, the vehicle motion request module 102 and thus modules 172, 174 can reset the request and / or constraint. In an embodiment, the vehicle motion control module 179 notifies modules 172, 174 when a request and / or constraint is satisfied and / or not satisfied. This indication can be provided by indicating the implemented speed, acceleration, and jerk, or can directly indicate whether a request and / or constraint has been satisfied by signaling. These indications can be provided back to one or more of modules 172, 174 and / or module 176 as part of a hardware constraint signal.

[0107] Figure 4 A method for generating motion requests and constraints for a vehicle motion control system (e.g., Figure 2 a speed-based control system 200) is shown. The following operations can be performed iteratively. At 400, a feature requirement module 302 may receive inputs and / or commands, which may be generated based on driver input. At 402, the feature requirement module 302 generates feature requirements based on the received inputs.

[0108] At 404, one or more in the feature request module 176 generate feature requests and constraints (e.g., acceleration and jerk constraints) based on feature requirements, hardware constraints, and profile constraints (i.e., constraints generated by the profile generation module 174). The feature requests include motion requests (e.g., speed requests).

[0109] At 406, the arbitration module 172 receives the feature requests and constraints generated by the feature request module 176.

[0110] At 408, the arbitration module 172 arbitrates the received feature requests to determine which one or more feature requests are at least partially satisfied. This is based on the output of the feature requirements module 302, hardware constraints, detected faults, calibration values, implemented vehicle states, and / or ARM and / or tARM.

[0111] At 410, the arbitration module 172 generates a resulting motion (or arbitration) request 322 and resulting constraints (e.g., acceleration constraint 324 and jerk constraint 326), which are provided to the profile generation module 174.

[0112] At 412, the profile generation module 174 generates i) profile requests for different parameters, such as a speed request profile 340, an acceleration request profile 342, and a jerk request profile 312, and ii) profile constraints (e.g., acceleration constraint 310 and jerk constraint 344).

[0113] At 414, the vehicle motion control module 179 controls one or more actuators (e.g., motors, engines, or other propulsion devices) based on one or more of the profile requests including the speed request profile, the acceleration request profile, and / or the jerk request profile and / or one or more profile constraints generated by the profile generation module 174. This can be based on the mode of operation and one or more requester requests that are satisfied. For example, in a speed control mode, the vehicle motion control module 179 monitors the speed request profile, adjusts one or more actuators based on the difference between the speed request profile and the measured speed (e.g., speed error), and may not monitor and / or utilize the acceleration request profile and the jerk request profile. The profile constraints can be the same as or different from the resulting constraints generated by the arbitration module 172. The profile generation module 174 can modify the resulting constraints generated by the arbitration module 172 and output the modified constraints to the vehicle motion control module 179 as profile limits.

[0114] At 416, the vehicle motion control module 179 generates a hardware constraint signal including hardware constraints. At 418, the vehicle motion control module 179 monitors the vehicle behavior and generates an implemented behavior feedback signal indicating the implemented vehicle state.

[0115] At 420, the fault mode module 320 detects one or more faults, generates calibration values, and / or generates vehicle equipment status values. The vehicle equipment status values can include the achieved vehicle speed, acceleration, and / or jerk, as well as the achieved engine and / or motor speed. The calibration values can include motor and / or engine calibration values, such as calibration voltage, current level, fuel supply level, air flow rate, timing information, etc. At 422, the detected fault information, calibration values, and vehicle equipment status values are provided to the arbitration module 172. Operation 408 can be performed after operation 422.

[0116] In an embodiment, the feature request module 176 requests vehicle behavior as an expected speed request and acceleration and jerk constraints, including corresponding vehicle speed ranges. Arbitration of multiple speed requests is performed based on the feature requirement module 302 through vehicle technical specifications, calibration, fault modes, and hardware limitations. A supervision layer constraint feedback is provided for system understanding. The feedback information includes hardware limitations, diagnostic status (including range) information. The arbitration module operates based on this information and generates an arbitration output (or arbitration information). The supervision layer trajectory speed feedback can include the future system behavior range. The arbitration module reports the "winner" of the performed arbitration to the profile generation module by indicating the motion request and the corresponding constraints. The brake pedal position can be provided as an input to the feature requirement module 302 and mapped to the vehicle speed request via one of the feature request modules. The described vehicle motion requests and the operation of the control system 300 ensure a smooth transition between speed requests.

[0117] Figure 5 An example diagram is shown when a speed profile with a specific format is generated based on changes in pedal position and target speed. A pedal position curve 1100 and a target speed curve 1102 are shown. The pedal position curve 1100 is an example illustration of the change in accelerator pedal position. The accelerator pedal position changes from a released state 1104 to a depressed state 1106. The target speed transitions from a low (or zero) speed state 1110 to a high (or non-zero speed) state 1112. The low speed state corresponds to the released state 1104 and the high speed state 1112 corresponds to the depressed state 1106.

[0118] Due to the change in pedal position and the corresponding change in target speed, a speed (or rate) profile 1120 is generated. The speed profile 1120 of rate versus time includes an initial acceleration (or first non-linear) portion 1122, a deceleration (or second non-linear) portion 1124, and a speed maintenance portion 1126. A transition portion 1128 may or may not be included between portions 1122, 1124. The speed profile 1120 can be generated by Figures 1-3An example of a speed request generated by the profile generation module 174. The acceleration request (or profile) can be determined by differentiating the speed profile. The jerk request (or profile) can be determined by differentiating the acceleration request (or profile).

[0119] The acceleration section 1122 extends from a first point at time t0 and rate v0 to a second point at time t1 and rate v1. The transition section 1128 extends from the second point to a third point at time t2 and rate v2. The deceleration section extends from the third point to a fourth point at time t3 and rate v3. Figure 5 The method provides an example of how the times t1, t2, t3 and the rate v1 can be determined. The initial state occurs at t0 and is v0, a0 and j0, all of which are known conditions, and v0 can be the current reference speed or the measured speed, depending on whether closed-loop or open-loop control is selected. The transition state begins at t1 and is v1, a1 and j0, where only a1 is a known condition, i.e., the maximum / minimum acceleration. The final target state begins to occur at t3 and is v3, a3 and j3, all of which are known conditions.

[0120] Traditionally, the target reference (or parameter) is typically expected to be a series of references within a target time window (or reference range) to achieve more accurate and robust closed-loop control. The examples disclosed herein provide a method for generating a speed range for a vehicle or any controlled moving object with respect to constraints on acceleration (e.g., ARM) and jerk (e.g., +tARM). The disclosed examples utilize seven known conditions, v0, a0, j0, a1, v3, a3 and j3, where v0 is the current reference speed, a0 is the current reference acceleration, j0 is the maximum / minimum jerk constraint, a1 is the maximum / minimum acceleration constraint, v3 is the target speed, a3 is the target acceleration, and j3 is the minimum / maximum jerk constraint. This includes: a current reference state, which includes three known conditions, which are the current reference vehicle rate v0, the current reference acceleration a0 and the current maximum / minimum jerk constraint j0; a transition state, which includes one independent known condition, which is the maximum / minimum acceleration constraint a1; and a target reference state, which includes the other three known conditions, which are the target vehicle rate v3, the target acceleration a3 and the target minimum / maximum jerk constraint j3. Given the known conditions (or current, transition and target parameter states), f0(v0, a0 and j0), a1 and f t (v3, a3 and j3), two quadratic functions f0 and f are determined t . The acceleration constraint a1 and the jerk constraints j0 and j3 are used to determine the time required to reach the target rate v3.

[0121] In an embodiment, portions 1122 and 1124 are determined based on a jerk constraint (tARM), and portions 1126 and 1128 are determined based on an acceleration constraint (ARM). The acceleration and jerk constraints (e.g., ARM and tARM) can be provided via and / or based on vehicle specifications stored in a memory, inputs from an upstream feature request module 176, inputs from a remote device communicating with the vehicle, and / or hardware limitations and / or faults obtained from downstream components.

[0122] Biquadratic function of the vehicle speed profile

[0123] The following examples can apply to both closed-loop and open-loop control of vehicle states (including speed, acceleration, and jerk states).

[0124] The speed profile 1120 is a vehicle speed profile based on a biquadratic function, which includes three portions 1122, 1128, and 1124 connected at times t1 and t2. The first non-linear portion 1122 can be defined as a first quadratic function that is valid for the speed profile between t0 and t1. The transition portion 1128 can be defined as a linear function that is valid for the speed profile between t1 and t2. The second non-linear portion 1124 can be defined as a second quadratic function that is valid for the speed profile between t2 and t3.

[0125] The three portions 1122, 1128, and 1124 have the following characteristics respectively: 1) transitioning from the current reference acceleration to the requested maximum / minimum acceleration (constrained by the current jerk constraint), 2) maintaining the maximum / minimum acceleration (constrained by the requested acceleration constraint), 3) transitioning from the requested acceleration to the target acceleration (constrained by the target jerk constraint).

[0126] The first quadratic function of the first non-linear portion 1122 that is valid for the speed profile between t0 and t1 can be represented by Equation 1, and the corresponding acceleration and jerk can be represented by Equations 2 and 3, where y is the speed, a is the current jerk, b is the current reference acceleration, and c is the current reference speed.

[0127]

[0128] y′ = at + b (2)

[0129] y″ = a (3)

[0130] At t = t0 = 0, the following conditions are known: i) a = y″ t0 , ii) b = y′ t0 , and iii) c = y t0 .

[0131] The linear function for the transitional portion 1128 of the velocity profile that is valid between t1 and t2 can be represented by Equation 4. Equation 5 represents the corresponding acceleration, where m is the slope of the linear function.

[0132] y = mt + d (4)

[0133] y′ = m (5)

[0134] At t = t0 = 0, it is known that m = y′ dsrd , where y′ dsrd is the requested acceleration constraint.

[0135] The second quadratic function for the second non - linear portion 1124 of the velocity profile that is valid between t2 and t3 can be represented by Equation 6. Equations 7 and 8 represent the corresponding acceleration and jerk of Equation 6.

[0136]

[0137] y′ = ez + f (7)

[0138] y″ = e (8)

[0139] At z = 0, the following conditions are known: i) e = y″ z0 , ii) f = y′ z0 , and iii) g = y z0 , where e is the target jerk, f is the target acceleration, and g is the target velocity.

[0140] Equations 29 - 32 can be used to determine the tangent point of portions 1122 and 1124 at time t t , where Equation 9 represents when the two portions have the same velocity at t t , Equation 10 represents when the two portions 1122, 124 have the same acceleration at t t , and Equation 11 represents when the relationship between the coordinate systems of the two quadratic curves of the two portions 1122, 1124. The tangent point of portions 1122 and 1124 at time t t can be represented as Equation 12.

[0141]

[0142] at + b = ez + f (10)

[0143] z = t - t3 (11)

[0144]

[0145] Theorem I: If the following Condition 1 is satisfied, then a negative discriminant can be determined:

[0146] (a - e)(c - g) > 0 (1)

[0147] Theorem II: If the following condition 2 is satisfied, a positive discriminant can be determined:

[0148] (a - e)(c - g) < 0 (2)

[0149] Theorem III: By setting a = -a and e = -e as follows, a negative discriminant can be made into a positive discriminant.

[0150] Theorem IV: For the following possible solutions t t1 and t t2 , for all conditions t tl < t t2 it holds (see Proof IV below). Thus t t2 is the only relevant solution. Equations 13 - 15 can represent t t1 , t t2 and t t .

[0151]

[0152]

[0153]

[0154] The profile generation module 174 can determine whether it is the transition (or linear) part 1128 by performing the following operations. The acceleration at the tangent point can be determined using Equation 16.

[0155] y′ tt = at t + b (16)

[0156] The requested acceleration is based on the vehicle technical specification (VTS) acceleration response map (ARM) or the acceleration constraint of the acceptance feature request module specified as y′ dsrd . If the following condition 3 is true, the linear part 1128 is required.

[0157] y′ tt > y′ dsrd (3)

[0158] Otherwise, the linear part 1128 is not required, and thus the second 1122 is connected to the part 1124, and one part is missing.

[0159] When the linear part 1128 is included, assuming the linear function 1128 adopts the format of Equation 19, Equations 17 - 18 can be used to determine the first transition point t1 between the first quadratic function and the linear function.

[0160] y' dsrd = at1 + b (17)

[0161]

[0162] y = y' dsrd t + d (19)

[0163] At point t1, equations 40 and 41 are satisfied.

[0164]

[0165] d = v1 - y' dsrd t1 (21)

[0166] Equations 22 and 23 can be used to determine the second transition point t2 between the second quadratic function and the linear function.

[0167] y' dsrd = e(t2 - t3) + f (22)

[0168]

[0169] Therefore, since equation 30 is satisfied, equations 24 - 29 are satisfied. Equation 31 is also satisfied.

[0170]

[0171]

[0172]

[0173]

[0174]

[0175]

[0176] y' dsrd = e(t2 - t3) + f (30)

[0177]

[0178] When the linear part 1128 is not included, both transition points t1 and t2 can be determined according to equation 32, while t3 remains the same as when the linear part 1128 is included. This occurs when the transition part 1128 is not included and v1 = v2.

[0179] t1 = t2 = t t (32)

[0180] Proofs I, II, and III only consider the condition ae < 0. If the discriminant (a - e)(af 2 - eb 2 + 2ae(c - g)) ≥ 0, then t t2 is the actual solution because swapping the signs of a and e will result in a negative discriminant. If the discriminant (a - e)(af 2 - eb 2 + 2ae(c - g)) < 0, then there are two possibilities, labeled as Case I and Case II below.

[0181] Case I:

[0182]

[0183] (a - e) < 0 implies a < 0 and e > 0

[0184] (-|a|f 2 - |e|b 2 + 2ae(c - g)) > 0

[0185] (2ae(c - g)) > |a|f 2 + |e|b 2

[0186] (2ae(c - g)) > 0

[0187] (c - g) < 0

[0188] If the signs of a and e are flipped, then (a - e) > 0, or a > 0 and e < 0 and

[0189] (2ae(c - g)) > |a|f 2 + |e|b 2 > - |a|f 2 - |e|b 2

[0190] (2ae(c - g)) > - |a|f 2 - |e|b 2

[0191] -(2ae(c - g)) < |a|f 2 + |e|b 2

[0192] -(2ae(c - g)) < 0

[0193] (c - g) < 0

[0194] Case II:

[0195]

[0196] (a - e) > 0 means a > 0 and e < 0

[0197] (|a|f 2 + |e|b 2 + 2ae(c - g)) < 0

[0198] 2ae(c - g) < -|a|f 2 -|e|b 2

[0199] 2ae(c - g) < 0

[0200] If the signs of a and e are flipped, then (a - e) < 0, or a < 0 and e > 0 and

[0201] (2ae(c - g)) < -af 2 + eb 2

[0202] (2ae(c - g)) < |a|f 2 + |e|b 2

[0203] Exchanging the signs of a and e results in a positive discriminant.

[0204] For the proof of IV, given a * e < 0 under all conditions, then

[0205] a * e - a 2 < -a 2

[0206] a 2 -a * e > a 2

[0207] a(a - e) > a 2

[0208] a(a - e) > 0

[0209] Therefore, under all conditions, the following will hold:

[0210]

[0211]

[0212] t t2 ≥ t t1

[0213] Figure 6 A method for generating velocity, acceleration, and jerk profiles is shown. The following operations can be performed iteratively. The method can be performed by Figures 1-3 the profile generation module 174.

[0214] At 1200, the profile generation module 174 determines the tangent point of two quadratic functions and its corresponding acceleration. This can be done using equations 33 - 35.

[0215]

[0216] v′ tt = at t + b (34)

[0217] D = (a - e)(af 2 - eb 2 + 2ae(c - g)) (35)

[0218] At 1202, the profile generation module 174 determines whether an acceleration constraint needs to be applied. If so, operation 1204 is performed; otherwise, operation 1206 is performed. If V′ tt > V′ max_dsrd or v′ tt < v′ min_dsrd , then the acceleration constraint is applied.

[0219] At 1204, the profile generation module 174 determines t1 and t2 in the case of applying an active acceleration constraint using equations 36 - 38.

[0220]

[0221]

[0222]

[0223] At 1206, the profile generation module 174 determines t1 and t2 in the case of not applying an active acceleration constraint using equation 39, where t1 = t t and t2 = t t .

[0224]

[0225] At 1208, the profile generation module 174 determines t3 using equation 40.

[0226]

[0227] At 1210, the profile generation module 174 initializes the first elements of the requested velocity, acceleration, and jerk ranges, where v″ dsrd_hrzn [0] = v″ dsrd , v′ dsrd_hrzn [0] = v′ dsrd , and V dsrd_hrzn [0] = V dsrd .

[0228] At 1212, the profile generation module 174 initializes i to 1. At 1214, the profile generation module 174 determines whether i is less than n, where n is the time range size. If i is not less than n, the method can end; otherwise, operation 1216 is performed.

[0229] At 1216, the profile generation module 174 sets the range t to be equal to i times the roster rate. At 1218, the profile generation module 174 determines whether t is less than t1. If so, operation 1220 is performed; otherwise, operation 1222 is performed.

[0230] At 1220, the profile generation module 174 updates the velocity, acceleration, and jerk request outputs according to the first set of settings as follows, where v″ dsrd_hrzn [i] = a, v′ dsrd_hrzn [i] = a * t + b, and v dsrd_hrzn [i] = 1 / 2 * a * t * t + b * t + c.

[0231] At 1222, the profile generation module 174 determines whether t is less than t2. If so, operation 1224 is performed; otherwise, operation 1226 is performed.

[0232] At 1224, the profile generation module 174 updates the velocity, acceleration, and jerk request outputs according to the second set of settings as follows, where v″ dsrd_hrzn [i] = 0.0, v′ dsrd_hrzn [i] = y′ dsrd , and v dsrd_hrzn [i] = y′ dsrd *(t - t1) + v1.

[0233] At 1226, the profile generation module 174 determines whether t is less than t3. If so, operation 1228 is performed; otherwise, operation 1230 is performed.

[0234] At 1228, the profile generation module 174 updates the velocity, acceleration, and jerk request outputs according to the third set of settings as follows, where t tz = t - t3, v” dsrd_hrzn [i] = e, v' dsrd_hrzn [i] = e * t tz + f, and v dsrd_hrzn [i] = 1 / 2 * e * t tz *t tz + ft tz + g.

[0235] At 1230, the profile generation module 174 updates the velocity, acceleration, and jerk request outputs according to a fourth set of settings as follows, where v” dsrd_hrzn [i]=0.0, v' dsrd_hrzn [i]=v' trgt , and v dsrd_hrzn [i]=v trgt .

[0236] At 1232, the profile generation module 174 increments i by 1 and then returns to operation 1214.

[0237] The above example includes a method for calculating a continuous / smooth desired reference velocity trajectory (continuous acceleration) when moving away from an initial velocity v0, which trajectory adheres to acceleration and jerk constraints (starting trajectory). The method is used in each cycle of a selected roster. The method determines how many sections (e.g., a starting constant jerk section - section 1, a constant acceleration section - section 2, an ending constant jerk section - section 3, and a constant velocity section - section 4) are needed to construct a profile / range. For a selected range size (e.g., 20), the motion profile / range can contain different combinations of sections (e.g., only section 1, sections 1 and 2, sections 1, 2, and 3, sections 1, 2, 3, and 4, only section 2, sections 2 and 3, sections 2, 3, and 4, only section 3, sections 3 and 4, only section 4), depending on the known conditions of a given cycle. The method performs these operations based on acceleration and jerk constraints received from an upstream implemented algorithm(s) from which the velocity profile is calculated and uses this information in the trajectory formula. A range of points is determined to achieve a target velocity with corresponding acceleration and jerk constraints. This measure applies maximum / minimum jerk constraints in section 1, maximum / minimum acceleration constraints in section 2, minimum / maximum jerk constraints in section 3, and reaches the target velocity in section 4. Thus, the time to reach the velocity target under any given set of known conditions (e.g., v0, a0, j0, v3, a3, and j3) is minimized / determined.

[0238] Figure 4 and Figure 6 The above operations of and are intended as illustrative examples. Depending on the application, the operations can be performed sequentially, synchronously, simultaneously, continuously, or in a different order during overlapping time periods. Additionally, depending on the implementation and / or sequence of events, any of the operations may not be performed or skipped.

[0239] The above example includes a speed-based architecture that does not require calibration of the requested characteristics for torque conversion. The architecture is simplified relative to the number of closed-loop control devices, including a controller, a device, and a feedback / sensor device, included in each requester. The architecture has a single vehicle motion control system having a vehicle motion control module, a device, and sensors for fulfilling requests from multiple requesters.

[0240] The foregoing description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or its use. The broad teachings of the disclosure can be implemented in a variety of forms. Thus, although the disclosure includes specific examples, the true scope of the disclosure should not be so limited since other modifications will become apparent upon study of the drawings, the specification, and the following claims. It should be understood that one or more steps within a method can be executed in a different order (or concurrently) without altering the principles of the disclosure. Further, while each of the embodiments described above is characterized as having certain features, any one or more of those features described with respect to any embodiment of the disclosure can be implemented in and / or combined with the features of any other embodiment of the disclosure, even if the combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and permutations of one or more of the embodiments with each other are still within the scope of the disclosure.

[0241] Spatial and functional relationships between elements (e.g., between modules, circuit elements, semiconductor layers, etc.) are described using various terms, including "connected," "engaged," "coupled," "adjacent," "next to," "on top of," "above," "below," and "disposed." Unless explicitly described as "direct," when describing the relationship between a first element and a second element in the disclosure above, the relationship can be a direct relationship in which no other intervening elements exist between the first and second elements, but can also be an indirect relationship in which one or more intervening elements exist between the first and second elements (spatially or functionally). As used herein, the phrase "at least one of A, B, and C" should be construed to mean logic (A OR B OR C) using a non-exclusive logical OR and should not be construed to mean "at least one of A, at least one of B, and at least one of C."

[0242] In the drawings, as indicated by the arrowheads, the direction of the arrow generally represents the flow of information of interest depicted (such as data or instructions). For example, when component A and component B exchange multiple types of information but the information transmitted from component A to component B is relevant to the depiction, the arrow can point from component A to component B. This one-way arrow does not imply that no other information is transmitted from component B to component A. Additionally, for the information sent from component A to component B, component B can send a request for the information or an acknowledgement of the receipt of the information to component A.

[0243] In the present application (including the following definitions), the term "module" or the term "controller" may be replaced by the term "circuit". The term "module" may refer to, be part of, or include the following: application specific integrated circuit (ASIC); digital, analog, or mixed analog / digital discrete circuits; digital, analog, or mixed analog / digital integrated circuits; combinational logic circuits; field programmable gate arrays (FPGA); processor circuits (shared, dedicated, or group) that execute code; memory circuits (shared, dedicated, or group) that store code executed by the processor circuits; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system-on-chip.

[0244] A module may include one or more interface circuits. In some examples, the interface circuit may include a wired or wireless interface connected to a local area network (LAN), the Internet, a wide area network (WAN), or a combination thereof. The functionality of any given module of the present disclosure may be distributed among multiple modules connected via the interface circuit. For example, multiple modules may allow load balancing. In additional examples, a server (also referred to as remote or cloud) module may perform some functions on behalf of a client module.

[0245] As used above, the term code may include software, firmware, and / or microcode, and may refer to programs, routines, functions, classes, data structures, and / or objects. The term shared processor circuit encompasses a single processor circuit that executes some or all of the code from multiple modules. The term group processor circuit encompasses a processor circuit that, in combination with additional processor circuits, executes some or all of the code from one or more modules. References to multiple processor circuits encompass multiple processor circuits on discrete die, multiple processor circuits on a single die, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the above. The term shared memory circuit encompasses a single memory circuit that stores some or all of the code from multiple modules. The term group memory circuit encompasses a memory circuit that, in combination with additional memory, stores some or all of the code from one or more modules.

[0246] The term memory circuit is a subset of the term computer-readable medium. As used herein, the term computer-readable medium does not cover transitory electrical or electromagnetic signals propagated through a medium such as on a carrier wave; thus, the term computer-readable medium can be considered tangible and non-transitory. Non-limiting examples of non-transitory, tangible computer-readable media are non-volatile memory circuits such as flash memory circuits, erasable programmable read-only memory circuits, or mask read-only memory circuits, volatile memory circuits such as static random access memory circuits or dynamic random access memory circuits, magnetic storage media such as analog or digital magnetic tape or hard disk drives, and optical storage media such as CDs, DVDs, or Blu-ray discs.

[0247] The devices and methods described in this application can be implemented, in part or in whole, by a special-purpose computer created by configuring a general-purpose computer to perform one or more specific functions implemented in a computer program. The functional blocks, flowchart components, and other elements described above serve as a software specification, which can be converted into a computer program by routine work of a skilled technician or programmer.

[0248] A computer program includes processor-executable instructions stored on at least one non-transitory, tangible computer-readable medium. A computer program may also include or rely on stored data. A computer program can cover a basic input / output system (BIOS) that interacts with the hardware of a special-purpose computer, device drivers that interact with specific devices of a special-purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0249] A computer program can include: (i) descriptive text to be parsed, such as HTML (HyperText Markup Language), XML (eXtensible Markup Language), or JSON (JavaScript Object Notation), (ii) assembly code, (iii) object code generated from source code by a compiler, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc. By way of example only, source code can be written using the syntax from languages including: C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Fortran, Perl, Pascal, Curl, OCaml, HTML5 (HyperText Markup Language 5th Edition), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Visual Lua, MATLAB, SIMULINK and

Claims

1. A motion system for a vehicle, the motion system comprising: an arbitration module configured to arbitrate the requests and one or more constraints received from each of the plurality of feature request modules to generate a resulting request and one or more resulting constraints; a profile generation module configured to determine whether to modify at least one of the derived request and the one or more derived constraints, and to output i) the derived request or a modified version of the derived request as a first profile request, and to output ii) the one or more derived constraints or a modified version of the one or more derived constraints as the one or more profile constraints; as well as A vehicle motion control module is configured to control one or more actuators of the vehicle based on the first profile request and the one or more profile constraints.

2. The exercise system according to claim 1, wherein: The arbitration module is configured to arbitrate requests and one or more constraints received from each of the plurality of feature request modules based on the one or more feature requirements to generate a resulting request and one or more resulting constraints.

3. The exercise system according to claim 1, wherein: The arbitration module is configured to arbitrate requests and one or more constraints received from each of the plurality of feature request modules based on the detected hardware failure to generate a derived request and one or more derived constraints.

4. The exercise system according to claim 1, wherein: The arbitration module is configured to arbitrate requests and one or more constraints received from each of the plurality of feature request modules based on the acceleration response map to generate a derived request and one or more derived constraints.

5. The exercise system according to claim 1, wherein: a vehicle motion control module configured to monitor at least one state of the vehicle and generate a behavior signal indicative of achievement of the at least one state; and The arbitration module is configured to arbitrate requests and one or more constraints received from each of the plurality of feature request modules based on the implemented behavior signal to generate a derived request and one or more derived constraints.

6. The exercise system of claim 1, wherein: The profile generation module is configured to generate a plurality of profile requests based on the obtained request or a modified version of the obtained request, wherein the plurality of profile requests includes a first profile request; and The vehicle motion control module is configured to control one or more actuators of the vehicle based on the plurality of profile requests.

7. The exercise system according to claim 6, wherein: The plurality of profile requests include a speed request, an acceleration request, and a jerk request.

8. The exercise system according to claim 1, wherein: The profile generation module is configured to output a first profile request based on the acceleration response map.

9. The exercise system of claim 1, wherein: The vehicle motion control module is configured to output at least one hardware constraint; and The profile generation module is configured to output a first profile request based on at least one hardware constraint.

10. The exercise system according to claim 1, wherein: The plurality of feature request modules are configured to: i) receive a first profile request and one or more profile constraints from a profile generation module, and ii) generate a request and one or more constraints generated by each of the plurality of feature request modules based on at least one of the first profile request and the one or more profile constraints.

Images