GENERATION AND CONTROL OF LONGITUDINAL MOVEMENT PROFILES TO ACHIEVE PERFORMANCE GOALS

Abstract

A motion system for a vehicle comprising: a profile generation module configured to receive an actual reference speed, an actual reference acceleration, a desired speed, and a desired acceleration for the vehicle and to generate a speed profile based on the actual reference speed, the actual reference acceleration, the desired speed, and the desired acceleration, comprising determining a first non-linear portion and a second non-linear portion of the speed profile, wherein the first non-linear portion is associated with acceleration, wherein the second non-linear portion is associated with deceleration, and wherein the speed profile comprises the acceleration of the vehicle from the actual reference speed to the desired speed;and a vehicle motion control module configured to control one or more actuators of the vehicle based on the speed profile;

Description

INITIATIONThe information in this section is intended to generally illustrate the context of the disclosure. Work of the present inventors, insofar as described in this section, as well as aspects of the description that may not be prior art at the time of filing, are neither expressly nor silently admitted as prior art against the present disclosure.The present disclosure relates to vehicle motion request and control systems that operate based on requests from multiple requesters.A host vehicle may include various motion control systems that assist the driver in, for example, partially or fully autonomous driving. For example, a 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 assistance in speed and acceleration (or deceleration) control as well as other assistance. The cruise control system and the adaptive cruise control system serve to maintain a set speed. The adaptive cruise control system also serves to maintain a safe distance from a vehicle in front of the host vehicle. The hands-free driving system autonomously controls the host vehicle, e.g., on a highway, including control of speed, acceleration, deceleration, and steering of the host vehicle. The one-pedal drive system automatically brakes the host vehicle when the driver releases the accelerator pedal. The host vehicle may automatically apply the brakes without requiring the driver to apply a brake pedal.SUMMARYA motion system for a vehicle is disclosed. The motion system includes: a profile generation module configured to obtain an actual reference speed, an actual reference acceleration, a target speed, and a target acceleration for the vehicle, and generate a velocity profile based on the actual reference speed, the actual reference acceleration, the target speed, and the target acceleration, and acceleration constraints (e.g., minimum and maximum constraints) and jerk constraints (e.g., minimum and maximum constraints), including determining a first non-linear portion and a second non-linear portion of the velocity profile, the first non-linear portion associated with the acceleration or the deceleration, the second non-linear portion associated with the deceleration or the acceleration, and wherein the velocity profile comprises the acceleration of the vehicle from the actual reference velocity to the desired velocity; and a vehicle motion control module configured to control one or more actuators of the vehicle based on the velocity profile.In other features, the first non-linear portion is a first quadratic function and the second non-linear portion is a second quadratic function that is different from the first quadratic function and that has the opposite sign of the jerk constraint.In further features, the motion system further includes: a first sensor that generates an output signal indicative of the actual reference speed and / or the actual reference acceleration; and an arbitration module that generates an output signal indicative of the desired speed and / or the desired acceleration. The profile generation module is configured to receive both the actual reference speed and the actual reference acceleration from the first sensor and to receive both the target speed and the target acceleration from the arbitration module.In other features, the profile generation module is configured to determine, when generating the velocity profile, whether to generate a transition portion for the transition from the first non-linear portion to the second non-linear portion.In other features, the transition portion is linear in velocity (e.g., constraint in acceleration). The transition portion is included when an acceleration constraint is applied. The transition portion is not included when the acceleration constraint is not applied.In other features, the transition portion is linear. The transition section is included when there is a tangential point of the first non-linear section and the second non-linear section that is outside of the minimum and maximum acceleration constraints. The transition section is not included when there is a tangential point of the first non-linear section and the second non-linear section that is within the minimum and maximum acceleration constraints.In other features, the profile generation module is configured to determine the first non-linear portion, the second non-linear portion, and a transition portion between the first non-linear portion and the second non-linear portion by: determining a first time point of a first point connecting the first non-linear portion to the transition portion; determining a second time point of a second point connecting the transition portion to the second non-linear portion; determining a third time point of a third point at the end of the second non-linear portion; and determining the first non-linear portion, the transition portion, and the second non-linear portion based on a time horizon for achieving the desired speed and the first time point, the second time point, and the third time point.In other features, the profile generation module is configured to generate the velocity profile to have a continuous, smooth trajectory from the actual reference velocity to the target velocity.In other features, the profile generation module is configured to receive acceleration and jerk constraints and generate a transition portion between the first non-linear portion and the second non-linear portion that satisfies the acceleration and jerk constraints.In other features, the profile generation module is configured to determine an endpoint of a starting trajectory of the speed profile and remain at the desired speed at the endpoint.In other features, the profile generation module is configured to: generate a linear transition portion for the transition from the first non-linear portion to the second non-linear portion.In other features, the vehicle motion control module is configured to generate an acceleration constraint and a jerk constraint based on the status of the vehicle hardware; and the profile generation module is configured to generate the speed profile based on the acceleration constraint and the jerk constraint received from the vehicle motion control module if the constraints are more restrictive than those from the arbitration module.In other features, the vehicle motion control module is configured to control the one or more actuators to move the vehicle according to the velocity profile.In other features, a motion request and control system for a vehicle is disclosed. The method includes: determining an actual reference speed, an actual reference acceleration, a target speed, and a target acceleration for the vehicle; generating a speed profile based on the actual reference speed, the actual reference acceleration, the target speed, and the target acceleration, as well as acceleration constraints (e.g., minimum and maximum constraints) and jerk constraints (e.g., minimum and maximum constraints), including determining a first non-linear portion and a second non-linear portion of the speed profile, wherein the first non-linear portion is associated with the acceleration, wherein the second non-linear portion is associated with the deceleration, and wherein the speed profile includes the acceleration of the vehicle from the actual reference speed to the target speed; controlling one or more actuators based on the speed profile such that the vehicle moves according to the speed profile.In other features, the first non-linear portion is a first quadratic function and the second non-linear portion is a second quadratic function different from the first quadratic function.In other features, the method further comprises: generating, via a first sensor, an output signal indicative of the actual reference speed and / or the actual reference acceleration; generating, via an arbitration module, an output indicative of both the target speed and the target acceleration; receiving, from the first sensor, the actual reference speed and the actual reference acceleration; and receiving, from the arbitration module, both the target speed and the target acceleration.In other features, the method further includes determining, upon generating the velocity profile, whether to generate a transition portion to transition from the first non-linear portion to the second non-linear portion.In other features, the method further comprises determining the first non-linear portion, the second non-linear portion, and a transition portion between the first non-linear portion and the second non-linear portion by: determining a first time point of a first point connecting the first non-linear portion to the transition portion; determining a second time point of a second point connecting the transition portion to the second non-linear portion; determining a third time point of a third point at the end of the second non-linear portion; and determining the first non-linear portion, the transition portion, and the second non-linear portion based on a time horizon for achieving the desired speed and the first time point, the second time point, and the third time point.In other features, the method further includes: obtaining acceleration constraints and jerk constraints; and generating a transition portion between the first non-linear portion and the second non-linear portion that satisfies the acceleration and jerk constraints.In other features, the method further comprises: creating a linear transition portion for the transition from the first non-linear portion to the second non-linear portion.Further areas of applicability of the present disclosure will become apparent from the detailed description, claims and drawings. The detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGSThe present disclosure will become more fully apparent from the detailed description and the accompanying drawings, in which: FIG. 1 is a functional block diagram of an exemplary host vehicle having a speed-based control system with a vehicle motion request module according to the present disclosure; FIG. 2 is a functional block diagram of an example of a 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; FIG. 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; FIG. 4 shows an example of a method for generating motion requests and constraints for a vehicle motion control system according to the present disclosure; FIG. 5 is a diagram showing an example in which a speed profile having a certain format is generated based on changes in the pedal position and the target speed according to the present disclosure; and FIG. 6 illustrates a method for generating speed, acceleration, and jerk profiles in accordance with the present disclosure.In the drawings, reference numerals may be reused to identify similar and / or identical elements.DETAILED DESCRIPTIONA host vehicle may include multiple motion requesters that may request driving at a desired speed, for example. For example, a host vehicle may include a cruise control system, an adaptive cruise control system, a hands-free driving system, a one-pedal driving system, or another motion request system. A host vehicle may also include devices that receive driver acceleration requests, e.g., an accelerator sensor that senses the position of the accelerator pedal and assigns it to a desired acceleration based on vehicle technical specification (VTS). Each of these motion requests may be communicated to a controller in the form of a tempo or speed request. The driver acceleration or torque requests may be converted to speed requests. A vehicle may include any number of motion control systems that generate corresponding speed requirements.An example implementation for handling the speed requests includes converters that convert the speed requests to torque requests. When multiple requests are received simultaneously, an arbiter decides which of the requests should be met. A torque profile generator then generates a torque profile to follow based on fulfilment of one or more requirements. A controller controls a plant of the vehicle based on the torque profile. The plant may comprise one or more motors and / or a machine. Sensors sense conditions of the plant, and the outputs of the sensors (e.g., vehicle movements) are then used as feedback to adjust the requested torque profile and / or control of the plant to meet the one or more requirements.The implementation indicated is associated with disadvantages. For example, each requester can have its own unique request format and a corresponding converter and a closed loop control circuit for regulating the system. Thus, the same operations are performed multiple times, and multiple vehicle models and controls and rules are used when each requester prepares its own torque requests for arbitration. There are also inefficiencies and inaccuracies in converting desired vehicle movements (or speed requirements) to the overall vehicle torque. The conversions and control are associated with high costs for the design, coding, testing, deployment, maintenance, calibration and thus engineering, as well as high consumption of hardware RAM and ROM throughput. If not all models and controllers of the same type are identical, power fluctuations may also occur in the requirements, which may lead to poor drive quality, in particular when changing between different types of requirements. In addition, acceleration maps such as a target acceleration map (ARM) and a target transient acceleration map (tARM, which may also be referred to as a target jerk map (JRM)) and the corresponding performance metrics must be converted to axle torque so that they can be used in a driver torque request system. An acceleration characteristic map, also referred to as a vehicle speed horizon, defines a setpoint speed profile curve by a zero acceleration. An ARM refers to the rate of change of vehicle motion between an initial acceleration phase and a deceleration phase. A tARM refers to changes in acceleration (or acceleration rates) during the initial acceleration phase and changes in acceleration (or acceleration rates) during the deceleration phase. In certain cases, no tARM is used, but only a pre-ARM for the initial acceleration phase and a post-ARM for the deceleration phase. The pre-ARM refers to different ARM values for the initial and final phases of the acceleration. The implementation indicated also requires a known and accurate vehicle mass, which may degrade performance.The conversion of acceleration-based setpoint powers into axle torques before the arbitration or decision about all torque requests is also complex. Conventional motion demand systems operate based on torque-based demands and have duplicate conversions of acceleration to torque in offline or real-time mode. When the conversions are offline, they lose the ability to compensate for changes in road and environmental conditions (e.g., road grade, road surface friction, wind direction and strength) and vehicle characteristics (e.g., vehicle mass, tire radius, drag coefficient). Regardless of whether the transformations are offline or in real-time, each torque requester must use a dynamic vehicle model and a controller or regulation to convert the desired vehicle motion to an axle torque. Thus, a vehicle may include multiple dynamic vehicle models and / or control and regulation systems that implement respective platforms with respective algorithms and calibrations. The transformations may be performed at the various vehicle models and / or controllers. Potentially, the duplicated effort for designing, encoding, testing, deployment, and maintenance of the dynamic vehicle model and a particular type of control and regulation controllers can result in a significant waste of technical resources and resources of the embedded control modules (e.g., RAM, ROM, and throughput). Calibration effort and errors can arise by performing duplicate, similar calibrations that can provide conflicting results.The examples set forth herein include an architecture for requesting vehicle longitudinal movements to provide movement requests and constraints based on requests from multiple requesters. Although the following examples are described primarily with respect to longitudinal motion requirements, speeds, accelerations, jerks, etc., the examples are also applicable to lateral motion requirements, speeds, accelerations, jerks, etc. Current torque-based architectures are inefficient, complex, non-robust, redundant, and expensive to calibrate. Examples described herein include receiving speed requests and restrictions from multiple requesters. A requester refers to a system requesting movements of the vehicle, such as a cruise control system, an adaptive cruise control system, a hands-free driving system, a one-pedal driving system, or another system requesting movements. A requester may also refer to a device or module for requesting driver torque, such as an acceleration module that generates a speed request signal based on the position of an accelerator pedal. The constraints include acceleration constraints and jerk constraints. The acceleration and jerk constraints may include acceleration and jerk limits that may not be exceeded. The disclosed architecture includes a supervisory control layer that reports accomplished behavior, hardware constraints, and detected failures back to the requesters, an arbitration module, and a profile generation module, as described further below.The examples set forth herein further include a profile generation module configured to construct motion horizons (i.e., velocity reference profiles of the motions to be tracked). In one embodiment, speed / tempo, acceleration and jerk profiles are created. In one embodiment, a tempo / speed horizon (or tempo / speed profile) of the vehicle is created with a particular format and using desired speed and motion constraints (e.g., maximum and minimum acceleration constraints, and maximum and minimum jerk constraints). This particular format provides an efficient method for generating vehicle motion profiles / horizons with minimal memory (RAM) consumption, read only memory (ROM) consumption, and throughput consumption, and provides sufficient motion reference information for a variety of control methods (e.g., proportional-integral-derivative (PID), linear quadratic controller (LQR), and model predictive control (MPC)). The speed and motion constraints (e.g., acceleration constraints and jerk constraints) may be obtained from a vehicle technical specification, from online demand modules, or via local and / or remote inputs. The examples eliminate inefficiency (e.g., duplicate conversions using a dual vehicle model and dual control method) in converting acceleration and jerk metrics to axle torque, thereby reducing algorithm and calibration effort.FIG. 1 shows a host vehicle 100 having an example speed-based control system 101 that includes a vehicle motion request module 102. The speed-based control system 101 includes a vehicle control module 103 that implements the vehicle motion request module 102. The vehicle motion request module 102, further described below, generates motion requests and constraints based on motion requests and constraints received from multiple requesters. The motion requests may include, for example, speed, acceleration, and jerk requests, and the constraints may include speed, acceleration, and jerk constraints. The modules 102, 103 may perform various operations based on interaction with a driver of the host vehicle 100. The vehicle control module 103 may perform autonomous operations based on the interaction including the responses received from the driver.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 may control the operation of the vehicle 100 and the modules 102, 106, 107, 108 and the propulsion system 110. The power sources 105 may include one or more battery packs, a generator, a converter, a control circuit, terminals for high and low voltage loads, etc., as well as one or more battery sensors 111 for sensing the states of the power sources 105 including voltages, currents, states of charge, etc.Telematics module 106 provides wireless communication services within vehicle 100 and wirelessly communicates with service providers, backoffices, central offices, cloud-based networks, stores, and devices external to vehicle 100. Telematics module 106 may support Wi-Fi® Bluetooth® Bluetooth Low Energy (BLE), Near Field Communication (NFC), cellular, legacy (LG) Transmission Control Protocol (TCP), Long Term Evolution (LTE), and / or other wireless communication, and / or operate in accordance with Wi-Fi® Bluetooth® BLE, NFC, cellular, and / or other wireless communication protocols. Telematics module 106 may include one or more transceivers 112 and a navigation module 114 having a global positioning system (GPS) and global navigation satellite system (GNSS) receiver 116. The transceivers 112 wirelessly communicate with network devices inside and outside of the vehicle 100, including cloud-based network devices, central stations, backoffices, and portable network devices. Transceivers 112 may perform pattern recognition, channel addressing, channel access control, and filtering operations.The navigation module 114 executes a navigation application to offer navigation services. The navigation services may include location identification services to determine where the vehicle 100 is located. Navigation services may also include guiding a driver and / or guiding the vehicle 100 to a selected location. The navigation module 114 may communicate with a central station to collect map information indicating the volume of traffic, the identification of transport objects and their locations (e.g., locations and types of signs), path information, locations of turns, lane identification, locations of ramps, etc. For example, if the vehicle 100 is an autonomous vehicle, the navigation module 114 may direct the vehicle control module 103 along a selected route to a selected destination. The GPS and GNSS receiver 116 may provide information for measuring the vehicle state, such as vehicle speed and / or the direction (or heading) of the vehicle 100 and other vehicles and objects (e.g., pedestrians and cyclists) and / or global time measurement information. The GPS and GNSS receiver 116 may generate a GPS signal that is passed to the vehicle control module 103. The GPS signal and corresponding information for measuring the vehicle state may be delayed (i.e., have a corresponding hang-up) upon receipt by the vehicle control module 103.The infotainment module 107 may include and / or be connected to an audio system 122 and / or a video system having one or more displays (a display 120 is depicted). The display 120 and audio system 122 may be part of a human-machine interface. The displays may include cluster and / or center console displays, head-up displays, etc. Messages may be displayed via the display 120, the audio system 122 played audibly, and / or output via one or more other output devices. The infotainment module 107 may provide various proactive messages and information. The infotainment module 107 may guide the vehicle operator to a particular location or around a turn, for example, to change lanes and / or display other information.The propulsion system 110 may include one or more torque sources, such as one or more motors and / or one or more engines (e.g., internal combustion engines). In the example shown in FIG. 1, the vehicle 100 includes an engine 130 and one or more motors 132. The torque sources are controlled independently of each other. The propulsion system 110 includes an engine control system 134 that includes the one or more engines 132 and an engine control module 136 that may control operation of the one or more engines 132 based on signals from the vehicle control module 103.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 interface. The vehicle control module 103 may control operation of vehicle modules, devices, and systems based on feedback from the sensors 150.The sensors 150 may include exterior sensors, interior sensors, vehicle condition sensors, and other sensors. For example, as shown, the sensors 150 may include radar and / or lidar sensors 152, exterior image sensors (e.g., cameras) 154, wheel speed sensors 156, acceleration sensors (e.g., longitudinal and lateral acceleration sensors) 158, speed sensors (e.g., longitudinal and lateral speed sensors) 160, an inertial measurement sensor 162, a yaw rate sensor 164, and other sensors 166. The other sensors 166 may include wheel angle sensors and / or other vehicle condition sensors and / or motion detection sensors.The exterior sensors may be used to detect objects outside of the vehicle 100 and / or in a path of the vehicle 100. The interior sensors may include interior image sensors (e.g., cameras) and a microphone or microphone array that may be used to monitor physical activity, eye movements, and / or gaze direction of a driver and / or to interact with the driver. The interior sensors may also be used to detect gestures of the driver, detect body orientation of the driver, detect speech of the driver, etc.The vehicle motion request module 102 may include an arbitration module 172 and a profile generation module 174. The vehicle control module 103 may further include feature request modules (or requesters) 176, an operating mode selection module 178, and a vehicle motion control module 179. The arbitration module 172 performs arbitration operations to determine which move requests need to be met, as described further below with respect to FIGS. 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 requirements may include a generated (or desired) profile of a vehicle condition (e.g., a desired profile of vehicle speed). The vehicle motion control module 179 controls actuators (e.g., the engine 130, motors 132, the brake system 177, etc.) of the vehicle based on the motion requests and constraints generated by the profile generation module 174. Although modules 102 and 179 are illustrated as being implemented by the same vehicle control module (or controller) 103, modules 102 and 179 may be implemented by separate control modules (or controllers).The mode selection module 178 may select a vehicle operating mode. For example, the vehicle control module 103 may operate in a fully or partially autonomous mode and control the propulsion system 110, a braking system 177, and a steering system 201. The steering system 201 includes a steering wheel angle sensor 203. In one embodiment, the vehicle control module 103 controls operation of the systems 101, 110, 177, and 201 based on interactions with a vehicle occupant (or driver). The vehicle control module 103 may i) perform autonomous operations such as steering, braking, accelerating, etc., and / or ii) display and / or acoustically render messages, and / or output messages and / or corresponding signals via other output devices.The vehicle 100 may also include the memory 180. The memory 180 may store sensor data 182, parameters 184, applications 186, algorithms 188, historical data 190 and other data 192. The parameters may include, for example, sensor parameters and data of the sensors 150. Applications 186 may include applications executed by modules 102, 103, 107, 108.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, e.g., driver driving patterns, data captured and / or generated by the modules 102, 103, traffic data, navigation data, map data, GPS data, path data, sensor data, etc.The vehicle control module 103 may control 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 the parameters specified by the modules 102, 103, 107, 108. The vehicle control module 103 may set at least some of the parameters based on the signals received from the sensors 150.The vehicle control module 103 may receive power from the power sources 105, which may be provided to the propulsion system 110, the braking system 177, the steering system 201, etc. The energy supplied to the motors 132, the brake system 177, the steering system 201, and / or actuators thereof may be controlled by the vehicle control module 103 to make settings such as: engine speed, torque, and / or acceleration; brake pressure; steering wheel angle; pedal position; etc. This control may be based on the outputs of the sensors 150, the navigation system 114, the GPS and GNSS receiver 116, and the above-mentioned data and information stored in the memory 180.The modules 102 and / or 103 may determine various parameters including vehicle speeds and accelerations, yaw rate, moment of inertia, wheel angle, steering wheel angle, gear state, accelerator pedal position, brake pedal position, and / or other information. The modules 102, 103 may further determine lane boundaries, lane positions, road positions, turn positions, speed boundaries, object positions, environmental conditions, etc.FIG. 2 shows a vehicle longitudinal motion request and control (or speed-based control) system 200 that includes the feature request modules (or motion requesters) 176, the vehicle motion request module 102 (or the final motion reference request), and a vehicle motion control system 204. Although the system 200 is described primarily with respect to longitudinal requirements and control, the system 200 is also configured for lateral motion requirements and control. The requesters 176 may be, for example, a cruise control requester, an adaptive cruise control requester, a hands-free driving system requester, a one-pedal driving system requester, or another motion system requester. The requesters 176 may also be a requester for driver acceleration. Each of the requesters 176 provides a speed request and acceleration and jerk constraints to the arbitration module 172. The driver acceleration requester converts a driver acceleration request to a speed request as well as acceleration and jerk constraints that are communicated to the arbitration module 172.Arbitration module 172 arbitrates motion requests (e.g., speed requests) received from feature request modules 176 and generates a resulting (or final) motion request that is provided to profile generation module 174. This arbitration is described in more detail below. The vehicle motion request module (or system) 102 further includes an acceleration map module 206 that generates an ARM and a tARM (or JRM jerk map) that include global limits indicative of acceleration and deceleration behavior that the vehicle should follow and that are provided to the profile generation module 174. The profile generation module 174 generates a profile request (e.g., a speed request over a horizon) that is provided to the vehicle motion control module 179 of the vehicle motion control system 204. The vehicle motion control module 179 controls operation of a plant 210 based on the profile request and selected control methods (e.g., open loop, PID, and MPC controllers). One or more sensors 212 monitor the conditions of the plant 210 and provide feedback to the vehicle motion control module 179. In one embodiment, the one or more sensors 212 provide a feedback value to the vehicle motion control module 179 that adjusts the torque requests based on the speed error (e.g., the difference between profile request and feedback value). In one embodiment, the vehicle motion control module 179 implements a single vehicle model. The sensors 212 may include a vehicle speed sensor, engine and / or engine speed sensors, wheel speed sensors, etc.In one embodiment, each of the feature request modules 176 provides a corresponding speed request and / or acceleration and jerk conditions, all of which may be the same format. The vehicle motion control system 204 operates as a single global set of controls and regulations for the particular features implemented. This simplifies the design, encoding, testing, deployment, maintenance, calibration, and development costs, and improves the hardware RAM, ROM, and throughput of the vehicle longitudinal motion request and control system 200. The described system provides consistent performance for all requests with a global vehicle model and set of controls and regulations for better drive quality, particularly when changing between different types of requests.FIG. 3 shows a vehicle motion request and control system 300 including a feature layer, a command interpretation layer, and a monitoring control layer. The feature layer includes the feature request modules 176, the acceleration map module 206, and a module 302 that determines the requirements of the feature. The feature request modules 176 receive feature requirements 304 from the feature requirement module 302. The requirements for the features may include, for example, a desired speed (or reference speed), a one-pedal drive deceleration rate or acceleration rate depending on accelerator pedal and speed, a brake pedal-based deceleration rate, an autonomous control request, etc. The feature requirements may be established and / or determined based on the driver inputs 306, which may also include the source of acceleration and jerk constraints for each feature request model 176, as well as motion request main priority level and sub-priority levels of 176. The feature request modules 176 may further receive: a response from the vehicle motion request module 102, a response 308 including types of acknowledged, partially acknowledged (actuator range limited in type and value), rejected (lost arbitration, propulsion actuator failures), from the vehicle motion control system 204 (e.g., hardware constraints), and other constraints such as an acceleration constraint 310 and a jerk constraint 344 generated by the profile generation module 174. The feature request modules 176 generate motion requests (e.g., speed requests) 314 and constraints, such as acceleration constraints 316 and jerk constraints 318, based on the feature requests 304, the response 343 to all requesters based on the decision made by the arbitration module 172, the response 308, the acceleration constraint 310, and the jerk constraint 344 from the vehicle motion control module 179. For example, the response 308 may include the maximum and minimum available torque for the available torque sources, the maximum and minimum acceleration and / or deceleration values, the maximum and minimum jerk values, the maximum and minimum speeds, etc. The response 308 may indicate when one or more devices (e.g., an engine) are not or are not functioning properly, thus limiting available acceleration, deceleration, etc. Similar to 308 being the response to the requests from 340, 342, 312, and 310 and 344, 343 is the response to all requesters, 176. Depending on the response 343 (e.g., acknowledged, partially acknowledged, or rejected), the requesters 176 may adjust their movements and restrictions accordingly.The command interpretation layer includes arbitration module 172 and profile generation module 174. The arbitration module 172 i) determines which motion requests 314 are accepted or accounted for based on the feature requirements 304, the reported failures, the calibration values, and the status values, ii) selects a winning machine from among the contemplated motion requests, and iii) generates an arbitrated motion request (or speed request) 322 and corresponding constraints such as an acceleration constraint 324 and a jerk constraint 326 provided to the profile generation module 174. In one embodiment, the motion request 322, the acceleration constraint 324, and / or the jerk constraint 326 are generated based on the winninger of the arbitration module 314 and its corresponding motion requests (e.g., speed requests) 314 and constraints such as acceleration constraints 316 and jerk constraints 318, or an ARM and a tARM from the acceleration map module 206 rather than as specified by the feature requirement model (feature requirements model) 302. The errors can be failures of hardware components, e.g., the failure of an engine or a sensor. The status values may relate to the vehicle speed achieved, vehicle acceleration (or deceleration) achieved, and / or vehicle jerk achieved.An error mode module 320 detects hardware and software errors (e.g., sensors, actuators, controllers for controllers and controllers, embedded control modules, and software implementation) and may report the errors to the arbitration module 172 along with calibration values and status values. When one or more errors occur, arbitration module 172 may determine that one or more features cannot be implemented and thus one or more of motion requirements 314 cannot be satisfied and do not detect the motion requirements of one or more corresponding feature requirement modules 176.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 based on the motion request 322, the acceleration constraint 324, the jerk constraint 326, the outputs of the fault mode module 320, and the response 308. In one embodiment, the motion request profile 340, the acceleration request profile 342, the jerk request profile 312, the acceleration constraint 310, and / or the jerk constraint 344 are generated based on the motion request (or arbitration speed request) 322 and the corresponding constraints, such as the winninger acceleration constraint 324 and jerk constraint 326, identified by the arbitration module 172, as well as an ARM and a tARM from the acceleration map module 206 according to the specifications of the feature requirement module 302.For example, if a driver ceases to apply a brake pedal and begins to apply an accelerator pedal of the vehicle to request a target speed greater than the actual vehicle speed, the profile generation module limits how speed, acceleration, and jerk profiles (or requests) are generated. The profile generation module 174 smoothly transitions from braking the vehicle to accelerating the vehicle so that the vehicle does not experience a "clunk" or "hit"(s) as defined by the acceleration constraints 324 and the jerk constraint 326. This is an example of how a generated profile can be constrained. The constraint may be created by creating speed, acceleration, and / or jerk profiles and acceleration and jerk constraints.The monitoring control layer includes the vehicle motion control system 204 including the vehicle motion control module 179 and the sensors 212. The vehicle motion control module 179 generates a series of torque requests to all available propulsion actuators and a achieved behavior feedback signal 330 that indicates the status values of the entire control, actuation, and sensing path. The vehicle motion control module 179 may not acknowledge one or more of the received requests and / or one or more of the received restrictions. For example, if the vehicle motion control module 179 is operating in a particular mode for which the request and / or constraint is not suitable, the vehicle motion control module 179 may not satisfy the request and / or constraint. For example, if the vehicle motion control module 179 is operating in a traction control mode, an acceleration request may not need to be met. If a request and / or constraint is not met, the vehicle motion request module 102, and thus the modules 172, 174, may reset the request and / or constraints. In one embodiment, the vehicle motion control module 179 informs the modules 172, 174 when requirements and constraints are met and / or not met. This indication may be made by indicating the speed, acceleration, and jerk achieved, or directly by notifying whether the requirements and / or constraints have been met. These indications may be returned to one or more of the modules 172, 174 and / or the modules 176 as part of the hardware constraint signal.FIG. 4 shows a method for generating motion requests and constraints for a vehicle motion control system (e.g., the speed-based control system 200 of FIG. 2 ). The following operations may be performed iteratively. At 400, the feature requirement module 302 may receive inputs and / or commands that may be generated based on driver inputs. At 402, the feature requirement module 302 generates feature requirements based on the received inputs.At 404, one or more of the feature request modules 176 generate feature requests and constraints (e.g., acceleration and jerk constraints) based on the feature requirements, hardware constraints, and profile constraints (i.e., constraints generated by the profile generation module 174). The feature requirements also include motion requirements (e.g., speed requirements).At 406, the arbitration module 172 receives the requests and restrictions generated by the feature request module 176.At 408, the arbitration module 172 decides the received feature requests to determine which of the feature requests should be at least partially satisfied. This is based on the output of the feature requirement module 302, the hardware constraints, detected errors, calibration values, vehicle conditions reached, and / or the ARM and / or tARM.At 410, the arbitration module 172 generates a resulting move (or arbitration) request 322 and resulting constraints (e.g., the acceleration constraint 324 and the jerk constraint 326) provided to the profile generation module 174.At 412, the profile generation module 174 generates i) profile requests for various 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., the acceleration constraint 310 and the jerk constraint 344).At 414, the vehicle motion control module 179 controls one or more actuators (e.g., engines, machine, or other propulsion devices) based on one or more profile requests, including the speed request profile, the acceleration request profile, and / or the jerk request profile, and / or the one or more profile constraints generated by the profile generation module 174. This may be done based on the mode of operation and the fulfillment of one or more requirements of the requester. For example, in a cruise control mode, the vehicle motion control module 179 monitors a 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 monitors and / or may not use the acceleration request profile and the jerk request profile. The profile constraints may be the same as or different from the resulting constraints generated by the arbitration module 172. The profile generation module 174 may modify the constraints generated by the arbitration module 172 and output the modified constraints as profile constraints to the vehicle motion control module 179.At 416, the vehicle motion control module 179 generates a hardware constraint signal with hardware constraints. At 418, the vehicle motion control module 179 monitors vehicle behavior and generates a attained behavior feedback signal indicative of the attained vehicle conditions.At 420, the fault mode module 320 detects one or more faults, generates calibration values, and / or generates values for the state of the vehicle plant. The vehicle plant state values may include the vehicle speed achieved, acceleration, and / or jerk, as well as the engine and / or engine speeds achieved. The calibration values may include engine and / or engine calibration values, such as calibrated voltages, amperages, fueling rates, airflow rates, timing information, etc. At 422, the detected fault information, calibration values, and status values of the vehicle plant are communicated to the arbitration module 172. Operation 408 may be performed subsequent to operation 422.In one embodiment, the feature request modules 176 described above request vehicle behavior in the form of expected speed requests and acceleration and jerk constraints including corresponding vehicle speed horizons. Arbitration of multiple speed requesters is based on the feature requirement module 302 through the vehicle technical specification, calibration, fault modes, and hardware constraints. For understanding the system, feedback of the monitoring layer regarding the constraints is provided. The feedback information includes information about hardware constraints and the diagnostic status (including a horizon). The arbitration module operates based on this information and generates arbitration outputs (or arbitration information). The feedback of the trajectory speed on the monitoring layer can contain a horizon for the future system behavior. The arbitration module reports the "winner" of the arbitration performed to the profile generation module by indicating a move request and corresponding restrictions. A brake pedal position may be provided as input to the feature requirement module 302 and mapped to a vehicle speed request via one of the feature requirement modules. The operation of the described vehicle motion request and control system 300 ensures smooth transitions between speed requests.FIG. 5 shows an example diagram for creating a speed profile with a certain format based on changes in the pedal position and the target speed. A pedal position curve 1100 and a setpoint speed curve 1102 are shown. The pedal position curve 1100 is an example of a change in the accelerator pedal position. The accelerator pedal position changes from a released state 1104 to a depressed stateState 1106. The desired speed transitions from a LOW speed state 1110 (or zero) to a HIGH state 1112 (or a speed greater than zero). The LOW speed state corresponds to the released state 1104 and the HIGH speed state 1112 corresponds to the depressed state 1106.A speed profile 1120 is created based on the change in pedal position and the corresponding change in setpoint speed. The velocity profile 1120 of velocity versus time includes an initial acceleration portion 1122 (or first non-linear portion), a deceleration portion 1124 (or second non-linear portion), and a velocity maintenance portion 1126. A transition portion 1128 may be present between portions 1122 and 1124. The speed profile 1120 is an example of a speed request that may be generated by the profile generation module 174 of FIGS. 1-3. An acceleration request (or profile) may be determined by deriving the velocity profile. A jerk request (or profile) may be determined by deriving the acceleration request (or profile).The accelerating section 1122 extends from a first point at time t 0 and the speed v 0 to a second point at time t 1 and the speed v 1. The transition portion 1128 extends from the second point to a third point at time t 2 and speed v 2. The delay section extends from the third point to a fourth point with time t 3 and speed v 3. The method of FIG. 12 shows an example of how the times t 1, t 2, t 3 and the speed v 1 can be determined. The initial state occurs at t 0 and includes v 0, a 0 and j 0, all conditions being known and v 0 may be the actual reference speed or the measured speed depending on whether a regulation or a control is selected. The transient condition begins at t 1 and includes v 1, a 1 and j 0, where only a 1 is a known condition, namely the maximum / minimum acceleration. The final desired state occurs from t 3 and comprises v 3, a 3 and j 3, all conditions being known.Traditionally, a target reference value (or parameter) is often expected as a series of reference values over a target time window (or reference horizon) to achieve more accurate and robust control. The examples disclosed herein provide a method for generating a speed horizon of a vehicle or any controlled moving object in consideration of acceleration (e.g., an ARM) and jerk conditions (e.g., + a tARM). The disclosed examples use seven known conditions, v 0, a 0, j 0, a 1, v 3, a 3 and j 3, where v 0 is the actual reference speed, a 0 is the actual reference acceleration, j 0 is the maximum / minimum jerk constraint, a1is the maximum / minimum acceleration constraint, v3is the desired speed, a3is the desired acceleration, and j3is the minimum / maximum jerk constraint. This includes an actual reference state including three of the known conditions, namely, an actual reference vehicle speed v 0, an actual reference acceleration a 0 and an actual maximum / minimum jerk constraint j 0, a transition state including an independent known condition, namely, the maximum / minimum acceleration constraint a 1, and a target reference state including the other three of the known conditions, namely, a target vehicle speed v 3, a target acceleration a 3 and a target minimum / maximum jerk constraint j 3. Two quadratic functions f 0 and f t are determined with the known conditions (or actual, transition and desired parameter states), f 0( v 0, a 0, and j 0), a 1, and f t( v 3, a 3, and j3). The acceleration constraint, a 1, and jerk constraints, j 0 and j 3, are used to determine the time required to reach the desired speed v 3.In one embodiment, portions 1122 and 1124 are determined based on jerk constraints (tARM) and portions 1126 and 1128 are determined based on acceleration constraint (ARM). The acceleration and jerk constraints (e.g., ARM and tARM) may be provided via and / or based on a vehicle technical specification stored in memory, inputs from upstream feature requesting modules (Feature Requesting Modules) 176, inputs from a remote device communicating with the vehicle, and / or hardware constraints and / or failures obtained from downstream components.DUAL QUADRATIC FUNCTIONS FOR VEHICLE SPEED PROFILEThe following examples apply to both control and control of vehicle conditions, including speed, acceleration and jerk conditions.The speed profile 1120 is a dual quadratic function vehicle speed profile that includes the three sections 1122, 1128, and 1124 connected at time t 1 and t 2 respectively. The first non-linear portion 1122 may be defined as a first quadratic function that applies to the velocity profile between t 0 and t 1. Transition portion 1128 may be defined as a linear function valid between t 1 and t 2 for the velocity profile. The second non-linear portion 1124 may be defined as a second quadratic function that applies between t 2 and t 3 to the velocity profile.The three sections 1122, 1128, and 1124 have the following characteristics: 1) transition from the actual reference acceleration to a requested maximum / minimum acceleration (limited by the actual jerk limitation), 2) maintenance of a maximum / minimum acceleration (limited by the requested acceleration limitation), 3) transition from the requested acceleration to a desired acceleration (limited by a desired jerk limitation).The first quadratic function of the first non-linear portion 1122, which applies between t 0 and t 1 for the velocity profile, can be represented by equation 1, and the corresponding acceleration and jerk can be represented by equations 2 and 3, respectively, where y is the velocity, a is the actual jerk, b is the actual reference acceleration and c is the actual reference velocity.For t = t 0= 0 the following conditions are known: i) a = y" t0, ii) b = y' t0 and iii) c = y t0.A linear function of the transition section 1128 that applies between t 1 and t 2 to the velocity profile can be represented by Equation 4. Equation 5 represents the corresponding acceleration, where m is the slope of the linear function.At t = t 0= 0 it is known that m = y' dsrd, where y' dsrd is the requested acceleration constraint.The second quadratic function of the second non-linear portion 1124 that applies between t 2 and t 3 for the velocity profile may be represented by equation 6. Equations 7 and 8 represent the corresponding acceleration and jerk from Equation 6.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 desired jerk, f is the desired acceleration, and g is the desired velocity.A tangent point of the sections 1122 and 1124 at time t t may be determined using equations 29-32, where equation 9 indicates when the two sections have the same velocity at tt, equation 10 indicates when the two sections 1122, 124 have the same acceleration at tt, and equation 11 indicates when there is a relationship between the coordinate systems of the two quadratic curves of the two sections 1122, 1124. The tangent point of the sections 1122 and 1124 at time t t may be represented as Equation 12.Theorem I: A negative discriminant can be determined when the following condition 1 is satisfied:Theorem II: A positive discriminant can be determined when the following condition 2 is satisfied:Theorem III: A negative discriminant can be converted to a positive discriminant by setting a = -a and e = -e.Theorem IV: For the following possible solutions t t1 and t t2 under all conditions t t1< t t2( see below Evidence IV). Thus, t t2 is the only solution that can be considered. Equations 13-15 may represent t t1, t t2, and t t respectively.The profile generation module 174 may determine whether the transition (or linear) portion 1128 is present by performing the following operations. The acceleration at the tangent point can be determined using Equation 16.The requested acceleration is based on an Acceleration Map (ARM) of the Technical Vehicle Specification (VTS) or on the acceleration constraint of the recognized feature request module designated y' dsrd. The linear portion 1128 is needed when the following condition 3 is satisfied.Otherwise, linear portion 1128 is not needed so that second 1122 is connected to portion 1124 and one portion is less present.When the linear portion 1128 is included, the first transition point t 1 between the first quadratic function and the linear function may be determined using equations 17-18 when the linear function 1128 has the format of equation 19.At the point t 1 the equations 40 and 41 are satisfied.The second transition point t 2 between the second quadratic function and the linear function can be determined with the aid of equations 22 and 23.Therefore, Equations 24- 29 are satisfied because Equation 30 is satisfied. Equation 31 is also satisfied.If linear portion 1128 is not included, both transition points, t 1 and t 2, may be determined according to equation 32 while t 3 remains the same as if linear portion 1128 is present. This occurs when transition portion 1128 is not included and v 1= v 2.The evidence I, II, III only takes into account the condition ae<0. If the discriminant (a - e)(af 2- eb 2+ 2 ae(c - g)) ≥ 0, t t2 is the actual solution because the sign swapping for a and e results in the discriminant having a negative value. When the discriminant, (a - e)(af 2- eb 2+ 2 ae(c - g))<0, there are two possibilities, which will be referred to as case I and case II below.Case I:If the signs of a and e are reversed, then (a-e) > 0 or a > 0 and e < 0 andCase II:If the signs of a and e are reversed, then (a - e)<0 or a<0 and e>0 andBy inverting the sign at a and e, the discriminant becomes a positive value.For evidence IV, a * e<0 applies under all conditions, i.e.Therefore, the following is true under all conditions:FIG. 6 shows a method for generating speed, acceleration and jerk profiles. The following operations may be performed iteratively. The method may be performed by the profile generation module 174 of FIGS. 1-3.At 1200, the profile generation module 174 determines the tangent point and its corresponding acceleration of two quadratic functions. This can be done using equations 33-35.At 1202, the profile generation module 174 determines whether an acceleration constraint needs to be applied. If yes, operation 1204 is performed, otherwise operation 1206 is performed. Acceleration constraint is applied when v' tt > v' max_dsrd or v' tt< v' min_dsrd.At 1204, the profile generation module 174 determines t 1 and t 2 with the active acceleration constraint using equations 36- 38.At 1206, the profile generation module 174 determines t 1 and t 2 without the applied active acceleration constraint using equation 39, where t 1= t t and t 2= tt.At 1208, the profile generation module 174 determines t 3 using equation 40.At 1210, the profile generation module 174 initializes a first element of a requested horizon of speed, acceleration, and jerk, where v" dsrd_hrzn[0]=v" dsrd, v' dsrd_hrzn[0] = y' dsrd and v dsrd_hrzn[0] = v dsrd.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 a temporal horizon size. If i is not less than n, the method may end, otherwise operation 1216 is performed.At 1216, the profile generation module 174 sets the horizon t equal to i times a list rate (ruster rate). At 1218, the profile generation module 174 determines whether t is less than t 1. If yes, operation 1220 is performed, otherwise operation 1222 is performed.At 1220, the profile generation module 174 updates the speed, acceleration, and jerk request outputs according to a 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.At 1222, the profile generation module 174 determines whether t is less than t 2. If yes, operation 1224 is performed, otherwise operation 1226 is performed.At 1224, the profile generation module 174 updates the speed, acceleration, and jerk request outputs according to a 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 - t 1)+ v 1.At 1226, the profile generation module 174 determines whether t is less than t 3. If yes, operation 1228 is performed, otherwise operation 1230 is performed.At 1228, the profile generation module 174 updates the speed, acceleration, and jerk request outputs according to a third set of settings as follows, where t tz= t - t 3, 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.At 1230, the profile generation module 174 updates the speed, 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.At 1232, the profile generation module 174 i increments by 1 and then returns to operation 1214.The examples described above include a method for calculating a continuous / smooth desired reference speed trajectory (a continuous acceleration) as one moves away from an initial speed, v 0, that satisfies acceleration and jerk constraints (starting trajectory). The method is used in each loop of a selected service plan (ruster). The method determines how many sections (e.g., initial constant jerk section 1, constant acceleration section 2, final constant jerk section 3, and constant velocity section 4) are required for the design of the profiles / horizons. For a selected horizon size (e.g., 20), a motion profile / horizon may include various combinations of sections (e.g., only section 1, section 1 and 2, section 1 and 2 and 3, section 1 and 2 and 3 and 4, only section 2, section 2 and 3, section 2 and 3 and 4, only section 3, section 3 and 4, only section 4), depending on the known conditions for a particular loop. The method performs these operations based on the received acceleration and jerk constraints from one or more algorithms implemented prior to the calculation of the velocity profile, and uses this information in formulating the trajectory. A horizon of points is set to achieve target speeds with corresponding acceleration and jerk constraints. The action applies the maximum / minimum jerk constraint in section 1, the maximum / minimum acceleration constraint in section 2, the minimum / maximum jerk constraint in section 3, and reaches the desired speed in section 4.The above-described operations of FIGS. 4 and 6 are to be understood as illustrative examples. The operations may be performed sequentially, synchronously, simultaneously, continuously, in overlapping periods, or in another order, depending on the application. In addition, depending on the execution and / or sequence of events, individual operations may not be executed or skipped.The examples described above include a speed-based architecture that does not require calibration of torque conversion requirement characteristics. The architecture is simplified in terms of the number of controlled devices with controllers, plant and feedback / sensor devices for each requester. The architecture includes a single vehicle control system having a vehicle motion control module, a plant, and sensors used to satisfy the requirements of multiple requesters.The foregoing description is merely illustrative in nature and is not intended to limit the disclosure, its application, or use. The broad teachings of the disclosure may be practiced in a variety of forms. Therefore, although this disclosure includes particular examples, the true scope of the disclosure should not be so limited as other modifications will be apparent upon a study of the drawings, the specification, and the following claims. It should be appreciated that one or more steps within a method may be performed in different order (or simultaneously) without altering the principles of the present disclosure. Although each of the embodiments is described above with certain features, any one or more of those features described with respect to any embodiment of the disclosure may be implemented in any of the other embodiments and / or combined with features of any other embodiment, although that combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and permutations of one or more embodiments with each other remain within the scope of this disclosure.Spatial and functional relationships between elements (e.g., between modules, circuit elements, semiconductor layers, etc.) are described with various terms, e.g., "connected," "engaged," "coupled," "adjacent," "next," "on," "over," "under," and "arranged.". When a relationship between first and second elements is not expressly described as "direct" in the above disclosure, this relationship may be a direct relationship in which no other intervening elements are present between the first and second elements, but may also be an indirect relationship in which one or more intervening elements (either spatially or functionally) are present between the first and second elements. As used herein, the phrase "at least one of A, B, and C" should be construed as logical (A OR B OR C) using a non-exclusive logical OR, and should not be understood as "at least one of A, at least one of B, and at least one of C.".In the figures, the direction of an arrow, as indicated by the arrow head, generally indicates the flow of information (e.g., data or instructions) of interest for the display. For example, if element A and element B exchange a variety of information, but the information transmitted from element A to element B is relevant for presentation, the arrow may point from element A to element B. This unidirectional arrow does not imply that no further information is transmitted from element B to element A. In addition, element B for information sent from element A to element B may send requests for or acknowledgments for the information to element A.In this application, including the definitions below, 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 a module: an application specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field programmable gate array (FPGA); a processor circuit (shared, dedicated, or group) that executes code; a memory circuit (shared, dedicated, or group) that stores the code executed by the processor circuit; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, e.g., in a system-on-chip.The module may include one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces connected to a local area network (LAN), the Internet, a wide area network (WAN), or combinations thereof. The functionality of any module of the present disclosure may be distributed among multiple modules connected via interface circuits. For example, multiple modules may allow load balancing. In another example, a server module (also referred to as a remote or cloud module) may perform some functions on behalf of a client module.The term code as used above 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 ("shared processor circuit") includes a single processor circuit that executes some or all of the code from multiple modules. The term "group processor circuit" includes a processor circuit that, in combination with other processor circuits, executes some or all of the code from one or more modules. References to multiple processor circuits (multiple processor circuits) include multiple processor circuits on discrete chips, multiple processor circuits on a single chip, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the foregoing. The term shared memory circuit ("shared memory circuit") includes a single memory circuit that stores part or all of the code from multiple modules. The term "group memory circuit" includes a memory circuit that, in combination with other memories, stores some or all of the code from one or more modules.The term "memory circuit" is a subset of the term "computer readable medium.". The term "computer-readable medium" as used herein does not include transitory electrical or electromagnetic signals propagating through a medium (e.g., on a carrier wave); the term "computer-readable medium" may therefore be considered tangible / tangible and non-transitory. Non-limiting examples of a non-transitory, tangible computer readable medium include non-transitory memory circuits (e.g., a flash memory circuit, an erasable programmable read only memory circuit, or a mask read only memory circuit), volatile memory circuits (e.g., a static random access memory circuit or a dynamic random access memory circuit), magnetic storage media (e.g., an analog or digital magnetic tape or a hard disk drive), and optical storage media (e.g., a CD, a DVD, or a Blu-ray Disc).The apparatus and methods described in this application may be implemented in part or in whole by a special purpose computer formed by configuring a general purpose computer to perform one or more particular functions embodied in computer programs. The above-described function blocks, flowchart components, and other elements serve as software specifications that can be translated into the computer programs by the routine work of an skilled technician or programmer.The computer programs include processor-executable instructions stored on at least one non-transitory, tangible computer-readable medium. The computer programs may also contain or access stored data. The computer programs may include a basic input / output system (BIOS) that interacts with the hardware of the special purpose computer, device drivers that interact with certain devices of the special purpose computer, one or more operating systems, user applications, background services, background applications, etc.The computer programs may include: (i) descriptive text to be parsed, e.g., hypertext markup language (HTML), extensible markup language (XML), or javascript object notation (JSON), (ii) assembler code, (iii) object code generated from the 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. The source code may be used with only, for example, the syntax of languages such as C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, The source code may be modified to include the syntax of languages such as C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, and the like, Lisp, Java® Fortran, Perl, Pascal, Curl, OCaml, Javascript® HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Precursor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash® Visual Basic® Lua, MATLAB, SIMULINK, and Python® may be written.FIG. 6 : Description of the FiguresY = YesN = No

