Electro-mechanical actuator with integrated fail-operational mechanism

Some embodiments relate to an electro-mechanical actuator that includes a screw, structurally segregated (split) housings, first and second nuts coupled to the screw, a sensor assembly, a plurality of motors, and a controller. The first nut is coupled to a first mounting point, and the second nut is coupled to a second mounting point. The sensor assembly may generate signals indicative of (e.g., relative) positions of left and right units of the actuator or positions of the first nut and the second nut on the screw. The controller controls the motors based on the signals generated by the sensor assembly. The motors may rotate each nut about a screw axis of the screw. This rotation results in one or both nuts moving along the screw. Movement between the first nut and the second nut along the screw adjusts a distance between the first mounting point and the second mounting point.

TECHNICAL FIELD

The present disclosure generally relates to actuators, and specifically relates to an electro-mechanical actuator with one or more integrated fail-operational mechanisms.

BACKGROUND

Vehicles (e.g., aircraft and cars) are increasingly moving toward fly-by wire operation in which mechanical aspects of the vehicle are controlled via actuators. In these situations, actuators may be evaluated according to high safety standards to prevent loss of life and damage to property in the event of an actuator failure.

DETAILED DESCRIPTION

Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

Configuration Overview

An actuator system may perform actuator operations between a first component and a second component. In some situations, the actuator system includes multiple actuators coupled to multiple mounting points. Thus, if one or more actuators experience a failure, the system can continue to actuate the components. However, in some situations, each component only has a single mounting point and the space around the mounting points is limited (e.g., it is only large enough for a single actuator). In these situations, a single actuator without multiple fail-operational mechanism may be insufficient to actuate the components. For example, if the actuator experiences a failure, the actuator may be unable to further actuate the components.

Thus, embodiments may relate to an electro-mechanical actuator (EMA) with multiple integrated fail-operational mechanisms. A fail-operational mechanism is a component (or group of components) that enables the EMA to continue to operate even though some portion or component of the EMA has experienced a failure event. Some of the EMAs described herein are linear actuators that control a distance between two mounting points (e.g., a vehicle mounting point and a control surface input point). For example, an EMA can move the mounting points closer together, move them farther apart, maintain a fixed distance, or some combination thereof. Due to the multiple integrated fail-operational mechanisms, the EMA may be the only actuator coupled the components and the EMA may be coupled to only two mounting points (one for each component).

For example, some embodiments relate to an EMA with a screw, a first nut and a second nut coupled to the screw, a sensor assembly, a first motor, a second motor, a backup motor, and a controller. The first nut is coupled to a first mounting point, and the second nut is coupled to a second mounting point. The sensor assembly is configured to generate signals indicative of positions of the first nut and the second nut on the screw. The first motor is configured to rotate the first nut about an axis of the screw. The second motor and the backup motor are each configured to rotate the second nut about the axis of the screw. Movement between the first nut and the second nut along the screw adjusts a distance between the first mounting point and the second mounting point. The controller is configured to control the first motor, the second motor, or the backup motor based on the signals generated by the sensor assembly.

Example System Environment

