Adaptive torque operating system and electric motor control apparatus

Abstract

An apparatus transforms vehicle operator intentions to wheel propulsion controls using an operator interface, sensors, a torque budgeting circuit, at least four motor controllers, and a vehicle/operator personality profile store. The store provides instructions and parameters which control dynamic vehicle responsiveness and reflect an operator's personality. The instructions and parameters are accessible by an application programming interface (API). Vehicle characteristics may be recorded by operating the vehicle through a prescribed route or evolution. A revised performance profile of a vehicle can be installed when the vehicle is reconfigured. Performance of a vehicle is modified to mimic a different vehicle by installing a new software dynamic performance profile. The API enables an open architecture for developers to customize vehicle dynamics without cutting metal.

Claims

1. An apparatus for transformation of vehicle operator intentions to wheel controller commands comprising: a vehicle control interface; a sensor reception interface (sensors); a vehicle/operator personality store (personality store); the personality store coupled to the vehicle control interface and to the sensors by an application programming interface (API); a torque budgeting circuit coupled to the API; and a motor controller interface coupled to the personality store by the API; wherein the sensors receive acceleration, yaw, speed, direction, vertical loading, traction and road condition measurements; wherein the personality store contains parameters accessible by an API to reflect an operator's skills in damping oscillations, reaction speed, observation acuity, muscularity, and hand-eye coordination; and wherein the torque budgeting circuit comprises a processor configured to determine a torque for each wheel to cause the vehicle to converge toward the driver intention as shaped by the personality store by instructions encoded in non-transitory medium in executable form.

2. The apparatus of claim 1 wherein the personality store further comprises computer-readable parameters encoded in non-transient media, accessible by the API to delay the application of torque to a first vehicle's actual or emulated performance characteristics and to add torque forces to simulate a second vehicle's responsiveness to yaw and acceleration intentions.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

(1) To further clarify the above and other advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof that are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

(2) FIG. 1 is a block diagram of a system; FIG. 2-5 are flowcharts of processes in a method of operation of the components of apparatuses of the system.

DETAILED DISCLOSURE OF EMBODIMENTS OF THE INVENTION

(3) In these embodiments, computing devices once embedded in this real-time closed loop control system, lose their generic capability for executing instructions other than continuously responding to physical measurements of indicia by setting electrical magnitudes and frequencies.

(4) One aspect of the invention is an apparatus for transformation of vehicle operator intentions to wheel controller commands comprising: a vehicle control interface (drivers); a sensor reception interface (sensors); a vehicle/driver personality profile store (personality store); the personality store coupled to the driver and the sensors by an application programming interface (API); a torque budgeting circuit coupled to the API; and a motor controller interface coupled to the personality store by the API.

(5) In an embodiment, the sensors receive acceleration, yaw, speed, direction, vertical loading, traction, and road condition measurements.

(6) In an embodiment, the drivers receives the operator's desired acceleration and vehicle yaw intentions.

(7) In an embodiment, the motor controller interface transmits commands for torque to each motor controller.

(8) In an embodiment, the torque budgeting circuit determines a torque for each wheel to cause the vehicle to converge toward the driver intention as shaped by the personality store.

(9) In an embodiment, the personality store contains parameters accessible by an API to reflect an operator's skills in damping oscillations, reaction speed, observation acuity, muscularity, and hand-eye coordination.

(10) In an embodiment, the personality store further contains parameters accessible by an API to delay the application of torque to the vehicle's actual or emulated performance characteristics and to add torque forces to simulate another vehicle's responsiveness to yaw and acceleration intentions.

(11) Instructions and parameters that control dynamic vehicle responsiveness and reflect an operator's personality are accessible by an application programming interface (API). In an embodiment torque controlled electric motors may be attached to non-wheel traction mechanisms such as fans, propellers, airscrews, caterpiller drives, paddles, and powered legs.

(12) DriveApps would be loaded either on the central computer (VCU) or a separate user-provided computer that couples to vehicle CANbus.

(13) DriveApp architecture allows multiple apps. Examples include: Sports car A tow trailer AWD ATV AWD SUV multiple-motor water or ice/snow vessel multiple-motor aircraft, and dual powered wheelchair or personal transporter.