Claims

A motion system for a vehicle, the motion system comprising: a profile generation module configured to receive an actual speed, an actual acceleration, a target speed, and a target acceleration for the vehicle, and generate a velocity profile based on the actual speed, the actual acceleration, the target speed, and the target acceleration, comprising determining a first non-linear portion and a second non-linear portion of the velocity profile, wherein the first non-linear portion is associated with the acceleration, wherein the second non-linear portion is associated with the deceleration, and wherein the velocity profile comprises the acceleration of the vehicle from the actual speed to the target speed; and a vehicle motion control module configured to control one or more actuators of the vehicle based on the velocity profile.The motion system of claim 1, wherein the first non-linear portion is a first quadratic function and the second non-linear portion is a second quadratic function different from the first quadratic function.The motion system of claim 1, further comprising: a first sensor generating an output signal indicative of the actual speed and / or the actual acceleration; and a second sensor generating an output signal indicative of the desired speed and / or the desired acceleration, wherein the profile generation module is configured to receive the actual speed and / or the actual acceleration from the first sensor and to receive the desired speed and / or the desired acceleration from the second sensor.The motion system of claim 1, wherein the profile generation module is configured to determine, upon generation of the velocity profile, whether to generate a transition portion for the transition from the first non-linear portion to the second non-linear portion.The motion system of claim 4, wherein: the transition portion is linear; the transition portion is included when an acceleration constraint is applied; and the transition portion is not included when the acceleration constraint is not applied.The motion system of claim 4, wherein: the transition portion is linear; the transition portion is included when the first non-linear portion and the second non-linear portion have a common tangential line; and the transition portion is not included when the first non-linear portion and the second non-linear portion do not have a common tangential line.The motion system of claim 1, wherein the profile generation module is configured to determine the first non-linear portion, the second non-linear portion, and a transition portion between the first non-linear portion and the second non-linear portion by: determining a first time point of a first point connecting the first non-linear portion to the transition portion; determining a second time point of a second point connecting the transition portion to the second non-linear portion; determining a third time point of a third point at the end of the second non-linear portion; and determining the first non-linear portion, the transition portion, and the second non-linear portion based on a time horizon to achieve the desired speed and the first time point, the second time point, and the third time point.The motion system of claim 1, wherein: the profile generation module is configured to generate the velocity profile to have a continuous smooth trajectory from the actual velocity to the target velocity; and the actual velocity is 0.The motion system of claim 1, wherein the profile generation module is configured to obtain an acceleration constraint and a jerk constraint and generate a transition portion between the first non-linear portion and the second non-linear portion that satisfies the acceleration and jerk constraints.The motion system of claim 1, wherein the profile generation module is configured to determine an endpoint of a starting trajectory of the velocity profile and remain at the target velocity when at the endpoint.

Images