Figure (FIG.1illustrates one example embodiment of a vehicle control and interface system100. In the example embodiment shown, vehicle control and interface system100includes one or more universal vehicle control interfaces110, universal vehicle control router120, one or more vehicle actuators130, one or more vehicle sensors140, and one or more data stores150. In other embodiments, the vehicle control and interface system100may include different or additional elements. Furthermore, the functionality may be distributed among the elements in a different manner than described. The elements ofFIG.1may include one or more computers that communicate via a network or other suitable communication method.

The vehicle control and interface system100may be integrated with various vehicles having different mechanical, hardware, or software components. For example, the vehicle control and interface system100may be integrated with fixed-wing aircraft (e.g., airplanes), rotorcraft (e.g., helicopters), motor vehicles (e.g., automobiles), watercraft (e.g., power boats or submarines), or any other suitable vehicle. The vehicle control and interface system100is advantageously configured to receive inputs for requested operation of a particular vehicle via universal set of interfaces and the inputs to appropriate instructions for mechanical, hardware, or software components of the particular vehicle to achieve the requested operation. In doing so, the vehicle control and interface system100enables human operators to operate different vehicles using the same universal set of interfaces or inputs. By way of example, “universal” indicates that a feature of the vehicle control and interface system100may operate or be architected in a vehicle-agnostic manner. This allows for vehicle integration without necessarily having to design and configure vehicle specific customizations or reconfigurations in order to integrate the specific feature. Although universal features of the vehicle control and interface system100can function in a vehicle-agnostic manner, the universal features may still be configured for particular contexts. For example, the vehicle control or interface system100may receive or process inputs describing three-dimensional movements for vehicles that can move in three dimensions (e.g., aircraft) and conversely may receive or process inputs describing two-dimensional movements for vehicles that can move in two dimensions (e.g., automobiles). One skilled in the art will appreciate that other context-dependent configurations of universal features of the vehicle control and interface system100are possible.

The universal vehicle control interfaces110is a set of universal interfaces configured to receive a set of universal vehicle control inputs to the vehicle control and interface system100. The universal vehicle control interfaces110may include one or more digital user interfaces presented to an operator of a vehicle via one or more electronic displays. Additionally, or alternatively, the universal vehicle control interfaces110may include one or more hardware input devices, e.g., one or more control sticks inceptors, such as side sticks, center sticks, throttles, cyclic controllers, or collective controllers. The universal vehicle control interfaces110receive universal vehicle control inputs requesting operation of a vehicle. In particular, the inputs received by the universal vehicle control interfaces110may describe a requested trajectory of the vehicle, such as to change a velocity of the vehicle in one or more dimensions or to change an orientation of the vehicle. Because the universal vehicle control inputs describe an intended trajectory of a vehicle directly rather than describing vehicle-specific precursor values for achieving the intended trajectory, such as vehicle attitude inputs (e.g., power, lift, pitch, roll yaw), the universal vehicle control inputs can be used to universally describe a trajectory of any vehicle. This is in contrast to existing systems where control inputs are received as vehicle-specific trajectory precursor values that are specific to the particular vehicle. Advantageously, any individual interface of the set of universal vehicle control interfaces110configured to received universal vehicle control inputs can be used to completely control a trajectory of a vehicle. This is in contrast to conventional systems, where vehicle trajectory must be controlled using two or more interfaces or inceptors that correspond to different axes of movement or vehicle actuators. For instance, conventional rotorcraft systems include different cyclic (controlling pitch and roll), collective (controlling heave), and pedal (controlling yaw) inceptors. Similarly, conventional fixed-wing aircraft systems include different stick or yoke (controlling pitch and role), power (controlling forward movement), and pedal (controlling yaw) inceptors.

In various embodiments, inputs received by the universal vehicle control interfaces110can include “steady-hold” inputs, which may be configured to hold a parameter value fixed (e.g., remain in a departed position) without a continuous operator input. Such variants can enable hands-free operation, where discontinuous or discrete inputs can result in a fixed or continuous input. In a specific example, a user of the universal vehicle control interfaces110can provide an input (e.g., a speed input) and subsequently remove their hands with the input remaining fixed. Alternatively, or additionally, inputs received by the universal vehicle control interfaces110can include one or more self-centering or automatic return inputs, which return to a default state without a continuous user input.

In some embodiments, the universal vehicle control interfaces110include interfaces that provide feedback information to an operator of the vehicle. For instance, the universal vehicle control interfaces110may provide information describing a state of a vehicle integrated with the universal vehicle control interfaces110(e.g., current vehicle speed, direction, orientation, location, etc.). Additionally, or alternatively, the universal vehicle control interfaces110may provide information to facilitate navigation or other operations of a vehicle, such as visualizations of maps, terrain, or other environmental features around the vehicle.

The universal vehicle control router120routes universal vehicle control inputs describing operation of a vehicle to components of the vehicle suitable for executing the operation. In particular, the universal vehicle control router120receives universal vehicle control inputs describing the operation of the vehicle, processes the inputs using information describing characteristics of the aircraft, and outputs a corresponding set of commands for actuators of the vehicle (e.g., the vehicle actuators130) suitable to achieve the operation. The universal vehicle control router120may use various information describing characteristics of a vehicle in order to convert universal vehicle control inputs to a suitable set of commands for actuators of the vehicle. Additionally, or alternatively, the universal vehicle control router120may convert universal vehicle control inputs to a set of actuator commands using a set of control laws that enforce constraints (e.g., limits) on operations requested by the universal control inputs. For example, the set of control laws may include velocity limits (e.g., to prevent stalling in fixed-wing aircraft), acceleration limits, turning rate limits, engine power limits, rotor revolution per minute (RPM) limits, load power limits, allowable descent altitude limits, etc. After determining a set of actuator commands, the universal vehicle control router120may transmit the commands to relevant components of the vehicle for causing corresponding actuators to execute the commands.

The universal vehicle control router120can decouple axes of movement for a vehicle in order to process received universal vehicle control inputs. In particular, the universal vehicle control router120can process a received universal vehicle control input for one axis of movement without impacting other axes of movement such that the other axes of movement remain constant. In this way, the universal vehicle control router120can facilitate “steady-hold” vehicle control inputs, as described above with reference to the universal vehicle control interfaces110. This is in contrast to conventional systems, where a vehicle operator must manually coordinate all axes of movement independently for a vehicle in order to produce movement in one axis (e.g., a pure turn, a pure altitude climb, a pure forward acceleration, etc.) without affecting the other axes of movement.

In some embodiments, the universal vehicle control router120is configured to use one or more models corresponding to a particular vehicle to convert universal vehicle control inputs to a suitable set of commands for actuators of the vehicle. For example, a model may include a set of parameters (e.g., numerical values) that can be used as input to universal input conversion processes in order to generate actuator commands suitable for a particular vehicle. In this way, the universal vehicle control router120can be integrated with vehicles by substituting models used by processes of the universal vehicle control router120, enabling efficient integration of the vehicle control and interface system100with different vehicles. The one or more models may be obtained by the universal vehicle control router120from a vehicle model database or other first-party or third-party system, e.g., via a network. In some cases, the one or more models may be static after integration with the vehicle control and interface system100, such as if a vehicle integrated with the vehicle control and interface system100receives is certified for operation by a certifying authority (e.g., the United States Federal Aviation Administration). In some embodiments, parameters of the one or more models are determined by measuring data during real or simulated operation of a corresponding vehicle and fitting the measured data to the one or more models.

In some embodiments, the universal vehicle control router120processes universal vehicle control inputs according to a current phase of operation of the vehicle. For instance, if the vehicle is a rotorcraft, the universal vehicle control router120may convert a universal input describing an increase in lateral speed to one or more actuator commands differently if the rotorcraft is in a hover phase or in a forward flight phase. In particular, in processing the lateral speed increase universal input the universal vehicle control router120may generate actuator commands causing the rotorcraft to strafe if the rotorcraft is hovering and causing the rotorcraft to turn if the rotorcraft is in forward flight. As another example, in processing a turn speed increase universal input the universal vehicle control router120may generate actuator commands causing the rotorcraft to perform a pedal turn if the rotorcraft is hovering and ignore the turn speed increase universal input if the rotorcraft is in another phase of operation. As a similar example for a fixed-wing aircraft, in processing a turn speed increase universal input the universal vehicle control router120may generate actuator commands causing the fixed-wing aircraft to perform tight ground turn if the fixed-wing aircraft is grounded and ignore the turn speed increase universal input if the fixed-wing aircraft is in another phase of operation. One skilled in the art will appreciate that the universal vehicle control router120may perform other suitable processing of universal vehicle control inputs to generate actuator commands in consideration of vehicle operation phases for various vehicles.

The vehicle actuators130are one or more actuators configured to control components of a vehicle integrated with the universal vehicle control interfaces110. For instance, the vehicle actuators may include actuators for controlling a power-plant of the vehicle (e.g., an engine). Furthermore, the vehicle actuators130may vary depending on the particular vehicle. For example, if the vehicle is a rotorcraft the vehicle actuators130may include actuators for controlling lateral cyclic, longitudinal cyclic, collective, and pedal controllers of the rotorcraft. As another example, if the vehicle is a fixed-wing aircraft the vehicle actuators130may include actuators for controlling a rudder, elevator, ailerons, and power-plant of the fixed-wing aircraft. Example actuators130are further described with reference toFIGS.3A-6.

The vehicle sensors140are sensors configured to capture corresponding sensor data. In various embodiments the vehicle sensors140may include, for example, one or more global positioning system (GPS) receivers, inertial measurement units (IMUs), accelerometers, gyroscopes, magnometers, pressure sensors (altimeters, static tubes, pitot tubes, etc.), temperature sensors, vane sensors, range sensors (e.g., laser altimeters, radar altimeters, lidars, radars, ultrasonic range sensors, etc.), terrain elevation data, geographic data, airport or landing zone data, rotor revolutions per minute (RPM) sensors, manifold pressure sensors, or other suitable sensors. In some cases, the vehicle sensors140may include, for example, redundant sensor channels for some or all of the vehicle sensors140. The vehicle control and interface system100may use data captured by the vehicle sensors140for various processes. By way of example, the universal vehicle control router120may use vehicle sensor data captured by the vehicle sensors140to determine an estimated state of the vehicle.

The data store150is a database storing various data for the vehicle control and interface system100. For instance, the data store150may store sensor data (e.g., captured by the vehicle sensors140), vehicle models, vehicle metadata, or any other suitable data.

FIG.2illustrates one example embodiment of a configuration200for a set of universal vehicle control interfaces in a vehicle. The vehicle control interfaces in the configuration200may be embodiments of the universal vehicle control interfaces110, as described above with reference toFIG.1. In the embodiment shown, the configuration200includes a vehicle state display210, a side-stick inceptor device240, and a vehicle operator field of view250. In other embodiments, the configuration200may include different or additional elements. Furthermore, the functionality may be distributed among the elements in a different manner than described.

The vehicle state display210is one or more electronic displays (e.g., liquid-crystal displays (LCDs) configured to display or receive information describing a state of the vehicle including the configuration200. In particular, the vehicle state display210may display various interfaces including feedback information for an operator of the vehicle. In this case, the vehicle state display210may provide feedback information to the operator in the form of virtual maps, 3D terrain visualizations (e.g., wireframe, rendering, environment skin, etc.), traffic, weather, engine status, communication data (e.g., air traffic control (ATC) communication), guidance information (e.g., guidance parameters, trajectory), and any other pertinent information. Additionally, or alternatively, the vehicle state display210may display various interfaces for configuring or executing automated vehicle control processes, such as automated aircraft landing or takeoff or navigation to a target location. The vehicle state display210may receive user inputs via various mechanisms, such as gesture inputs (as described above with reference to the gesture interface220), audio inputs, or any other suitable input mechanism.

As depicted inFIG.2the vehicle state display210includes a primary vehicle control interface220and a multi-function interface230. The primary vehicle control interface220is configured to facilitate short-term of the vehicle including the configuration200. In particular, the primary vehicle control interface220includes information immediately relevant to control of the vehicle, such as current universal control input values or a current state of the vehicle. As an example, the primary vehicle control interface220may include a virtual object representing the vehicle in 3D or 2D space. In this case, the primary vehicle control interface220may adjust the display of the virtual object responsive to operations performed by the vehicle in order to provide an operator of the vehicle with visual feedback. The primary vehicle control interface220may additionally, or alternatively, receive universal vehicle control inputs via gesture inputs.

The multi-function interface230is configured to facilitate long-term control of the vehicle including the configuration200. In particular, the primary vehicle control interface220may include information describing a mission for the vehicle (e.g., navigation to a target destination) or information describing the vehicle systems. Information describing the mission may include routing information, mapping information, or other suitable information. Information describing the vehicle systems may include engine health status, engine power utilization, fuel, lights, vehicle environment, or other suitable information. In some embodiments, the multi-function interface230or other interfaces enable mission planning for operation of a vehicle. For example, the multi-function interface230may enable configuring missions for navigating a vehicle from a start location to a target location. In some cases, the multi-function interface230or another interface provides access to a marketplace of applications and services. The multi-function interface230may also include a map, a radio tuner, or a variety of other controls and system functions for the vehicle.

In some embodiments, the vehicle state display210includes information describing a current state of the vehicle relative to one or more control limits of the vehicle (e.g., on the primary vehicle control interface220or the multi-function interface230). For example, the information may describe power limits of the vehicle or include information indicating how much control authority a use has across each axis of movement for the vehicle (e.g., available speed, turning ability, climb or descent ability for an aircraft, etc.). In the same or different example embodiments, the vehicle state display210may display different information depending on a level of experience of a human operator of the vehicle. For instance, if the vehicle is an aircraft and the human operator is new to flying, the vehicle state display may include information indicating a difficulty rating for available flight paths (e.g., beginner, intermediate, or expert). The particular experience level determined for an operator may be based upon prior data collected and analyzed about the human operator corresponding to their prior experiences in flying with flight paths having similar expected parameters. Additionally, or alternatively, flight path difficulty ratings for available flight paths provided to the human operator may be determined based on various information, for example, expected traffic, terrain fluctuations, airspace traffic and traffic type, how many airspaces and air traffic controllers along the way, or various other factors or variables that are projected for a particular flight path. Moreover, the data collected from execution of this flight path can be fed back into the database and applied to a machine learning model to generate additional and/or refined ratings data for the operator for subsequent application to other flight paths. Vehicle operations may further be filtered according to which one is the fastest, the most fuel efficient, or the most scenic, etc.

The one or more vehicle state displays210may include one or more electronic displays (e.g., liquid-crystal displays (LCDs), organic light emitting diodes (OLED), plasma). For example, the vehicle state display210may include a first electronic display for the primary vehicle control interface220and a second electronic display for the multi-function interface230. In cases where the vehicle state display210include multiple electronic displays, the vehicle state display210may be configured to adjust interfaces displayed using the multiple electronic displays, e.g., in response to failure of one of the electronic displays. For example, if an electronic display rendering the primary vehicle control interface220fails, the vehicle state display210may display some or all of the primary vehicle control interface220on another electronic display.

The one or more electronic displays of the vehicle state display210may be touch sensitive displays is configured to receive touch inputs from an operator of the vehicle including the configuration200, such as a multi-touch display. For instance, the primary vehicle control interface220may be a gesture interface configured to receive universal vehicle control inputs for controlling the vehicle including the configuration200via touch gesture inputs. In some cases, the one or more electronic displays may receive inputs via other type of gestures, such as gestures received via an optical mouse, roller wheel, three-dimensional (3D) mouse, motion tracking device (e.g., optical tracking), or any other suitable device for receiving gesture inputs.

Touch gesture inputs received by one or more electronic displays of the vehicle state display210may include single finger gestures (e.g., executing a predetermined pattern, swipe, slide, etc.), multi-finger gestures (e.g., 2, 3, 4, 5 fingers, but also palm, multi-hand, including/excluding thumb, etc.; same or different motion as single finger gestures), pattern gestures (e.g., circle, twist, convergence, divergence, multi-finger bifurcating swipe, etc.), or any other suitable gesture inputs. Gesture inputs can be limited asynchronous inputs (e.g., single input at a time) or can allow for multiple concurrent or synchronous inputs. In variants, gesture input axes can be fully decoupled or independent. In a specific example, requesting a speed change holds other universal vehicle control input parameters fixed—where vehicle control can be automatically adjusted in order to implement the speed change while holding heading and vertical rate fixed. Alternatively, gesture axes can include one or more mutual dependencies with other control axes. Unlike conventional vehicle control systems, such as aircraft control systems, the gesture input configuration as disclosed provides for more intuitive user experiences with respect to an interface to control vehicle movement.

In some embodiments, the vehicle state display210or other interfaces are configured to adjust in response to vehicle operation events, such as emergency conditions. For instance, in response to determining the vehicle is in an emergency condition, the vehicle control and interface system100may adjust the vehicle state display210to include essential information or remove irrelevant information. As an example, if the vehicle is an aircraft and the vehicle control and interface system100detects an engine failure for the aircraft, the vehicle control and interface system100may display essential information on the vehicle state display210including 1) a direction of the wind, 2) an available glide range for the aircraft (e.g., a distance that the aircraft can glide given current conditions), or 3) available emergency landing spots within the glide range. The vehicle control and interface system100may identify emergency landing locations using various processes, such as by accessing a database of landing spots (e.g., included in the data store150or a remote database) or ranking landing spots according to their suitability for an emergency landing.

