Physics-based acceleration control node
The acceleration control node in autonomous vehicles converts torque values into pedal positions, emulating human input, addressing the challenge of controlling semi-trucks with automated transmissions, enhancing compatibility and efficiency.
Patent Information
- Application Number
- JP2025536647
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-12-27
- Filing Date
- 2023-12-27
- Publication Date
- 2026-01-16
AI Technical Summary
Autonomous vehicles lack an efficient mechanism to mimic human control inputs, such as accelerator and brake pedals, without requiring complex tuning processes for different vehicle configurations and gear shifts, especially in semi-trucks with automated transmissions.
An acceleration control node that converts engine torque values into physical displacement values, mimicking pedal positions, and generates control signals to emulate human input, using a physics-based model that considers vehicle state information.
Enables seamless control of vehicle speed and gear shifts without complex tuning, allowing autonomous vehicles to respond like a human driver, compatible with various OEMs and reducing the need for manual intervention.
Smart Images

Figure 2026501544000001_ABST
Abstract
Description
[Technical Field]
[0001] The present disclosure relates to physics-based acceleration control nodes. [Background technology]
[0002] When a user presses the vehicle's accelerator pedal, a sensor captures the pedal position and transmits the captured pedal position to an engine control unit that adjusts the vehicle's engine power output based on the pedal position. For example, the engine control unit may determine an amount of torque and apply the amount of torque to the engine. Further, a transmission control unit receives the pedal position and automatically adjusts the vehicle's gear setting based on the pedal position.
[0003] In contrast, an autonomous vehicle does not physically press an accelerator pedal (or brake pedal) to move (or stop) the vehicle. Instead, the autonomous vehicle's computer sends commands to an engine control unit, which controls the engine's power output. For example, the commands may identify a desired torque for the vehicle, and the engine control unit may increase the engine's power output until the desired torque is achieved.
[0004] While manually driving a vehicle, a driver may adjust control inputs, such as the throttle pedal or braking amount, based on knowledge or observation of the physical characteristics of the truck and the world around them. For example, if the vehicle is a fully loaded semi-truck, the driver may press the accelerator pedal harder for less acceleration than a vehicle with a lighter load. A similar concept can be applied to the control of an autonomous vehicle to improve the performance of the control. However, traditionally, this would require a complex tuning process for different vehicle configurations. The tuning process can be further complicated by automated transmissions in semi-trucks that may shift gears at different shift points during autonomous driving than during manual driving, if the control inputs to the vehicle are not the same during manual and autonomous driving. Summary of the Invention
[0005] Exemplary embodiments are directed to an acceleration control node that can be included within an autonomous vehicle and create control signals to control inputs to the vehicle's engine or braking system without the need for pedals. The acceleration control node is a software component that can be installed within a vehicle and can control the vehicle's desired speed (or braking) relative to a traditional accelerator pedal (or brake pedal). For example, the acceleration control node can convert engine torque values (numbers) received from the vehicle's computer into physical displacement values (such as pedal position) that can be used to operate the vehicle's engine. Furthermore, the content within the control signal can match what would normally be transmitted from an acceleration sensor associated with the pedal. Thus, the vehicle's control unit interprets the control signal as if a human were actually pressing the pedal. In doing so, exemplary embodiments use software to overcome shortcomings in the related art that require tuning. A tuning process is not required here because the control unit receives values from the acceleration control node that it is familiar with and can interpret correctly without requiring significant tuning.
[0006] As noted above, the acceleration control node may be a software program installed within an autonomous vehicle (AV) system that is part of the vehicle's computer and used for planning and route guidance. The acceleration control node may provide input signals to an interface system such as that described in U.S. Patent Application No. 17 / 457,946, filed with the U.S. Patent and Trademark Office on December 7, 2021, the entire disclosure of which is incorporated herein by reference for all purposes.
[0007] An interface system (also referred to herein as a universal interface) can be used to mimic or otherwise emulate signals from various physical input mechanisms of a vehicle that may be used to control other components of the vehicle. (Physical input mechanisms may include an accelerator pedal, brake pedal, turn signal stalk, buttons on a dashboard, a steering wheel, a console, etc.) The interface system can create and output signals that mimic or otherwise emulate signals from the physical input mechanisms. These control signals can be used to control the corresponding physical components of the vehicle that the physical input mechanisms typically control. Thus, the systems disclosed herein improve upon the state of the art by providing improved control signals to the vehicle, thereby improving vehicle response.
[0008] In order for the interface system to control the engine's actuators and / or the vehicle's braking system, the interface system requires inputs that provide engine torque or brake pressure. In an exemplary embodiment, the acceleration control node may create or otherwise determine an engine torque or brake pressure value to be used by the interface system and provide this value to the interface system when the interface system is in the process of generating a control signal configured to mimic a physical input mechanism such as an accelerator pedal or brake pedal. To do this, the acceleration control node may rely on a physics-based model that receives state information and an acceleration value as input and generates an engine torque value (i.e., acceleration) or brake pressure value (i.e., deceleration).
[0009] In an exemplary embodiment, the acceleration control node may use a physics-based model, which may be predefined in advance or dynamically generated, that converts acceleration values, such as those provided by the autonomous vehicle's planning system, into engine torque or brake pressure values, depending on whether the acceleration control node determines there is a need to slow down or speed up the vehicle. Decisions by the acceleration control node may also be based on vehicle state information, such as the current speed, the vehicle's location on the road, other vehicles sensed around the vehicle, objects in the road, etc. This state information may be used by the physics-based model when determining the appropriate engine torque or brake pressure values.
[0010] For example, an acceleration control node may receive a trigger or other request to accelerate from a vehicle computer, such as a planning system, and in response generate an engine torque value. The request may be made by the vehicle computer and include an acceleration value that is the desired acceleration for the vehicle. A physics-based model may then generate the engine torque value based on the vehicle state and the acceleration value from the vehicle computer. The engine torque value may be submitted to an interface system that converts the engine torque value into a pedal position (displacement value) that would typically be sensed by a vehicle sensor associated with an accelerator pedal. The interface system may generate a signal that mimics a reading from an accelerator pedal sensor, etc. In some embodiments, the interface system may include multiple interfaces (e.g., mounting harnesses) for easily connecting to wiring harnesses of various vehicle components, such as the accelerator pedal, brake pedal, turn signal stalk, engine control unit, controller area network (CAN) bus, etc.
[0011] The acceleration control node may be embodied in an AV system that also includes an interface for attachment to an interface system wiring harness, allowing the acceleration control node to send commands from a vehicle computer to control the vehicle's physical input mechanisms. For example, the vehicle computer may send a request to the acceleration control node to trigger activation of the vehicle's engine air intake based on a desired engine torque value. In response, the interface system may convert the desired engine torque value to a pedal position value and send the pedal position value to the engine control unit and / or transmission control unit. In this example, the system may consult a table having desired torque values and / or current engine speeds and receive the corresponding pedal position value. If the table does not contain an exact match of torque / pedal position values, the system may perform an interpolation process to interpolate the pedal position value for the requested torque value based on similar torque values and their mapped pedal positions. Other mechanisms for relating physical positions or inputs to control signals are known in the art and are encompassed by the inventions disclosed herein.
[0012] In an exemplary embodiment, the engine control unit receives a pedal position signal from the system, where the engine control unit is unaware of whether the signal comes from an actual accelerator pedal position sensor or from the system described herein. In response, the engine control unit operates the engine based on the pedal position value. Similarly, the transmission control unit can almost instantly find the appropriate gear based on the pedal position value. Additionally, if desired, a "kill" switch can be provided that interrupts computerized control operation, returning full control of the accelerator pedal (or other physical input mechanism) to its original configuration. In response to the kill signal, the system can disable the connection between the system and the engine control unit and restore the connection between the accelerator pedal sensor and the engine control unit.
[0013] Additionally, the interface system may be used to generate electrical input signals that mimic or otherwise emulate signals of other physical input components of the vehicle, such as a brake pedal or brake actuation system. Here, the interface system may include multiple interfaces for simultaneously connecting to multiple physical input components, including both an accelerator pedal and a brake pedal or brake actuation system, as well as others such as turn signals, headlights, a radio, and A / C. Additionally, the acceleration control node may generate interface signal inputs to create the emulated signals. For example, the acceleration control node may use a physics-based model to determine the brake pressure to apply to the brake actuation system based on a desired acceleration value and vehicle state information. In this case, the acceleration control node may forward a brake pressure command value to the interface system, which then sends it to the brake control system, which actuates the brakes and applies pressure to the vehicle's brake circuit, slowing the vehicle.
[0014] Additionally, different manufacturers (also referred to herein as OEMs) have different control signals, messages, formats, etc. between physical input mechanisms and vehicle components. The system described herein is "universal" because it provides ports / interfaces and logic that can be used on vehicles from any type of manufacturer. For example, the system can be programmed with different logic and instructions for each different manufacturer. As another example, the system can be dynamically configured for a specific manufacturer. In this case, the system can be designed in advance to work with a specific OEM by swapping out replaceable parts on the system's motherboard.
[0015] According to an aspect of an exemplary embodiment, an apparatus is provided that may include a processor configured to receive acceleration values from a vehicle planning system and vehicle states from a state estimation system, convert the acceleration values and vehicle states into at least one of an engine torque value and a brake value, and generate a control signal for controlling vehicle speed based on the at least one of the engine torque value and the brake pressure value; and an output configured to transmit the control signal to a vehicle control system. In this context, the engine torque value may refer to either an actual torque signal transmitted directly to the engine or an accelerator pedal position that the engine would interpret to mean a similar torque value based on engine calibration. Furthermore, the brake value may refer to either a brake pressure value or an engine braking torque value.
[0016] According to an aspect of another exemplary embodiment, a method is provided that may include receiving an acceleration value from a planning system of the vehicle and a state of the vehicle from a state estimation system; converting the acceleration value and the state of the vehicle into at least one of an engine torque value and a brake value; generating a control signal for controlling a speed of the vehicle based on the at least one of the engine torque value and the brake pressure value; and transmitting the control signal to a control system of the vehicle.
[0017] According to an aspect of another exemplary embodiment, a non-transitory computer-readable medium is provided that includes instructions that, when executed by a processor, cause the computer to implement a method that may include receiving acceleration values from a planning system of the vehicle and a state of the vehicle from a state estimation system; converting the acceleration values and the state of the vehicle into at least one of an engine torque value and a brake value; generating a control signal for controlling a speed of the vehicle based on at least one of the engine torque value and the brake pressure value; and transmitting the control signal to a control system of the vehicle. [Brief explanation of the drawings]
[0018] The features and advantages of the illustrative embodiments, and the manner in which they are achieved, will become more readily apparent from the following detailed description taken in conjunction with the accompanying drawings.
[0019] [Figure 1] 2A-2C illustrate a control system that may be deployed on a vehicle such as the semi-truck depicted in FIGS. 2A-2C, according to an exemplary embodiment. [Figure 2A] FIG. 1 illustrates an exterior view of a semi-truck that may be used in accordance with an exemplary embodiment. [Figure 2B] FIG. 1 illustrates an exterior view of a semi-truck that may be used in accordance with an exemplary embodiment. [Figure 2C] FIG. 1 illustrates an exterior view of a semi-truck that may be used in accordance with an exemplary embodiment. [Figure 3A] FIG. 1 is a diagram illustrating electrical connections between physical input components of a vehicle according to the related art. [Figure 3B] FIG. 2 is a diagram illustrating electrical connections between physical input components of a vehicle in accordance with an exemplary embodiment. [Figure 4] FIG. 1 illustrates an AV system for generating actuation signals for physical input components of a vehicle, according to an exemplary embodiment. [Figure 5A] FIG. 1 illustrates a process for controlling physical input components of a vehicle in accordance with an exemplary embodiment. [Figure 5B] FIG. 1 illustrates a process for controlling physical input components of a vehicle in accordance with an exemplary embodiment. [Figure 5C] FIG. 1 illustrates a process for controlling physical input components of a vehicle in accordance with an exemplary embodiment. [Figure 6A] FIG. 10 illustrates a process of an acceleration control node generating an actuation signal to control the acceleration of a vehicle according to an exemplary embodiment. [Figure 6B] FIG. 10 illustrates an example of logic implemented by an acceleration control node to generate actuation commands, according to an exemplary embodiment. [Figure 7]FIG. 1 illustrates a method for controlling a physical input component of a vehicle, according to an exemplary embodiment.
[0020] Throughout the drawings and detailed description, the same drawing reference numbers should be understood to refer to the same elements, features, and structures unless otherwise stated. The relative size and depiction of these elements may be exaggerated or adjusted for clarity, illustration, and / or convenience. DETAILED DESCRIPTION OF THE INVENTION
[0021] In the following description, specific details are set forth to provide a thorough understanding of various exemplary embodiments. It should be understood that various modifications to the embodiments will be readily apparent to those skilled in the art, and that the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Moreover, in the following description, numerous details are set forth for purposes of explanation. However, those skilled in the art should understand that the embodiments may be practiced without the use of these specific details. In other instances, well-known structures and processes are not shown or described so as not to obscure the description with unnecessary detail. Thus, the present disclosure is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
[0022] For convenience and ease of description, certain terminology is used herein. For example, the term "semi-truck" is used to refer to a vehicle in which the system of the exemplary embodiment may be used. The terms "semi-truck," "truck," "tractor," "vehicle," and "semi" may be used interchangeably herein.
[0023] Light detection and ranging (lidar) sensors are used by vehicles to measure surrounding areas by obtaining a sparse point cloud using distances to points in the point cloud measured by a light beam from the lidar sensor. Lighting operates independently of ambient light and can be used in any condition. Furthermore, lidar sensors can capture data that can be used to generate a three-dimensional (3D) map of the world. Meanwhile, vehicle cameras can capture images (e.g., RGB images, black and white images, etc.) of the world around the vehicle, providing complementary data to the lidar data captured by the lidar sensor. For example, cameras can capture data such as color, texture, and appearance, while lidar can capture and model the structural aspects of the data.
[0024] In many vehicles, the perception of the vehicle is based on a combination (i.e., joint) of lidar data from a lidar sensor and image data captured by a camera. For accurate perception, these two systems must be aligned with each other. Calibration can be performed by changing extrinsic parameters, such as rotation and translation between the lidar sensor and camera coordinate frames, to align the lidar sensor's coordinate frame with the camera's coordinate frame. These extrinsic parameters can be used to fuse information from the lidar sensor and image sensor together when visualizing the vehicle and interpreting visual data from the road.
[0025] Using calibrated sensors, a vehicle can capture images and lidar readings of the area surrounding the vehicle and build / modify a three-dimensional map that is stored internally in the vehicle's computer (or remotely via a web server). The vehicle can position itself within the map and decide how to steer, turn, slow down, etc. based on other objects, lanes, entrance lanes, exit lanes, etc. in the map. An autonomous vehicle may use one or more computer systems to control the vehicle to move autonomously without user input. For example, a vehicle may be equipped with an autonomous vehicle (AV) system that generates signals to control the engine, steering wheel, brakes, etc. based on other objects, lanes, entrance lanes, and exit lanes in the map.
[0026] However, many features of a vehicle are still operated (sometimes solely) by a user who uses their hands, feet, etc. to input commands (physical actions) into the vehicle's physical input mechanisms. For example, headlights, accelerator pedal, brake pedal, turn signals, input buttons, etc. are examples of physical input mechanisms that may be used to control parts of a vehicle. For example, a user may use their hand to turn on a headlight or activate a turn signal by turning on the headlights or activating the turn signal. As another example, a person may use their foot to press an accelerator pedal to accelerate the engine, and similarly, they may use their foot to press a brake pedal to apply a braking system and slow down the vehicle's wheels.
[0027] Exemplary embodiments are directed to an interfacing system (interface system) that generates control signals for physical input mechanisms that mimic or otherwise emulate actuation signals created by these physical input mechanisms, thereby electronically controlling corresponding physical components of the vehicle based on instructions from a vehicle computer rather than a user physically entering commands within the vehicle. The system may be referred to herein as an interface system, a universal interface, or the like. The system may include a housing that holds a motherboard, circuit components (e.g., a processor, resistor modules, etc.) installed therein, and the like. Further, the motherboard may include interfaces that allow the system to physically connect to various components of the vehicle. For example, the interface may include, but is not limited to, mounting harnesses, ports, cables, etc., or other attachment means for receiving and connecting wiring (e.g., wiring harnesses) of other components of the vehicle. For example, the system may be electrically connected / attached to vehicle wiring (e.g., wiring harnesses of the physical input mechanisms and wiring harnesses of a control unit for controlling the corresponding physical components).
[0028] According to various embodiments, the system may disable or otherwise block signals from the physical input mechanism from being used to control / actuate the physical input mechanism, and instead replace the signals from the physical input mechanism with signals from control signals triggered by the vehicle's computer. For example, the system may be integrated into the vehicle's computer and connected to the vehicle's AV system, which may send requests or commands to the system to cause it to mimic physical inputs by a user on the vehicle's component's physical input mechanism.
[0029] In some examples herein, the vehicles are illustrated as semi-trucks. However, it should be understood that the illustrative embodiments are applicable to any type of autonomous vehicle and may include not only trucks or semi-trucks, but instead automobiles, boats, tractors, motorcycles, etc., as well as trucks of all types.
[0030] Figure 1 illustrates a control system 100 that may be deployed on a vehicle, such as the semi-truck 200 depicted in Figures 2A-2C, according to an example embodiment. With reference to Figure 1, control system 100 may include a number of sensors 110 that collect data and information that are provided to a computer system 140 to perform operations, including, for example, control operations to control vehicle components via a gateway 180. According to some embodiments, gateway 180 is configured to allow computer system 140 to control several different components from different manufacturers.
[0031] Computer system 140 may be configured, along with one or more central processing units (CPUs) 142, to perform processing, including processing for implementing features of embodiments of the present invention described elsewhere herein, and to receive sensor data from sensors 110 for use in generating control signals to control one or more actuators or other controllers associated with the vehicle's systems (including, for example, actuators or controllers that enable control of throttle 184, steering system 186, brakes 188, etc.). Generally, control system 100 may be configured to operate semi-truck 200 in an autonomous (or semi-autonomous) operating mode. In some embodiments, computer system 140 may include an AV system 143 for controlling the systems further described herein with respect to FIGS. 3, 4, 5A-5C, and 6. For example, AV system 143 may be located within computer system 140.
[0032] In operation, the control system 100 may be operated to capture images from one or more cameras 112 mounted at various locations on the semi-truck 200 and perform processing (e.g., image processing) on the images to identify objects proximate to or in the path of the semi-truck 200. Additionally, the lidar 114 and radar 116 sensors may be positioned to sense or detect the presence and volume of objects proximate to or in the path of the semi-truck 200. Other sensors may also be positioned or mounted at various locations on the semi-truck 200 to capture other information, such as position data. For example, the sensors may include one or more satellite positioning sensors, such as the GNSS / IMU 118, and / or an inertial navigation system. The Global Navigation Satellite System (GNSS) is a space-based satellite system that provides location information (longitude, latitude, altitude) and time information anywhere on or near the Earth, in all weather conditions, to devices called GNSS receivers. GPS is the most widely used GNSS system in the world. An inertial measurement unit ("IMU") is an inertial navigation system. Generally, an inertial navigation system ("INS") measures and integrates the orientation, position, velocity, and acceleration of a moving object. The INS integrates the measured data, and the GNSS is used as a correction for integration errors in the INS orientation calculation. Any number of different types of GNSS / IMU 118 sensors may be used in conjunction with the features of the present invention. Data collected by each of these sensors may be processed by the computer system 140 to generate control signals that control the operation of the semi-truck 200. Image and location information may be processed to identify or detect objects around or within the path of the semi-truck 200, and control signals may be emitted to adjust the throttle 184, steering 186, or brakes 188 as needed to safely operate the semi-truck 200. While illustrative example sensors and actuators or vehicle systems are shown in FIG. 1, those skilled in the art will understand, upon reading this disclosure, that other sensors, actuators, or systems may also be used.For example, in some embodiments, actuators may also be provided that allow for control of the transmission of the semi-truck 200 .
[0033] Control system 100 may include a computer system 140 (e.g., a computer server) configured to provide a computing environment in which one or more software or control applications (e.g., items 160-182) may execute to perform the processes described herein. In some embodiments, computer system 140 includes components deployed on semi-truck 200 (e.g., they may be deployed in a system rack 240 positioned within berth 212, as shown in FIG. 2C). Computer system 140 may communicate with other computer systems (not shown) that may be remote from semi-truck 200 (e.g., the computer systems may communicate via a network connection).
[0034] In some examples, computer system 140 may be implemented as a server. Furthermore, computer system 140 may be configured using any of several well-known computing systems, environments, and / or configurations, such as, but not limited to, a personal computer system, a cloud platform, a server computer system, a thin client, a thick client, a handheld or laptop device, a tablet, a smartphone, a database, a multiprocessor system, a microprocessor-based system, a set-top box, a programmable consumer electronics product, a network PC, a minicomputer system, a mainframe computer system, a distributed cloud computing environment, or the like, and may include any of the above systems or devices.
[0035] Several different software applications or components may be executed by computer system 140 and control system 100. For example, as shown, an active learning machine processing application (active learning component 160) may be provided to process images captured by one or more cameras 112 and information obtained by lidar 114. For example, image data may be processed using a deep learning segmentation model 162 to identify objects of interest within those images (e.g., other vehicles, construction signs, etc.). Lidar data may be processed by machine learning application 164 to draw or identify bounding boxes on the image data to identify objects of interest located by the lidar sensor. Information output from the machine learning application may be provided as input to object fusion 168 and vision map fusion 170 software components, which may predict the behavior of other road users, fuse local vehicle pose with global map geometry in real time, and perform processing to enable on-the-fly map correction. Output from the machine learning application may be complemented with information (as well as positioning data) from radar 116 and map localization 166 application data. These applications enable control system 100 to be less map-dependent and better able to handle constantly changing road environments. Furthermore, by correcting any map errors on the fly, control system 100 can facilitate safer, more scalable, and more efficient operation compared to alternative map-centric approaches. Information is provided to prediction and planning application 172, which provides input to trajectory planning 174 component, which enables trajectory 176 to be generated in real time based on interactions and predicted interactions between semi-truck 200 and other associated vehicles in the environment. In some embodiments, for example, control system 100 generates a 60-second planning horizon and analyzes the relevant actors and available trajectories.The plan that best meets multiple criteria (including safety, comfort, and route preference) is selected, and any associated control inputs necessary to implement the plan are provided to controller 182 to control the movement of semi-truck 200.
[0036] These applications or components (as well as other components or flows described herein) may be implemented in hardware, a computer program executed by a processor, firmware, or a combination of the above. The computer program may be embodied on a computer-readable medium, such as a storage medium or device. For example, the computer program may reside in random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.
[0037] The storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application-specific integrated circuit ("ASIC"). Alternatively, the processor and the storage medium may reside as separate components. For example, FIG. 1 illustrates an exemplary computer system 140 that may represent or be integrated with any of the components described above. FIG. 1 is not intended to suggest any limitation regarding the scope of use or functionality of the embodiments of the present application described herein. The computer system 140 may implement and / or perform any of the functions described above.
[0038] Computer system 140 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system 140 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.
[0039] 1, computer system 140 is shown in the form of a general-purpose computing device. Components of computer system 140 may include, but are not limited to, one or more processors (such as CPU 142 and GPU 144), a communications interface 146, one or more input / output interfaces 148, and a storage device 216. Although not shown, computer system 140 may also include a system bus coupling various system components, including system memory, to CPU 142. In some embodiments, input / output interface 148 may also include a network interface. For example, in some embodiments, some or all of the components of control system 100 may communicate via a controller area network ("CAN") bus or the like.
[0040] Storage device 150 may include various types and forms of computer-readable media. Such media may be any available media accessible by the computer system / server and may include both volatile and nonvolatile media, removable and non-removable media. In one embodiment, system memory implements the flow diagrams of other figures. System memory may include computer-readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. As another example, storage device 150 may read and write to non-removable, non-volatile magnetic media (not shown, typically referred to as a "hard drive"). Although not shown, storage device 150 may include one or more removable, non-volatile disk drives, such as magnetic, tape, or optical disk drives. In such an example, each may be connected to a bus by one or more data media interfaces. Storage device 150 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of the application.
[0041] 2A-2C are diagrams illustrating the exterior of a semi-truck 200 that may be used in accordance with exemplary embodiments. With reference to FIGS. 2A-2C, the semi-truck 200 is shown for illustrative purposes only; those skilled in the art will understand, upon reading this disclosure, that the embodiments may be used in conjunction with several different types of vehicles. The exemplary semi-truck 200 shown in FIGS. 2A-2C is configured in a typical North American style with an engine 206, steering axle 214, and drive axle 216 forward of the cab 202. A trailer (not shown) is attached to the semi-truck 200 via a fifth-wheel trailer coupling mounted on a frame 218 positioned above the drive axle 216. A sleeping compartment 212 is positioned behind the cab 202. Several sensors are positioned in different locations on the semi-truck 200. For example, sensors may be mounted on the roof of the cab 202 on a sensor rack 220. Sensors may also be mounted on the side mirrors 210, as well as elsewhere. As discussed, sensors may be mounted on the bumper 204, as well as on the side of the cab 202, or elsewhere. For example, rear-facing radar 236 is shown mounted on the side of the cab 202 in FIG. 2A . Embodiments may be used in other configurations of trucks or other vehicles (e.g., semi-trucks having cab-over or cab-forward configurations, etc.). Generally, and without limiting embodiments of the invention, features of the invention may be used with desirable results in vehicles that haul cargo over long distances, such as long-distance semi-truck routes.
[0042] FIG. 2B is a front view of semi-truck 200 illustrating several sensors and sensor locations. A sensor rack 220 may secure and position several sensors, including a long-range lidar 222, a long-range camera 224, a GPS antenna 234, and a medium-range forward-facing camera 226. Side mirrors 210 may provide mounting locations for a rear-facing camera 228 and a medium-range lidar 230. A front radar 232 may be mounted on the bumper 204. Other sensors may be mounted or installed elsewhere; the locations and mounting depicted in FIGS. 2A-2C are for illustrative purposes only. Referring now to FIG. 2C, a partial view of semi-truck 200 is shown showing the interior of cab 202 and sleeper compartment 212. In some embodiments, portions of control system 100 of FIG. 1 are deployed in a system rack 240 within sleeper compartment 212, allowing easy access to components of control system 100 for maintenance and operation.
[0043] The illustrative embodiments are directed to new technology never before created. The interface system described herein is a hardware system (e.g., a box or other device) having a motherboard and various components embedded therein, including adapters (e.g., ports, mounting harnesses, slots, etc.) for electrically connecting to various vehicle hardware, and a processor for controlling the signaling of the system. The system allows a vehicle's computer (e.g., the AV system) to electronically control a system that the AV system was not designed to have electronic control from a third-party system.
[0044] Despite advances in autonomous vehicle technology, many aspects of vehicles are still designed to be controlled by humans (i.e., by human touch or otherwise physically contacting and operating a physical input mechanism). For example, an accelerator pedal or brake pedal is intended to be depressed by a person using their foot to push the pedal. Similarly, a turn signal stalk is intended to be pulled up or down or a dial turned by a user's hand. Similarly, input buttons for cruise control, climate control, user interface input, hazard lights, etc. are all designed to be operated by a user making physical contact with some physical input mechanism with their hand.
[0045] The interface system described herein provides the ability for a vehicle's AV system to turn the vehicle's systems off and on as if the driver were controlling the vehicle's systems. The system also allows the vehicle's computer to implement the driver's behavior within the vehicle so that the vehicle cannot know whether a human or a computer is operating the vehicle. This gives the autonomous vehicle (AV)'s electronic systems the ability to control the vehicle like a human.
[0046] The interface system may be physically attached (e.g., using cables, wires, wiring harnesses, input ports, mounting harnesses, etc.) to various equipment / components of a vehicle, such as the brake pedal or brake actuation device (and its sensor), the accelerator pedal (and its sensor), or the handle on the steering column (and its sensor). Once attached to the various components, the interface system may be mounted under the vehicle's console, hidden from view. The system is considered a "universal" interface or system because it can be adapted to fit all types of vehicles and therefore interface with all types of OEMs, including PETERBILT®, NAVISTAR®, VOLVO®, DAIMLER®, KENWORTH®, etc. These are the four major OEMs serving the U.S. semi-truck market, but it should be understood that the system can work with all vehicles and all OEMs, not just semi-trucks. This is useful for achieving a universal interface. Furthermore, the system may conform to the vehicle's vertical controller area network (CAN) architecture, making it compatible. Thus, the system's software may be configured with CAN architecture functionality.
[0047] As an example, when moving a vehicle autonomously, the AV system interacts with an engine control unit, which controls the torque output of the engine, and a transmission control unit, which changes gears. Traditionally, the vehicle's AV system provides a torque value to the engine control unit. In response, the engine control unit adjusts the engine's torque output based on the torque command value. However, most OEM vehicles not specifically designed for autonomous driving have transmission control units that are not designed to simply select a gear based on torque, because other factors, such as gear ratio, pedal position, and RPM, are required. Therefore, what typically happens is that the transmission control unit goes through a tuning process to guess the best gear and continues to adjust the gear until the best gear that meets the requested torque is found. This process can take a significant amount of time. Furthermore, if the vehicle is climbing a hill or performing other actions that strain the vehicle's movement, the tuning process may take even longer.
[0048] In an exemplary embodiment, the interface system may convert values provided by the vehicle computer (e.g., torque values, RPM values, etc.) into pedal position values (e.g., sensor readings) that identify the actual pedal position of the accelerator pedal as if it were being pressed by the driver's foot. The system may store or otherwise access a table (e.g., a look-up table, etc.) that includes a mapping of pedal position to torque and / or RPM values. The table need not include every possible combination of torque, RPM, and corresponding pedal position values. Instead, the system may use a sparse map to interpolate torque, RPM, and pedal position values based on other known torque, RPM, and pedal position values stored in the table. Essentially, the system determines the pedal position value (e.g., pedal movement / depression distance) to achieve such torque at such RPM. In response, the engine control unit and transmission control unit can nearly instantly determine the speed and gear. Here, the engine control unit may use the torque, RPM, and / or pedal position value. Similarly, the transmission control unit may use the pedal position value, a process that significantly reduces the traditional tuning process.
[0049] Every OEM does the same thing, but they might use different connectors and different communication protocols. In other words, every OEM essentially uses the same pulse-width modulation (PWM) control on the engine; they just change the voltage level between PWM and analog values, and they change the connector. Here, the interface system can be directly attached to the wiring of the engine control unit and AV system, and the system has a flexible input system that can handle any of these signals. For example, different resistors on the system's motherboard can be used for different OEMs (truck types). In this case, the board can be configured to use one of these resistors depending on the type of truck the system is installed in. Furthermore, additional jumpers can be used to change the CAN bus supply and turn CAN routing functions on and off. In the trucking industry, a system might be designed with four different versions of the same board with four different configurable resistor modules for four major OEMs. The interface system can receive CAN commands, apply conversions to the commands to generate signals for controlling vehicle components, such as actuators and control units, and send the signals to the components. Furthermore, the interface system can receive reports back from the components confirming the execution of the commands. The interface system can then provide this report to other components of the vehicle, such as the vehicle's computer, to allow visibility of commands throughout the vehicle.
[0050] Controlling throttle pedal position using the interface described in the previous section is a universal solution that works across different OEM platforms and avoids the drawbacks of sending torque commands directly to the engine via the CAN bus. However, certain OEMs and powertrain suppliers have recently improved their firmware to avoid some of these drawbacks by implementing specific control interfaces for autonomous driving systems. In these systems, response to torque commands is faster than pedal position commands, but less hardware is required. When this firmware is present in an OEM vehicle, the interface components can be configured to send CAN commands directly to powertrain components instead of changing the accelerator pedal position.
[0051] FIG. 3A illustrates a diagram 300 of electrical connections between vehicle components, according to the related art. With reference to FIG. 3A , a vehicle may include physical input mechanisms within a vehicle interior 310, including an accelerator pedal 312, a brake pedal 314, and a handle 316, which may be mounted on (or below) the steering wheel and used to control headlights, turn signals, cruise control, etc. Each of the physical input mechanisms (e.g., accelerator pedal 312, brake pedal 314, handle 316, etc.) may be wired to one or more actuation systems of a vehicle control unit, such as an engine control unit, a transmission control unit, a CAN bus, etc. Although not shown in FIG. 3A , there may also be other physical input mechanisms, such as buttons for hazard lights, cruise control, etc., which may each be controlled.
[0052] 3A, a user may press an accelerator pedal 312 (or brake pedal 314), and a sensor attached to the accelerator pedal 312 may send a signal to an actuation mechanism 320 to actuate physical components of the vehicle, such as the engine and braking system (e.g., air brakes, etc.). The actuation mechanism 320 may include an engine control unit, a transmission control unit, and a braking system control unit or actuator. The signal may include a displacement value measured by the sensor in response to the accelerator pedal 312 being depressed. In other words, the displacement value may represent the amount of distance the accelerator pedal 312 is depressed by the user / driver's foot.
[0053] FIG. 3B illustrates a diagram 330 of electrical connections between physical input components of a vehicle, according to an exemplary embodiment. In this example, the vehicle's actuation mechanism 320 is modified to include an autonomous vehicle driving system according to various embodiments. In particular, the actuation mechanism 320 includes an autonomous vehicle (AV) system 324 and an interface system 326. The AV system 324 may include an acceleration control node of the exemplary embodiment, which is configured to generate engine torque or brake pressure values in response to acceleration or deceleration requests, respectively, from the vehicle's computer. The AV system 324 may generate triggers itself or may receive triggers from another unit on the vehicle or a remote server. The AV system 324 may include one or more input ports for electrically connecting to the vehicle's computer and other components. The AV system 324 may also include an output port for electrically connecting to the interface system 326, for example, via a wiring harness or the like.
[0054] When interface system 326 receives an engine torque value or brake pressure value from AV system 324, interface system 326 converts the value (and possibly other values, such as RPM) into an actuation signal for triggering actuation of the engine or brake system according to the converted value. Interface system 326 may use a conversion table to convert the engine torque value (and RPM value) into a pedal position displacement value that mimics the displacement of accelerator pedal 312 when pressed by a user's foot. In this case, however, the actuation signal originates from AV system 324 rather than accelerator pedal 312. In response, interface system 326 may then send an actuation signal to control unit 322, such as an engine control unit and / or a transmission control unit, that changes speed (and possibly gear) based on the pedal position displacement value. Although not shown in FIG. 3B , interface system 326 may interrupt or switch off an electrical connection with accelerator pedal 312 in response to the signal received from AV system 324.
[0055] On the other hand, if the AV system 324 sends a brake pressure value to the interface system 326, the interface system may send a brake pressure command to the brake actuation system, which will trigger the brake system to apply braking force to the wheels of the vehicle. The interface system 326 and brake actuation system may be connected to the vehicle such that the OEM vehicle will perceive the brake pressure as if it came from the brake pedal 314, even though it is from the AV system 324.
[0056] The AV system 400 according to various embodiments is integrated into a vehicle. For example, the AV system 400 may be installed attached to or otherwise connected to wiring between the physical input mechanisms and the control unit 322. Here, the AV system 400 may include interfaces for receiving wiring harnesses from the accelerator pedal 312, the brake pedal 314, and the handle 316, as well as sensors attached thereto. It should also be understood that in these examples, the brake pedal 314 may refer to a brake actuation system (e.g., air brakes, etc.) that can convert compressed air force in the truck's air reservoir into mechanical force that can be used to actuate the brakes. In this case, the interface system 326 may be used to block signals from different physical input mechanisms (e.g., using relays, gates, switches, etc. internal to the AV system 400) and generate control signals that appear as if they were coming from the physical input mechanisms (e.g., the accelerator pedal 312, the brake pedal 314, and the handle 316).
[0057] The control signals may mimic or otherwise match signals that would be transmitted from a physical input mechanism. However, rather than requiring a user to press or otherwise interact with a physical input mechanism, the control signals may be triggered by a command or request from a vehicle computer, such as the AV system 324. The control signals may be received by the control unit 322 and processed as if they came from an actual physical input mechanism. Thus, the vehicle computer may control the physical input mechanisms (e.g., accelerator pedal 312, brake pedal 314, steering wheel 316, etc.) as if a human were present inside the vehicle 310. Meanwhile, the control unit 322 is unaware that the control signals are not from a human interacting with a physical input mechanism. Additionally, the vehicle computer may utilize a control interface specifically designed as a mechanism for the autonomous driving system to command OEM vehicle systems. Such an interface may include sending torque commands directly to the engine and transmission units via a CAN bus, with the ability to communicate to the units that the messages originate from the autonomous driving system.
[0058] FIG. 4 illustrates an AV system 400 for automatically driving an autonomous vehicle. In this example, the AV system 400 may generate actuation signals for physical input components of the vehicle according to an exemplary embodiment. Referring to FIG. 4, the AV system 400 may be the AV system 324 shown in FIG. 3B used for planning and route guidance. In this example, the AV system 400 includes a motion planning system 402 configured to generate a route or path for the vehicle and a state estimation system 404 configured to capture sensor data, such as radar, lidar, imagery, etc., and estimate various attributes of the vehicle, such as its attitude, its speed, other objects / vehicles on the road, the vehicle's current lane, etc.
[0059] In an exemplary embodiment, motion planning system 402 may generate a desired acceleration value and transmit it to acceleration control node 406. State estimation system 404 may generate a state estimation signal and transmit it to acceleration control node 406, the state estimation signal including one or more values for the current vehicle speed, the current lane, vehicle data for surrounding vehicles, other objects on the road, etc. Motion planning system 402 and state estimation system 404 may be triggered to transmit their data by a signal from AV system 400 itself or from another system external to the AV system. In response, acceleration control node 406 may invoke actuator modeling system 408, which uses physics-based models to convert the vehicle state and acceleration values into one of an engine torque value and a brake pressure value, which are then output and transmitted to interface system 326 shown in FIG. 3B. In this context, engine torque value may refer to either an actual torque signal transmitted directly to the engine or an accelerator pedal position that the engine will interpret to mean a similar torque value based on engine calibration. Furthermore, brake value may refer to either a brake pressure value or an engine braking torque value.
[0060] 5A-5C illustrate a process for controlling the physical input of a vehicle's engine 522 or braking system 524, according to an exemplary embodiment. In some embodiments, both the engine 522 and braking system 524 may be controlled, or only one of the systems may be controlled. In particular, FIG. 5A illustrates a process 500 in which a control signal is generated by the vehicle's accelerator pedal 510 being depressed by the driver's foot. When depressed, the accelerator pedal sends a signal to a control unit to increase the engine speed. In this example, the AV and interface systems described above are not embodied in the vehicle or are not used. Here, accelerator pedal 510 may refer to an accelerator pedal, a brake pedal, etc.
[0061] 5A, accelerator pedal 510 has a start position 511a before a physical input and an end position 511b (displaced location) after the physical input. In response, pedal sensor 512 measures the difference between start position 511a and end position 511b of accelerator pedal 510 to determine a pedal displacement value and sends a control signal with the displacement value to control unit 520, such as an engine control unit, a transmission control unit, a brake system control unit, or a combination thereof, which generates actuation signals to drive a vehicle engine 522 and a brake system 524.
[0062] As one example, the control unit 520 may include an engine control unit and a transmission control unit configured to command the engine 522 to accelerate when pedal position values (or other values) received from sensors indicate that the vehicle should speed up. As another example, the control unit 520 may include a torque retarder / engine retarder within or otherwise coupled to the engine 522. The torque retarder may have its own ECU. In semi-trucks, the torque retarder is often referred to as a "jake brake." The engine retarder may use negative torque commands to modify the operation of the engine so that it acts as a power-absorbing component (e.g., the engine retarder applies load / friction to the engine 522, which slows the vehicle, etc.). In some cases, the engine retarder may be used, such as on long downhill slopes, where a braking system is not needed, but rather engine deceleration is sufficient to slow the vehicle in time. The engine retarder does not access brake pads but rather controls the braking system.
[0063] FIG. 5B illustrates a process 550 for a vehicle including an autonomous vehicle system (AV system 540) and an interface system 530. In this case, the AV system 540 also includes an acceleration control node having a physics-based model for interpreting acceleration and state values from the vehicle's computer into engine torque or braking values used to operate the vehicle's engine or braking system. In this case, the acceleration control node may be a software program installed within the AV system 540 that determines the torque or braking values. However, in this case, the AV system 540 is turned off by opening a switch 544 between the AV system 540 and the interface system 530. Meanwhile, the switch 514 between the pedal sensor 512 and the interface system 530 is closed / enabled. In this scenario, the interface system 530 will receive a pedal displacement value / reading from the pedal sensor 512 and allow it to pass through to the control unit 520. In other words, even though the AV system 540 and the interface system 530 are included within the vehicle, the vehicle can still be operated under its normal acceleration and deceleration operations.
[0064] 5C illustrates a process 560 in which interface system 530 closes switch 544 between AV system 540 and interface system 530 and opens switch 514 between pedal sensor 512 and interface system 530. In doing so, interface system 530 allows AV system 540 to control the vehicle's movement and route / path of travel. In this example, AV system 540 (e.g., acceleration control node 406, etc.) may interact with physics-based model 542 to create input signals that can be interpreted by interface system 530. For example, the physics-based model may determine an engine torque value or a brake value based on the model. A request 546 having the engine torque value or brake value generated by physics-based model 542 may be sent from AV system 540 to interface system 530. Request 546 may include other data attributes generated by AV system 540, such as RPM. In response, interface system 530 may convert the value in request 546 into a pedal displacement value, such as an accelerator pedal displacement value (acceleration) or a brake pressure value (deceleration) for a braking system. To do this, interface system 530 may store or otherwise access a conversion table that maps torque / RPM combinations to pedal displacement measurements.
[0065] Meanwhile, interface system 530 may establish pulse width modulation (PWM) signals between AV system 540 and control units 520, such as an engine control unit and a transmission control unit, where interface system 530 may receive requests 546 from AV system 540, generate control signals that mimic the signals from accelerator pedal 510, and send the control signals to control unit 520. In response, the control units may control actuators associated with the engine or braking system to accelerate the vehicle (increase engine output torque) or decelerate the vehicle (apply / activate the brakes).
[0066] When a user commands the accelerator pedal 510, the user can use their foot to press the accelerator pedal 510, causing a change in pedal position from a start position 511a to an end position 511b. This change in pedal position can be sensed by one or more sensors (not shown) and transmitted to the engine control unit. In contrast, in the example of FIG. 5C, the vehicle's computer systems, including the AV system 540 and interface system 530, can create signals that mimic the sensor signals. Thus, the control unit 520 does not know whether the signal is coming from the pedal sensor 512 or the AV system 540.
[0067] 5C, the engine 522 may include a kill switch or the like that can receive a kill signal, also referred to herein as an emergency stop signal, from the vehicle computer. In response, the interface system 530 may use a switch 544 or other relay to disable the connection between the AV system 540 and the control unit 520 and enable the connection from the pedal sensor 512 to the control unit 520.
[0068] Figure 6A illustrates a process 600 by which an acceleration control node 620 generates actuation signals to control the acceleration of a vehicle, according to an exemplary embodiment, and Figure 6B illustrates an example of logic used by the acceleration control node to model actuation commands of control units on the vehicle, such as an engine control unit, a transmission control unit, a jake brake, etc. In particular, Figure 6A illustrates the process of acceleration control node 620, which may correspond to acceleration control node 406 of Figure 4. In this example, acceleration control node 620 may be installed within or otherwise coupled to AV system 540 shown in Figure 5C.
[0069] 6A, acceleration control node 620 includes a control force generator 622 and an actuator command generator 624. These models may determine the force required to reach a desired acceleration (control force generator 622) and convert that force into an appropriate actuation signal to cause the vehicle to achieve such force (actuator command generator 624). For example, acceleration control node 620 may receive a requested acceleration value from a motion planning system 610, which may be included within the vehicle's AV system or other system. The acceleration value may be a desired value obtained by the vehicle and may differ from the vehicle's current speed / acceleration.
[0070] The acceleration control node 620 may obtain various state information of the vehicle from the motion planning system 610 to make a decision on how to handle the requested acceleration. For example, the state measurement node 612 may obtain various settings and characteristics of the vehicle, such as the current gear the engine / transmission is running in, the maximum available engine torque available to increase acceleration, the maximum available braking torque available to slow the engine, engine speed, etc. Additionally or alternatively, the acceleration control node 620 may also obtain estimated state values of the vehicle, such as estimated mass, speed, drag, pitch, roll resistance, engine friction, maximum traction, wheel radius diameter, driveline efficiency, applied engine braking force, mass coefficient, pitch, etc. Furthermore, the acceleration control node 620 may also receive vehicle configuration data, such as the vehicle's braking system characteristics and throttle pedal characteristics.
[0071] 6A , control force generator 622 receives acceleration values from motion planning system 610, while actuator command generator 624 receives vehicle configuration data 616. Meanwhile, both control force generator 622 and actuator command generator 624 receive measured states from state measurement node 612 and estimated states from state estimation node 614. In response, control force generator 622 may determine appropriate forces necessary to control the vehicle to reach a desired acceleration value based on the vehicle state. For example, control force generator 622 may generate control force values using one or more physics-based models. Control force generator 622 may output the control force values and input them to actuator command generator 624. In response, actuator command generator 624 may generate control signals, such as actuation commands, to control vehicle actuators, such as an engine control unit, a brake control unit, a throttle control unit, etc. Additionally, the actuator command generator 624 may output actuation commands to the interface system 630, which converts the commands into actuation signals that are then sent to the corresponding actuators.
[0072] An example of logic embodied in actuator command generator 624 is shown and further described in Figure 6B. Referring to Figure 6B, a process 640 is illustrated that converts a control force value 642 into actuator commands 661, 662, 663, 664, 665, or 666. In this example, the actuator command generator may receive the control force value 642, which may be a numeric value, and compare it to one or more thresholds, such as a maximum coasting threshold.
[0073] For example, if the control force exceeds the maximum coasting threshold, the vehicle needs to accelerate. Here, the actuator command generator 624 can generate either a pedal position control signal 651 to control the engine by adjusting the accelerator pedal position, or an engine torque control signal 652 to directly control the engine with a torque command via the CAN bus. An example of the pedal position control signal 651 is shown in actuator command 661. Here, the control signal includes a pedal position command without changing the brake pressure (BP), engine brake torque (EBT), or throttle. Meanwhile, an example of the engine torque control signal 652 is shown in actuator command 662. In this example, the actuator command 662 adjusts the engine throttle value to increase engine speed based on torque instead of pedal position. The decision of whether to use the pedal position control signal 651 or the engine torque control signal 652 is made based on the method best supported by the OEM vehicle's engine type.
[0074] As another example, if the control force value 642 is below the maximum coast threshold but above the minimum coast threshold, the logic may determine a coast control signal 653 (do not accelerate or decelerate). An example of such a coast control signal is shown in actuator command 663, which does not modify any of the actuators (all values are zero). As another example, if the logic determines that the control force value 642 is below the minimum coast threshold, the actuator command generator 624 may determine to apply the brakes in some manner. There are different possible control signals for braking, such as a base brake control signal 654, an engine brake control signal 655, or a combination of both 656. Further, corresponding actuator commands 664, 665, and 666 are shown for controlling the base brake control signal 654, the engine brake control signal 655, and both 656, respectively.
[0075] 7 illustrates a method 700 for controlling the actuation of a physical input mechanism of a vehicle, according to an example embodiment. As an example, the method 700 may be performed by an acceleration control node that may be implemented in an AV system, such as an autonomous vehicle. Referring to FIG. 7, at 710, the method may include receiving an acceleration value from a planning system of the vehicle and a state of the vehicle from a state estimation system.
[0076] As an example, the acceleration value may be a positive acceleration value (e.g., acceleration) or a negative acceleration value (e.g., deceleration). The vehicle state may include both data read from the vehicle's on-board systems, such as the current gear of the transmission system, available engine torque, available retarder torque, engine speed, etc. As another example, or in addition, the vehicle state may be provided by an estimation node that may estimate characteristics such as mass, speed, drag, roll, pitch, engine friction, maximum tractive effort, wheel radius, driveline efficiency, applied engine braking force, mass coefficient, etc.
[0077] At 720, the method may include converting the acceleration value and the state of the vehicle into at least one of an engine torque value and a braking value. At 730, the method may include generating a control signal for controlling a speed of the vehicle based on at least one of the engine torque value and the braking value. Further, at 740, the method may include transmitting the control signal to a control system of the vehicle.
[0078] In some embodiments, converting may include converting the acceleration value and the vehicle state to an engine torque value, and generating may include generating a control signal for controlling an actuator of the vehicle. In some embodiments, transmitting may include transmitting the control signal to the engine control unit via a gateway interface configured to convert the engine torque value to a pedal position displacement value. In some embodiments, transmitting may include transmitting the control signal directly to the engine control unit as an engine torque command without converting the command to a pedal position.
[0079] In some embodiments, converting includes converting the acceleration values and vehicle state to braking values, and generating includes generating a control signal to control an actuator of the vehicle to apply pressure in a braking system that will activate brake pads on the wheels with a desired force. In some embodiments, converting may include converting the acceleration values and vehicle state to braking forces and generating a control signal to control an actuator of the vehicle to apply a braking action to drive wheels of the vehicle to slow the vehicle without using service brakes.
[0080] In some embodiments, receiving the vehicle state may include reading one or more of the vehicle's current gear, maximum available engine torque, maximum available retarder torque, and engine speed from a system on the vehicle. In some embodiments, receiving the vehicle state may include receiving one or more of the vehicle's current mass, the vehicle's current speed, the current pitch, and the wheel radii of the wheels on the vehicle, estimated by an estimation node of the vehicle. In some embodiments, generating may include converting the acceleration values and the vehicle state into control forces, and generating includes generating actuation commands including at least one of a brake pressure command, an engine brake command, an accelerator pedal position command, or an engine torque command based on the actuator model and the control forces. In some embodiments, transmitting includes transmitting the actuation commands to at least one of a transmission control unit, an engine control unit, a brake control unit, and a torque retarder.
[0081] As will be understood based on the foregoing specification, the above-described examples of the present disclosure may be implemented using computer programming or engineering techniques, including computer software, firmware, hardware, or any combination or subset thereof. Any such resulting program having computer-readable code may be embodied or provided in one or more non-transitory computer-readable media, thereby creating a computer program product, i.e., an article of manufacture, according to the discussed examples of the present disclosure. For example, the non-transitory computer-readable medium may be, but is not limited to, a fixed drive, a diskette, an optical disk, a magnetic tape, flash memory, an external drive, semiconductor memory such as read-only memory (ROM), random access memory (RAM), and / or any other non-transitory transmission and / or reception medium, such as the Internet, cloud storage, the Internet of Things (IoT), or other communications network or link. An article of manufacture including the computer code may be created and / or used by executing the code directly from one medium, by copying the code from one medium to another, or by transmitting the code over a network.
[0082] A computer program (also referred to as a program, software, software application, "app," or code) may include machine instructions for a programmable processor and may be implemented in a high-level procedural and / or object-oriented programming language and / or assembly / machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, cloud storage, Internet of Things, and / or device (e.g., magnetic disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. However, "machine-readable medium" and "computer-readable medium" do not include transitory signals. The term "machine-readable signal" refers to any signal that can be used to provide machine instructions and / or any other type of data to a programmable processor.
[0083] The above descriptions and illustrations of processes herein should not be construed as implying a fixed order for performing process steps. Rather, process steps may be performed in any order feasible, including simultaneous performance of at least some steps. Although the present disclosure has been described in conjunction with specific examples, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art may be made to the disclosed embodiments without departing from the spirit and scope of the present disclosure, as set forth in the appended claims.
Claims
1. 1. An apparatus comprising:
1. A processor, comprising: receiving acceleration values from a planning system associated with a vehicle and a state of the vehicle from a state estimation system; converting the acceleration value and the state of the vehicle into at least one of an engine torque value and a braking value via a control node; generating a control signal for controlling a speed of the vehicle based on the at least one of the engine torque value and the brake value; and an output configured to transmit the control signal to an actuator control system of the vehicle.
2. 2. The apparatus of claim 1, wherein the processor is configured to convert the acceleration value and the state of the vehicle into the engine torque value and generate the control signal for controlling an actuator of the vehicle to adjust the torque output of the engine based on the engine torque value.
3. 3. The apparatus of claim 2, wherein the output is configured to transmit the control signal to an engine control unit via a gateway interface configured to at least one of send a torque command directly to the engine and convert the engine torque value to a pedal position displacement value.
4. 2. The apparatus of claim 1, wherein the processor is configured to convert the acceleration value and the state of the vehicle into the braking value and generate a control signal to control an actuator of the vehicle to activate at least one of a service braking system and an engine retarder of the vehicle.
5. 2. The apparatus of claim 1, wherein the processor is configured to convert the acceleration value and the state of the vehicle into the braking value and generate a control signal for controlling an actuator of the vehicle to reduce acceleration of an engine of the vehicle based on the braking value.
6. 2. The apparatus of claim 1, wherein the conditions of the vehicle include one or more of the vehicle's current gear, transmission's current gear ratio, maximum available engine torque, maximum available retarder torque, and engine speed read from a system on the vehicle.
7. 2. The apparatus of claim 1, wherein the state of the vehicle includes one or more of a current mass of the vehicle, a current velocity of the vehicle, a current acceleration of the vehicle, a value based on drag and friction forces acting on the vehicle, a current pitch, and a wheel radius of a wheel on the vehicle, as estimated by an estimation node of the vehicle.
8. 2. The apparatus of claim 1, wherein the processor is configured to generate control forces based on the received acceleration values and the state of the vehicle, and to generate actuation commands including at least one of a brake pressure command, an engine brake command, an accelerator pedal position command, and an engine torque command based on at least an actuator model and the control forces.
9. The apparatus of claim 8 , wherein the processor is configured to output the actuation command to at least one of a brake unit, a transmission control unit, an engine control unit, and an engine retarder.
10. 1. A method comprising: receiving acceleration values from a planning system associated with a vehicle and a state of the vehicle from a state estimation system; converting the acceleration value and the state of the vehicle into at least one of an engine torque value and a braking value via a software control node; generating a control signal for controlling a speed of the vehicle based on the at least one of the engine torque value and the braking value; transmitting the control signal to an actuator control system of the vehicle.
11. 11. The method of claim 10, wherein the converting includes converting the acceleration value and the state of the vehicle to the engine torque value, and wherein the generating includes generating a control signal for controlling an actuator of the vehicle to adjust a torque output of an engine based on the engine torque value.
12. 12. The method of claim 11, wherein the transmitting comprises transmitting the control signal to an engine control unit via a gateway interface configured to at least one of send a torque command directly to the engine and convert the engine torque value to a pedal position displacement value.
13. 11. The method of claim 10, wherein the converting includes converting the acceleration value and the state of the vehicle to the braking value, and the generating includes generating a control signal for controlling an actuator of the vehicle to activate at least one of a service braking system and an engine retarder of the vehicle.
14. 11. The method of claim 10, wherein the converting comprises converting the acceleration value and the state of the vehicle into the braking value; and generating a control signal for controlling an actuator of the vehicle to reduce acceleration of an engine of the vehicle based on the braking value.
15. 11. The method of claim 10, wherein the conditions of the vehicle include one or more of the vehicle's current gear, transmission's current gear ratio, maximum available engine torque, maximum available retarder torque, and engine speed read from a system on the vehicle.
16. 11. The method of claim 10, wherein the state of the vehicle includes one or more of a current mass of the vehicle, a current velocity of the vehicle, a current acceleration of the vehicle, a value based on drag and friction forces acting on the vehicle, a current pitch, and a wheel radius of a wheel on the vehicle, as estimated by an estimation node of the vehicle.
17. 11. The method of claim 10, wherein said generating includes converting the acceleration values and the states of the vehicle into control forces, and wherein said generating includes generating actuation commands including at least one of a brake pressure command, an engine brake command, an accelerator pedal position command, and an engine torque command based on an actuator model and the control forces.
18. The method of claim 17 , wherein the transmitting comprises transmitting the actuation command to at least one of a brake control unit, a transmission control unit, an engine control unit, and an engine retarder.
19. A non-transitory computer-readable medium that, when executed by a processor, receiving acceleration values from a planning system associated with a vehicle and a state of the vehicle from a state estimation system; converting the acceleration value and the state of the vehicle into at least one of an engine torque value and a braking value via a software control node; generating a control signal for controlling a speed of the vehicle based on the at least one of the engine torque value and the braking value; and transmitting the control signal to an actuator control system of the vehicle.
20. 20. The non-transitory computer-readable medium of claim 19, wherein the converting includes converting the acceleration values and the states of the vehicle into control forces, and wherein the generating includes generating actuation commands including at least one of a brake pressure command, an engine brake command, an engine torque command, and an accelerator pedal position command based on an actuator model and the control forces.