(14) Referring to FIG. 1, a system 100 illustrates an embodiment wherein API calls are performed via sending a controller area network (CAN) command into the traction CANbus 200. CAN ID defines recipient of the command—each inverter also called an Adaptive Field-Oriented Controller (AF-OC) circuit 310-340 has a CAN ID, as does Vehicle Control Unit (VCU) apparatus 400 and Battery Management System (BMS) circuit 500. All other subsystems are controlled from within these modules (e.g., wheel #2 load actuator 322 is controlled from inverter #2 e.g. AF-OC-2, 320 etc.) A plurality of sensors 110-130 provide measurement packets of yaw 121, roll 122, attitude 123, acceleration 131, load 132, etc.

(15) Low-level (per-inverter) APIs include:

(16) a. setTorque(wheel, torque, duration_ms)

(17) i. requests torque output of <torque>N*m from <wheel> wheel for <duration_ms> milli-seconds

(18) ii. returns 0 on success, non-0 on error (error codes TBD)

(19) b. setSlipLevel(wheel, level)—sets level of aggressiveness of slip control (low=street car use, high=race track)

(20) c. getTorque(wheel)—return torque value actually delivered

(21) d. getLoad(wheel)—get wheel loading in Newtons

(22) e. getRPM(wheel)—get RPM of the wheel

(23) f. getSlipAngle(wheel)—get actual sleep angle

(24) Referring to FIG. 2 a method of operation 600 is illustrated that includes at a field oriented motor controller coupled to a network, receiving a set torque command 610 which specifies a wheel identifier, a value of target torque, and a duration wherein torque is in units of Newton*meters, and duration is in units of milliseconds; receiving a set slip level 620 as an acceptable percentage of rotation; determining a voltage magnitude and voltage frequency 631-634 for a motor; providing n-phase electric current at said voltage magnitude and voltage frequency 641-644; receiving slip and skid measurements 650 from the identified wheel; and returning success or error codes 690, which include the attainable torque at acceptable slip.

(25) Mid-level (traction system—level) APIs include measurements of Rate of change in vehicle position in 3-dimensional polar coordinates: getYawRate( )—get yaw rate in degrees/second from yaw sensor getRollRate( )—get roll rate in degrees/second from roll sensor getAttitudeRate( )—get attitude rate in degrees/second from attitude sensor getAccel( )—get vehicle acceleration in mm/s^2 (1 g=9,800 units) getLoad( )—get total vehicle weight (dynamic, can be different from weight at rest due to aerodynamic lift etc) get[max/min][params]( )—get min and max values of the parameters from the per-inverter level. Example: int getMaxSlipAngle( ) and, setAccel(accel)—request acceleration of the vehicle in mm/s^2 (can be positive or negative).

(26) Referring now to FIG. 3 a method 700 is illustrated for control of a vehicle by a processor performing the steps of a process including transmitting commands 710 and receiving measured or stored data 790. In an embodiment, each sensor responds when it is addressed. In an embodiment, all sensors having the requested data respond in order when no address is specified in the command. In embodiments the commands and resulting data including at least one of the following: getYawRate—get yaw rate in degrees/second from yaw sensor 711; getRollRate—get roll rate in degrees/second from roll sensor 712; getAttitudeRate—get attitude rate in degrees/second from attitude sensor 713; getAccel—get vehicle acceleration in mm/s^2 (1 g=9,800 units) 714; getLoad—get total vehicle weight (dynamic, can be different from weight at rest due to aerodynamic lift etc) 715; and get[max/min][params]( )—get min and max values of the parameters SlipAngle, Torque, SlipLevel, RPM, and Load 716.

(27) In an embodiment illustrated in FIG. 4, an operator control 110 transmits to a vehicle control unit 400 a command to setAccel(accel) 810—request acceleration of the vehicle in mm/s^2 (can be positive or negative). In an embodiment, an autonomous vehicle control system is coupled by an API to the vehicle control unit to request acceleration and vectored torque 850.

(28) High-level (car-level) API's includeBattery Management System (BMS) functions:

(29) i. getBattSOC( )—get state of charge of the battery in %

(30) ii. getBattAH( )—get remaining energy in the battery in AH (amp-hours)

(31) iii. getBattKWH( )—same in KWHrs

(32) iv. getBattV( )—get current battery voltage—used by VCU to predict maximum possible power band

(33) v. getBattIR( )—get current internal resistance of the battery—used by VCU to predict maximum possible power band and

(34) vi. getMaxBattPower( )—get max battery power in kW. Used in VCU (Vehicle Control Unit) to understand how much power is available to distribute into wheels.

(35) Referring to FIG. 5, a method 900 is illustrated for operating a vehicle by a processor in a vehicle control unit coupled by a network to a battery management system includes transmitting commands to read parameters including at least one of the following: to get maximum battery power in kW: getMaxBattPower 910; to get state of charge of the battery in percent: getBattSOC 920; to get remaining energy in the battery in ampere-hours: getBattAH 930; to get remaining energy in the battery in kilowatthours: getBattKWH 940: to get current battery voltage: getBattV 950; to get current measured internal resistance of the battery: getBattIR 960.

(36) A system for predictive torque budgeting receives traction estimates for impending road conditions. Traction measurements from previously recorded measurements can be retrieved using global positioning coordinates. Road geometry and incline is predicted from a stored 3D map. Traction measurements may be received from another vehicle in a peleton. Road conditions can be forecast from forward looking sensors on the vehicle itself. Wheel slip and wheel skid measured by a front wheel is transmitted to the adaptive field-oriented motor control of the tandem rear wheel. Wheel loading sensors and actuators provide direct feedback on attainable torque.

(37) In an embodiment, the system receives predicted yaw events from a map, gps system, user goggles or heads up display.

(38) Intelligent traction prediction engine—data sources: maps (curve ahead, etc) and GPS waypoints. GPS waypoints and prior experience on same route photo sensors before the front wheel to predict surface traction (camera looking out 1 foot ahead will give us 10 ms time at 60 mph to modulate front wheel) traction information from the front wheel fed into torque commands to the rear wheels (that will see the same part of pavement in ˜100 ms at 60 mph) wheel loading sensors & actuators (to actively manage instantaneous wheel loading)

(39) In an embodiment, a rear wheel AF-OC circuit adjusts its voltage magnitude and frequency magnitude output when a front wheel AF-OC circuit determines a target torque cannot be attained or sustained, or transmits substantially large slip data, skid data, or stability data.

(40) In an embodiment a torque budgeter circuit adjusts the target torque for rear wheel AF-OC circuits when at least one front wheel AF-OC circuit determines a target torque cannot be attained or sustained, or transmits substantially large slip data, skid data, or stability data.

(41) A method provides through an API, a process to adaptively control thrust instead of throttle and brake operation. The vehicle control unit receives acceleration requirements from the higher level autonomous systems and determines positive or negative torque for each electric motor driven wheel.

(42) It can be appreciated that the circuits may be implemented by processors using real time customized software closely coupled to physical measurements and resulting torque assignments in Newton meters transmitted to each motor controller. The physical manifestation of the invention is electric current magnitude or voltage magnitude and a poly-phase frequency or phase angle provided to a motor. Because of the dynamic nature of controlling a vehicle, the transformation method cannot be performed mentally or using manual computations.

(43) It is understood that circuits described above can be implemented as digital logic gates in a mask programmed standard cell or gate array. The circuits may equally be embodied in a programmable logic device depending on fuses or electrically erasable flash memory or firmware. The circuits may equally be embodied in Field Programmable Gate Arrays configured by non-transitory storage such as flash or read only memories (ROM). The circuits above may equally be embodied as processors adapted by instructions in non-transitory storage to perform the specific logic functions.

CONCLUSION

(44) Based on the traction prediction method, the apparatus provides target torque requests. The results include matching a rear wheel to its corresponding front wheel; placing more energy on the rear axle wheels and less on the front axle wheels for climbing, anticipating tighter cornering and providing positive torque to a left side or providing negative torque to a right side or vice versa or both. In some cases, negative torque is provided to one rear wheel while positive torque is provided to the diagonally opposite wheel. The system anticipates desired yaw moments for the route and road conditions.

(45) The claimed subject matter is easily distinguished from conventional vehicle performance characteristics by modifying through reading and writing parameters through an application programming interface the dynamic performance of the vehicle in response to user control, skills, and road conditions. Adjusting the behavior for towing or various loads can be done by installing an amended profile. Adapting the vehicle for a novice driver can be done as needed by downloading a plug-in.

(46) The techniques described herein can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The techniques can be implemented as an embedded microcontroller, i.e., firmware tangibly embodied in a non-transitory medium, e.g., in a machine-readable storage device, for execution by, or to control the operation of circuit apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and connected by a wireless network.

(47) Method steps of the techniques described herein can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). Modules can refer to portions of the computer program and/or the processor/special circuitry that implements that functionality.

(48) Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.

(49) The claimed subject matter is easily distinguished from conventional traction control by obtaining measurements from front wheels, sensors, telemetry from other vehicles, or stored measurements associated with global positioning coordinates instead of operator selection of modes.

(50) The claimed subject matter is easily distinguished from conventional autonomous vehicle systems by further sensing individual wheel slip and skid and budgeting torque for each motor controlling an individual wheel. A conventional autonomous vehicle depends on throttle control and braking actuators to provide positive or negative torque. The present invention provides an API interface between the navigation and environmental sensor system and the torque control system.

(51) A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, other network topologies may be used. Accordingly, other embodiments are within the scope of the following claims.