The side-stick inceptor device240may be a side-stick inceptor configured to receive universal vehicle control inputs. In particular, the side-stick inceptor device240may be configured to receive the same or similar universal vehicle control inputs as a gesture interface of the vehicle state display210is configured to receive. In this case, the gesture interface and the side-stick inceptor device240may provide redundant or semi-redundant interfaces to a human operator for providing universal vehicle control inputs. The side-stick inceptor device240may be active or passive. Additionally, the side-stick inceptor device240and may include force feedback mechanisms along any suitable axis. For instance, the side-stick inceptor device240may be a 3-axis inceptor, 4-axis inceptor (e.g., with a thumb wheel), or any other suitable inceptor.

The components of the configuration200may be integrated with the vehicle including the configuration200using various mechanical or electrical components. These components may enable adjustment of one or more interfaces of the configuration200for operation by a human operator of the vehicle. For example, these components may enable rotation or translation of the vehicle state display210toward or away from a position of the human operator (e.g., a seat where the human operator sits). Such adjustment may be intended, for example, to prevent the interfaces of the configuration200from obscuring a line of sight of the human operator to the vehicle operator field of view250.

The vehicle operator field of view250is a first-person field of view of the human operator of the vehicle including the configuration200. For example, the vehicle operator field of view250may be a windshield of the vehicle or other suitable device for enabling a first-person view for a human operator.

The configuration200additionally or alternately include other auxiliary feedback mechanisms, which can be auditory (e.g., alarms, buzzers, etc.), haptic (e.g., shakers, haptic alert mechanisms, etc.), visual (e.g., lights, display cues, etc.), or any other suitable feedback components. Furthermore, displays of the configuration200(e.g., the vehicle state display210) can simultaneously or asynchronously function as one or more of different types of interfaces, such as an interface for receiving vehicle control inputs, an interface for displaying navigation information, an interface for providing alerts or notifications to an operator of the vehicle, or any other suitable vehicle instrumentation. Furthermore, portions of the information can be shared between multiple displays or configurable between multiple displays.

FIG.3Ais a side view of an electro-mechanical actuator300, according to one or more embodiments. The actuator300may be a vehicle actuator130as described above. For example, the actuator300actuates a portion of a vehicle responsive to an input from the primary vehicle control interface220. Components of the actuator300, such as ball nuts and motors, are contained in housings306A and306B and illustrated in subsequent figures. A left unit321A of the actuator300is coupled to a first mounting point311A and a right unit321B is coupled to a second mounting point311B (e.g., a vehicle mounting point and a control surface input point). The left unit321A and the right unit321B are coupled together by a ballscrew317and separated by distance325.

FIG.3Bis a side view of the actuator300(similar toFIG.3A), except the left unit321A and the right unit321B are separated by a larger distance325. As previously stated, the actuator300(e.g., via a controller module) may control the distance325between the mounting points311. For example,FIG.3Aillustrates a situation where the mounting points311are close together andFIG.3Billustrates a situation where the mounting points311are farther apart. Actuation may occur by each unit321A,321B moving along the ballscrew317. The units of the actuator300may operate independently. Thus, for example, if one of the units (e.g.,321A) experiences a failure, the other unit (e.g.,321B) may continue to move along the ballscrew317to keep the actuator functional. If both units are operational, the actuation rate may be double the actuation rate of an actuator with only a single unit (depending on the actuation rate of each unit321A,321B).

FIG.4Ais a block diagram of a cross sectional view of an actuator400, according to one or more embodiments. The actuator300may be an embodiment of the actuator400.FIG.4Aincludes a ballscrew417, a cavity419, a first ball nut415A, a second ball nut415B, a sensor assembly420, a first motor405A, a second motor405B, a backup motor405C, a first brake410A, a second brake410B, a third brake410C, an end stop425, a protrusion430, multiple stops440, a first inverted nut435A, a second inverted nut435B, and a controller445. The actuator may include additional, fewer, or different components than illustrated. For simplicity, this disclosure describes the actuator400as including a ballscrew417and ball nuts415A,415B. However, the actuator400may include other screw and nut types, such as ACME screws or roller screws (and their corresponding nuts).

Actuator400may include gears coupled to the ball nuts415. Motor pinions of the motors405may engage with the gears to rotate the ball nuts415. Example gear418is labeled inFIG.4A. Actuator400may include brake discs coupled to the ball nuts415or the inverted nuts435. The brake discs may have notches that allow the brakes410to engage with the discs. Example brake disc419is labeled inFIG.4A.

In some embodiments, each housing406includes a two or more load paths. Thus, in the event of one of the housings (e.g.,406A) experiencing a failure (e.g., a rupture), the two or more load paths may ensure that the failure does not cause a loss of pin-to-pin structural integrity. Two (or more) load paths may be implemented by each housing (e.g.,406A and406B) including two (or more) portions coupled together (e.g., a top half coupled to a bottom half). Thus, for example, a fracture in one of the portions, will not propagate through the entire housing (e.g., and cause loss of control of the mounting points411,411B). This may be important for applications in which the actuator is the only actuator for each control surface (e.g., coupled to the mounting points411A,411B). Each housing may also include a clevis (used for coupling to the mounting points411A,411B) made of a structure separate from the two or more portions. In some embodiments, if the actuator.

The ballscrew417is a rod with helical grooves (e.g., threads). The length of the ballscrew may be based on a target range of actuation for the two (e.g., vehicle) mounting points411. Design parameters of the ballscrew may include length, load, torque, thread pitch, thickness, and material type (e.g., stainless steel). Values of the design parameters may be based on resolution of actuation, load, speed of movement, weight, and chance of failure. In some embodiments, the length of the ballscrew417is at least twice the target range of actuation. Thus, if one unit (e.g.,421B) experiences a failure (e.g., one of the nuts becomes jammed), the other unit (e.g.,421A) may still have enough range of movement along the ballscrew417to keep the actuator400functional (e.g., across a required operating stroke).

In some embodiments, the ballscrew417includes a rod. The rod may provide a secondary load path for the ballscrew417. For example, in the event of the ballscrew417experiencing a failure event, the rod may carry tensile and torsional loads between the ends of the ballscrew417. The ballscrew417may be hollow and the rod may fit inside the hollow ballscrew417and be long enough to couple to both ends of the ballscrew417. In some embodiments, the ballscrew417, ball nuts415A,415B, rod, stops440and end stops425are made of metal, such as stainless steel.

The first ball nut415A and the second ball nut415B are coupled to the ballscrew417and are configured to rotate about the ballscrew417(about axis447). The first ball nut415A and the second ball nut415B are collectively referred to as ball nuts415. The ball nuts415may have helical grooves (e.g., threads) that match or correspond to the helical grooves of the ballscrew417. Balls roll between the grooves to provide contact between a ball nut and the ballscrew417. The ball nuts415may include seals at one or both ends to prevent contamination ingress and for lubrication retention. In some embodiments, a ball nut (e.g.,415A) is a multi-circuit ball nut.

The motors405enable multiple drive channels to control the actuator400(motors405A-C are collectively referred to as motors405). For example, if a single drive channel fails, one or more of the remaining channels may be used to control the actuator400. One or more of the motors405may be a brushless DC motor, a synchronous reluctance motor, or a brush DC motor. Among other advantages, a brushless motor may result in less motor wear compared to brush motors. The motors405are configured to rotate the ball nuts415about the axis447of the ballscrew417(e.g., via a geared drive interface). Rotating a ball nut (e.g.,415A) about the ballscrew417results in the ball nut moving along the length of the ballscrew417. Thus, the motors405may rotate the ball nuts415in either direction (e.g., clockwise or counterclockwise) about axis447in order to move the ball nuts415in either direction along the length of the ballscrew417. The motors405may each generate signals that indicate the position of a corresponding ball nut (e.g.,415A or415B) on the ballscrew417. For example, a motor (e.g.,405A) may track the number of rotations of a ball nut (e.g.,415A) about the ballscrew417.

In the example ofFIG.4A, the first motor405A is contained in the first housing406A and is configured to rotate the first ball nut415A. The second motor405B is contained in the second housing406B and is configured to rotate the second ball nut415B. Movement of the first ball nut415A along the ballscrew417, movement of the second ball nut415B along the ballscrew, or movement of both the first ball nut415A and the second ball nut415B along the ballscrew417may adjust a distance between the mounting points411A,411B. In this manner, the actuator400may convert rotation of the ball nuts415into a linear actuation.

Although not illustrated inFIG.4A, the motors405may each include motor control electronics (“MCE”) that control the motor. For example, the controller module445controls the motors405by sending control signals to the MCE of each motor.

The example ofFIG.4Aincludes a backup motor405C for the second motor405B. Generally, the actuator400may include one or more backup motors in the first housing406A, the second housing406B, or both the first and second housings406A,406B. Each backup motor in an actuator (e.g.,400) may be configured to back up a respective motor that is coupled to the backup motor. Thus, in the example ofFIG.4A, if motor405B fails, the backup motor405C can rotate the corresponding second ball nut415B instead, thereby providing a fail-operational mechanism. Additionally, or alternatively, a backup motor may be used to assist a corresponding functional motor for difficult actuation tasks (e.g., add additional power, torque, etc.). For example, backup motor405C may assist motor405B for a difficult actuation task.

In some embodiments, the controller445is configured to determine if a motor has failed, identify one or more backup motors associated with the failed motor, and then use the identified one or more backup motors to adjust the distance between the mounting points411A,411B. If the controller445determines that the failed motor doesn't have a backup motor associated with it, the controller445may instruct the failed motor to stop and may instruct another motor (e.g., on an opposite unit) to adjust the distance between the mounting points411A,411B. In some embodiments, the controller445may follow instructions that don't require the controller445to identify a backup motor or determine whether a failed motor has a backup motor. For example, the controller445may follow instructions that instruct the controller445to use the backup motor405C responsive to the second motor405B failing and that instruct the controller445to use the second motor405B or the backup motor405C responsive to the first motor405A failing.

Each housing406A,406B may form a ballscrew cavity (e.g.,419) that allows the ballscrew417to move within the housing (e.g., when a motor rotates a nut). For example, as the first motor405A rotates the first ball nut415A, the end of the ballscrew417moves toward or away from mounting point411A in ballscrew cavity419(depending on the rotation of the nut).

An end stop425is coupled to the end of the ballscrew417and is configured to prevent (or reduce) the ballscrew417from rotating about ballscrew axis447. Thus, the end stop425may be referred to as an anti-rotation feature.

The end stop425includes a protrusion430that extends away from the ballscrew axis447and into a groove formed by the inner wall of the ballscrew cavity419. The groove may run along the ballscrew cavity419. As the ballscrew417moves in the ballscrew cavity419, the protrusion430slides along the groove and may prevent the ballscrew417from rotating about ballscrew axis447. The end stop425may include multiple protrusions that fit into one or more grooves in the ballscrew cavity419(e.g., to reinforce the first protrusion430). Additional details about the groove are described with respect toFIG.4B.

The sensor assembly420is configured to monitor positions of the first ball nut415A and the second ball nut415B. The sensor assembly420includes one or more sensors that generate signals indicative of positions (or changes in positions) of the first ball nut415A or the second ball nut415B on the ballscrew417. A sensor may generate signals by interacting directly or indirectly with one or both ball nuts415or a component coupled to one or both ball nuts415.

The sensor assembly420may include one or more sensors that measures the relative position of one ball nut (e.g.,415A) relative to another ball nut (e.g.,415B). For example, the sensor may measure the distance (e.g., axial separation) between the ball nuts415along the ballscrew. Example relative sensors include a linear variable displacement transducer (LVDT), a potentiometer, or an absolute magnetic encoder. In the example ofFIG.4A, the sensor assembly420includes a LVDT sensor coupled to both the first housing406A and the second housing406B.

The sensor assembly420may include one or more sensors that measures the position of a ball nut (e.g.,415A) relative to the ballscrew417. For example, the sensor generates signals that indicate the amount of rotation of a ball nut (e.g., the total number of clockwise rotations of the ball nut about the ballscrew417). In some embodiments, one or more sensors of the sensor assembly420sense movement (e.g., rotation) of a gear (e.g.,418) or a brake disc (e.g.,419) to generate signals. Example sensors include a proximity sensor, a resolver, an absolute optical encoder, or a rotary magnetic encoder.

Multiple sensors may be used in combination to monitor positions of the ball nuts415. For example, a LVDT may be positioned in the second housing406B and coupled to the first housing406A (e.g., as illustrated inFIG.4A) to monitor a distance between the first housing406A and the second housing406B. Additionally, a magnetic or optical encoder may be used in each housing406A,406B to monitor revolutions of each ball nut415A,415B. Note that a resulting distance between the two attachment points is a result of motion of the ball nut415A and the ball nut415B. An overall distance may be derived from nut rotations (rather than relative positions of the housing) by summing the motion caused by rotation of ball nut415A to motion caused by rotation of ball nut415B.

In the example ofFIG.4A, the actuator400includes a first inverted nut435A in housing406A and coupled to the first ball nut415A and a second inverted nut435B in housing406B and coupled to the second ball nut415B. The first inverted nut435A and the second inverted nut435B may be collectively referred to as inverted nuts435. An inverted nut (e.g.,435A) may be coupled to a ball nut (e.g.,415A) such that the inverted nut rotates with the ball nut. In some embodiments, an inverted nut is like a regular nut that mates with a regular screw except that the thread form of an inverted nut matches the thread profile of the ballscrew417with some clearance. An inverted nut may be made of metal, such as aluminum-nickel-bronze, stainless steel, beryllium copper, etc. The inverted nuts435may include features that act as mechanical stops between the ball nuts415and may limit movement of the ball nuts415along the ballscrew417. Thus, the inverted nuts435may prevent the ball nuts415from (e.g., unintentionally) impacting each other as the ball nuts415move along the ballscrew417. In some embodiments, the purpose of an inverted nut (e.g.,435A) is to provide a redundant load path in the event of a ball nut failure. For example, if a ball nut fails structurally (e.g., all the balls fall out), the inverted nut may keep the ballscrew417connected to the bearings and the housing. An inverted nut (e.g.,435A) may include a seal at one or both ends to prevent contamination ingress and for lubrication retention.

In some embodiments, an actuator (e.g.,400) includes a stop440coupled to an outer end of a ball nut (e.g.,415A) and an end stop425coupled to an end of the ballscrew417. These components may act as mechanical stops similar to the inverted nuts435. Thus, an end stop425and stop440pair may prevent a ball nut (e.g.,415A) from sliding off of the end of the ballscrew417(e.g., in a situation where a motor (e.g.,405A) or the controller445lose track of the position of the ball nut).

In some embodiments, an actuator (e.g.,400) includes one or more brakes410(brakes410A-C may be collectively referred to as brakes410). In the example ofFIG.4A, the actuator400includes a brake for each motor. Each brake is coupled to a corresponding ball nut (e.g., via an inverted nut). In the example ofFIG.4A, first brake410A is coupled to the first ball nut415A and second brake410B and third brake410C are coupled to the second ball nut415B. When a brake (e.g.,410A) is engaged, it may prevent the corresponding ball nut (e.g.,415A) from rotating about the ballscrew417. Thus, if a motor (or another component) experiences a failure (e.g., loses power or motor runaway), the brake may prevent the corresponding ball nut from moving along the ballscrew (e.g., in an uncontrolled manner). Bakes may also be part of a secondary load path. In the event of certain failure events, such as a motor shaft fracture, a gear failure, or a bearing failure, a brake may provide a secondary means to prevent ball nut rotation. Otherwise under loads, the ball nut may be back-driven.

The controller module445controls components of the actuator400. In some embodiments, the controller445is a universal vehicle control router120. In the example ofFIG.4A, the controller445is in the second housing406B. However, this is not required. The controller445may be in the first housing406A, both housings, or in neither of the housings. Additionally, the controller445may be located at a different place in the second housing406B. The controller445may be a single module or it may include multiple modules (e.g., distributed in the left and right units421A,421B). A controller445with multiple modules may prevent a failure event from disabling all actuator control channels. The controller445may receive an input (e.g., instructions) to actuate the actuator400(e.g., from a vehicle control system, a universal vehicle control interface110, or a universal vehicle control router120). The input may specify actuation parameters (e.g., an amount of actuation, a rate of actuation, or a time to begin or end actuation). Additionally, or alternatively, the controller445may determine the actuation parameters based on the input. After the actuation parameters are determined, the controller445may instruct a motor (e.g.,405A) to move a ball nut (e.g.,415A) along the ballscrew417according to the parameters. The controller445may instruct one or more motors405to achieve a target actuation. For example, the controller445instructs the first motor405A and the second motors405B such that the first ball nut415A and the second ball nut415B simultaneously move away from each other (increasing a distance between the mounting points411A,411B) or move toward each other (decreasing a distance between the mounting points411A,411B) along the ballscrew417.

The controller445may control the motors405based on the signals received from the sensor assembly420(e.g., in addition to the input). For example, the controller445may use signals from the sensor assembly420to (1) determine the positions (or changes in position) of the first ball nut415A and the second ball nut415B on the ballscrew417and (2) adjust the distance between the first ball nut415A and the second ball nut415B based on the determined positions. In some embodiments, signals from the sensor assembly420may be additionally monitored by a second controller (e.g., located in a different housing). For example, the controller445and a second controller both monitor signals from the sensor assembly420in order to provide independent checks and monitoring.

As previously described, the motors405may provide signals indicative of positions (or changes in positions) of the ball nuts415. Thus, the controller445may determine ball nut positions based on signals from one or more of the motors405and may provide control instructions to one or more of the motors405based on these positions. For example, the controller445may track the number of rotations of the ball nuts415about the ballscrew417based on signals from the motors405. However, it may be advantageous to provide a fail-operational mechanism. For example, the motor signals may be unreliable, inaccurate, or prone to errors (e.g., a motor signal doesn't indicate motor runaway). Thus, signals from the sensor assembly420may be used to check or in conjunction with the motor signals to determine positions of the ball nuts415. For example, the controller445may compare (1) position determinations based on the motor signals with (2) position determinations based on the sensor assembly signals to determine positions of the ball nuts415. If the results of (1) and (2) diverge, then the channel (e.g., a controller, a motor, and a motor position feedback sensor) may be disabled by the controller445, and one or more of the other channels may take over. In some embodiments, signals from the motors405are not used to determine positions of the ball nuts415(e.g., the controller445only uses signals from the sensor assembly420to determine positions of the ball nuts415). In some embodiments, motor signals are used for motor power commutation and signals from the sensor assembly420are used to track the ball nut positions.

The controller445may use signals from the sensor assembly420or signals from the motors405to determine if a failure event (e.g., malfunction) occurred. A failure event occurs when a component ceases to function, the component malfunctions, or the component's functionality is reduced below a predetermined threshold. An example failure is a jam between a ball nut (e.g.,415A) and the ballscrew417that prevents movement of the ball nut along the ballscrew417. Another example failure is a motor (e.g.,405A) losing count of the number of ball nut rotations about the ballscrew417. Another example failure is a motor (e.g.,405A) breaking down and being unable to rotate a ball nut (e.g.,415A).

After determining a failure event occurred, the controller445may control one or more of the motors405based on the failure event. For example, in cases where a failure results in a first unit (e.g., the left unit421A) becoming inoperative (e.g., a ball nut becomes jammed or a motor without a backup motor fails), the brake on the failed side may be engaged and the remaining unit (e.g., the right unit421B) may still be able to fully actuate the actuator400. However, if one unit is inoperative, the rate of actuation may be less (e.g., half) that of the rate of actuation when both units are operating correctly (depending on the rate of actuation of each unit). Or if each channel can drive an actuator (e.g.,400) at full rate, failures do not affect rate until all channels fail. In this manner, the two units421A,421B allow redundancy and are a fail-operational mechanism. In this context, ‘fully actuate’ refers to the ability to actuate at least to a target (e.g., threshold) range of actuation between the two mounting points411A,411B.

To ensure that both units421A,421B can fully actuate the actuator400, the controller445may control the motors405so that the first ball nut415A remains along on a first portion of the ballscrew417(e.g., a first half) and so that the second nut415B remains along a second different portion of the ballscrew417(e.g., a second half). Thus, if one of the units experiences a failure such that it can no longer move along the ballscrew417, the remaining unit may still have access to enough of the ballscrew417to fully actuate the actuator400.

In cases where a motor failure occurs but a backup motor (e.g.,405C) is present, the controller445may determine the motor (e.g.,405B) has failed and instruct the backup motor (e.g.,405C) to take over operation of the failed motor (e.g.,405B). In this case, the controller445may also instruct the failed motor (e.g.,405B) to stop operating or to stop rotating a corresponding ball nut (e.g.,415B).

In some embodiments, if/when a motor (e.g.,405A) experiences a failure event, the controller445may reset the motor. For example, the controller445may turn off and turn on the motor. In another example, the controller445resets parameters of the motor. In another example, if the motor experiences motor runaway, the controller445may use signals from the sensor assembly420to inform the motor of its correct position on the ballscrew417. Thus, resetting a motor (e.g., with the help of the sensor assembly420) is another fail-operational mechanism of the actuator400. If a motor reset does not fix the failure event (or a similar failure event occurs within a threshold time after the reset), the controller445may instruct the motor to stop rotating the corresponding ball nut and may instruct a backup motor to rotate the ball nut (assuming a backup motor is present).

Accordingly, an actuator (e.g.,400) may include a plurality of fail-operational mechanisms that may allow the actuator to continue operating even if one or more failure events occur. Due to the fail-operational mechanisms, the actuator (e.g.,400) may be the only actuator coupled to the mounting points (e.g.,411A,411B) or the actuator may be mounted to only the mounting points. Since different applications of an actuator (e.g., use in a ground vehicle vs. an aerial vehicle) may have different safety requirements, the number and type of fail-operational mechanisms of the actuator may depend on the application of the actuator. For example, the number of backup motors may be set to meet or exceed a particular safety requirement associated with an actuator application.

FIG.4Bis a cross sectional diagram of housing406B as seen from plane A-A′ inFIG.4A, according to one or more embodiments. As described, above, the ballscrew cavity419may include a groove442(or multiple grooves) that run along the ballscrew cavity419. The protrusion430of the end stop425may slide along the groove442to prevent the ballscrew417from rotating. Furthermore, the housing406B includes a top half408and a bottom half407(e.g., to form multiple load paths).

FIG.4Cis another block diagram of actuator400, according to one or more embodiments.FIG.4Cis similar toFIG.4Aexcept the sensor assembly420includes three different sensors (instead of the single LVDT sensor illustrated inFIG.4A). The sensors inFIG.4Cinclude a first sensor in the first housing406A and a second sensor and a backup sensor in the second housing406B. The first sensor generates signals indicative of the position of the first ball nut415A. The second sensor and backup sensor generate signals indicative of the position of the second ball nut415B. The controller445may use signals from the backup sensor if the second sensor experiences a failure event. Among other advantages, packaging may be simpler when one sensor on each nut is used and the two positions are summed together instead of having one sensor between the two housings.

FIGS.5A-Gare diagrams of another electro-mechanical actuator500, according to one or more embodiments.FIG.5Ais a perspective view of the actuator500. The actuator500may include components similar to actuator400, such as a left unit521A with a first housing506A and a right unit521B with a second housing506B.FIG.5Bis an exploded view of the actuator500.FIG.5Billustrates that each housing506A,506B includes different portions (e.g., to form multiple load paths). Specifically, each housing includes a top half and a bottom half. InFIG.5B, the top and bottom halves of the first housing are labeled (507,508).FIG.5Cis a top view of the actuator500.FIG.5Dis a cross sectional diagram of the actuator500along line A-A (inFIG.5C).FIG.5Eis a side view of the actuator500.FIG.5Fis a cross sectional diagram of the actuator500along line B-B (inFIG.5E).FIG.5Gis a cross sectional diagram of the actuator500along line C-C (inFIG.5E).

FIG.6is a magnified cross-sectional view of the first brake410A as viewed from plane B-B′ inFIG.4A, according to one or more embodiments. The brake410A includes a disk with a notch625(or a plurality of notches), a pawl630, a spring635, and a solenoid605. The brake410A may include additional, fewer, or different components than illustrated. Furthermore, the description of first brake410A with respect toFIG.6may be applicable to brakes410B and410C.

The disk is coupled to the first ball nut415A and rotates when the ball nut415A rotates (see rotation direction640). In some embodiments, the disk is a component of the ball nut415A. The solenoid605is an actuator with a sliding plunger610. When the plunger610is extended, it presses against a protrusion620of the pawl630, which results in the pawl630rotating about the pivot point615and away from the disk. This allows the disk (and ball nut415A) to rotate. The spring635applies pressure to the end of the pawl630. If the solenoid605retracts the plunger610, the spring635presses the end of the pawl630against the disk. As the disk rotates, the end of the pawl630eventually engages with the notch625and stops the disk from rotating, thus stopping the ball nut415A from rotating about the ballscrew417.

To control the brake410A, the controller445may control the solenoid605. In embodiments where an actuator (e.g.,400) includes multiple controller modules, a brake solenoid may be a dual solenoid (e.g., with dual coils) so that two or more of the controller modules may release the brake410A.

Computing Machine Architecture

The machine may be a computing system capable of executing instructions724(sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute instructions124to perform any one or more of the methodologies discussed herein.

The example computer system700includes one or more processors702(e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), field programmable gate arrays (FPGAs)), a main memory704, and a static memory706, which are configured to communicate with each other via a bus708. The computer system700may further include visual display interface710. The visual interface may include a software driver that enables (or provide) user interfaces to render on a screen either directly or indirectly. The visual interface710may interface with a touch enabled screen. The computer system700may also include input devices712(e.g., a keyboard a mouse), a storage unit716, a signal generation device718(e.g., a microphone and/or speaker), and a network interface device720, which also are configured to communicate via the bus708.

The storage unit716includes a machine-readable medium722(e.g., magnetic disk or solid-state memory) on which is stored instructions724(e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions724(e.g., software) may also reside, completely or at least partially, within the main memory704or within the processor702(e.g., within a processor's cache memory) during execution.

Additional Configuration Information

Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).