JP2013225284A - Parameter estimation method for operation system, parameter estimation method thereof, generation method for operation profile and generation system thereof - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system and method for estimating inertia and friction coefficients of a machine system to be controlled.SOLUTION: An inertia estimator 402 generates a torque command signal which continuously varies with time during a test sequence. Then the speed of an operation system responding to the torque command signal which varies with time is measured and recorded during the test sequence. Then the inertia estimator estimates one of inertia and friction coefficients of the operation system on the basis of torque command data sent to the operation system and measured speed data. An operation profile which is optimized with time is also generated on the basis of restrictions for controlling a locus of movement between two points of an operation control system. A profile generation unit calculates an operation profile of an ST curve including jerk reference continuously varying with time in at least one segment of the operation profile, and creates a smooth locus optimized with time.

Description

  Embodiments described herein relate generally to a motion system parameter estimation method, a parameter estimation system thereof, a motion profile generation method, and a generation system thereof, and to an automatic inertia estimation method, a motion profile generation method, and general motion control in a mechanical system. In particular, the present invention relates to the estimation of inertia and friction coefficient used as parameters in a motion control system, and the generation of a temporally optimal motion profile based on constraints.

  In many cases where automation is applied, motion control systems are employed to control machine position and speed. Such motion control systems typically include one or more motors or similar motion devices that operate under the control of a controller. The controller sends position and speed control commands to the motor according to a user defined control algorithm or program. Some motion control systems operate in a closed loop configuration, and the controller commands the motor to move to a target position or move to a target speed (desired state) and provide feedback information indicating the motor's operating state. Receive. The controller monitors the feedback information to determine whether the motor has reached the target position or target speed and adjusts the control signal to correct the error between the actual state and the desired state.

  Motion control system designers seek an optimal trade-off between motion speed and system stability. For example, if the controller commands the motor to transition the machine part to the target position with high torque, the machine will initially quickly shift its position from the desired position (ie, a time efficient method). But will go through the desired position due to high torque. As a result, the controller must output a correction signal to return the machine to the desired position. Such interactions will be performed repeatedly and undesirable mechanical vibrations will occur before the operating system settles into the desired position. Conversely, if the motor is commanded to move with low torque, the initial state transition accuracy could be increased and mechanical vibrations could be reduced or eliminated. However, it takes longer to move the machine to the desired position. Ideally, the controller gain factor should be selected to optimize the trade-off between state transition speed and system stability. The selection of a suitable gain factor for the controller is known as tuning.

  The response of the controlled mechanical system to a controller signal having a predetermined gain factor depends on the physical characteristics of the mechanical system, including inertia and coefficient of friction. Inertia represents the resistance to acceleration and deceleration of the operating system. The coefficient of friction represents the friction found in the motor, such as the friction between the rotor and the shaft. Accurate estimates for the inertia and friction coefficient of the controlled mechanical system simplify the tuning process and improve system performance. However, it is difficult to identify the exact values of these parameters for any mechanical system. In some cases, inertia is estimated using manual calculations based on the motor rating and the physical data (weight, dimensions, etc.) of the part including the load. Such calculations are cumbersome and time consuming. And it is difficult to get accurate values of these important parameters.

  In other aspects of motion control, motion profiles are often used to facilitate position or speed state transitions. For example, when the controller determines that the motion system must move to a new position or change its speed (according to the control algorithm or user request), the motion system is moved from that position / speed to the target position / speed. The trajectory of the position or speed for making the transition must be calculated. The trajectory is referred to as the motion profile, which reveals the speed, acceleration and / or position of the motion system over time as the system moves from the current state to the target state. Once this motion profile is calculated, the controller converts the motion profile into appropriate control signals to move the motion system through the trajectory revealed by the profile.

  In some applications, various segments (or stages) of the motion profile are calculated based on predetermined user-defined constraints (eg, maximum speed, maximum acceleration, etc.). The constraints then correspond to the mechanical limits of the operating system. Given these constraints and / or the desired target position and / or speed, the controller calculates the motion profile used to perform the desired movement or speed change. The resulting motion profile also depends on the type of profile that the controller is configured to generate. The format is typically a trapezoidal or S-curve profile. For trapezoidal profiles, the controller will calculate the motion profile according to three distinct phases: an acceleration phase, a constant velocity phase, and a deceleration phase. Such a profile is a trapezoidal velocity curve. The S-curve profile modifies the trapezoidal profile by adding four additional stages corresponding to these stage transitions. In these additional stages, it is possible to gradually transition between a constant speed (or zero speed) stage and a constant acceleration or constant deceleration stage, giving a smoother movement and more precise movement profile. Control is possible.

  Since the trapezoidal profile always accelerates or decelerates at a predetermined maximum acceleration, this type of profile tends to move faster between two points than the S-curve profile. However, the trapezoidal profile will have a steep transition between the constant speed (or zero speed) phase and the acceleration phase, which will result in excessive rattling in the system. Furthermore, if a trapezoidal motion profile is used, the risk of overshooting with respect to the target position or speed is increased and the accuracy is lowered. There is also additional controller operation and time to return the operating mechanism to the desired goal. On the other hand, in the S curve profile, high-precision control is possible between the constant speed phase and the acceleration or deceleration phase, but additional time is generated in the movement between the two points.

  The above description is merely intended to provide an overview of some of the challenges facing a typical motion control system. Other challenges in a typical system and the contrasted advantages of the various non-limiting embodiments described herein will become apparent from the following description.

  In order to provide a basic understanding of one or more embodiments, an overview is provided below. This summary is not an exhaustive overview of all contemplated embodiments and is not intended to be a key or essential element of any embodiment, and any or all embodiments may be described. It is not something to explain. Its purpose is to present a summary of one or more embodiments in a simplified form as a prelude to the more detailed description that is presented later.

  One or more embodiments of the disclosure relate to a system and method for automatically estimating the inertia and coefficient of friction of a controlled mechanical system. To achieve this goal, the inertial estimation system can instruct the controller to send a torque control signal to the motor, and the torque control signal is timed between a defined maximum torque value and a minimum torque value. Continuously changes. This torque control signal is controlled based on a test sequence determined in the inertia estimation system. As a non-limiting example, the test sequence can specify that the torque control signal gradually increase at a defined increase rate to accelerate the motor. In response to the defined trigger, the torque control signal gradually decreases to zero and can decelerate the motor to a stopped state.

  During these acceleration and deceleration phases, the inertia estimation system measures and records the motor speed in response to the torque control signal over time. Then, the inertia calculation unit determines either or both of the estimated inertia and the estimated friction coefficient of the mechanical system based on the time-varying torque signal and the measured speed curve. The estimated inertia and / or the estimated coefficient of friction are later used to facilitate identification of the appropriate control gain of the system.

  Other aspects of this disclosure relate to systems and methods that efficiently generate temporally optimized motion profiles based on constraints. In order to achieve this purpose, the profile generation unit arranged inside the controller analyzes the movement between two points optimized in time based on the constraint condition in real time, and generates a trajectory based on the solution. Utilize mathematical algorithms to calculate. In order to obtain smooth and accurate movement between two points, the profile generator generates a profile having a continuous jerk criterion with respect to time in at least one of the acceleration segment and the deceleration segment of the profile. Calculate the trajectory based on the profile. By calculating a motion profile including a time-varying jerk criterion, the profile generator disclosed herein can create a smoother and more stable motion than a normal trapezoidal or S-curve profile.

  The profile of the ST curve generated by the profile generator supports asymmetric acceleration and deceleration phases. Traditionally, asymmetric acceleration and deceleration are only supported by the trapezoidal profile and not the smoother S-curve profile. ST curves generated according to the techniques described herein allow for the use of smoother motion profiles for asymmetric acceleration and deceleration. In some embodiments, the profile generator described herein can also generate an S-curve profile that supports asymmetric acceleration and deceleration.

  In other aspects, one or more embodiments of the profile generator described herein may improve its efficiency by omitting calculations for segments of trajectories that are not used in the final trajectory. That is, in the case where one or more segments are not used, rather than calculating profile data for all seven stages of the profile, the profile generator described herein performs a final operation on a given trajectory. Calculation can be performed only for the stage used in the profile, and the calculation load of the controller can be reduced. The profile generator can automatically determine which segments of the motion profile are skipped for a given movement between two points, so that the remaining segments can be calculated.

  According to another aspect, one or more embodiments of the profile generator described herein may provide for the accuracy of the movement between two points by ensuring that the total profile time is a multiple of the motion controller sampling time. Increase efficiency. In an exemplary technique, the profile generator calculates a time-optimized solution for a given movement between two points, determines the duration of each segment of the resulting profile, and Can be rounded so that the duration of is a multiple of the sampling time. The profile generator can recalculate the jerk, acceleration / deceleration, velocity, and position of the profile to fit these rounded times. As a result, the output trajectory coincides with the sample points, alleviating the need to compensate for small differences that occur when the entire profile time is between two sample times.

  The following description and the annexed drawings set forth some illustrative details of the one or more embodiments. However, these aspects illustrate some of the many ways in which the principles of the various embodiments can be used, and the described embodiments are equivalent to all such aspects and equivalents. Including things.

It is a block diagram showing the structure of simplified closed loop operation control. 1 is a block diagram illustrating a non-limiting inertia estimation system. It is a block diagram showing the input / output relevant to an inertia estimator. It is a block diagram showing the interaction between an inertia estimator and a motion control system. It is a graph which illustrates torque command u (t) and corresponding feedback speed v (t) with respect to time. It is a block diagram showing the inertia estimator which has an inertia part and a friction coefficient part. It is a block diagram which illustrates the structure which an inertia estimator functions as an independent element compared with a motion controller. It is a block diagram showing the application example of motion control tuning using the estimated inertia and friction coefficient which were produced | generated by the inertia estimator. 6 is a flowchart illustrating a procedure for estimating inertia and coefficient of friction for a controlled mechanical system. It is a flowchart which illustrates the procedure which performs the test sequence of a motion control system, in order to estimate an inertia and a friction coefficient. It is a block diagram which illustrates the operation profile generation system which can generate the operation profile in an operation control system. FIG. 3 is a block diagram illustrating an operation controller using a profile generator. FIG. 3 is a block diagram illustrating input and output of an exemplary position profile generator. FIG. 3 is a block diagram representing inputs and outputs of an illustrated speed profile generator. It is a graph which compares a normal trapezoidal and S curve profile, and illustrated ST profile. Fig. 6 is a graph illustrating an S-curve profile using all seven stages. It is a graph which illustrates the line motion profile of S music which omitted the constant speed step. It is a graph which illustrates the S curve profile which excluded the constant acceleration and the constant deceleration stage. It is a graph which illustrates the S curve profile which excluded the constant acceleration, the constant speed, and the constant deceleration stage. It is a flowchart which illustrates the procedure which calculates the operation profile for the movement between two points in an operation control system. It is a flowchart which illustrates the procedure of calculation of the time optimal motion profile based on the restrictions according to the sampling time of a motion controller. It is a flowchart which illustrates the procedure which calculates the motion profile for omitting a segment and performing a movement between two points. FIG. 3 is a block diagram illustrating a networked or distributed computing environment for implementing one or more embodiments described herein. FIG. 2 is a block diagram illustrating a computing system or operating environment for implementing one or more embodiments described herein.

  Several embodiments will be described with reference to the drawings. Similar symbols in the figures represent similar elements. Numerous specific details in the following description are provided for the purpose of explanation and understanding of this disclosure. However, embodiments may be practiced without these specific details or with other methods, elements, materials, and the like. As another example, structures and devices are shown in block diagram form in order to facilitate describing one or more embodiments.

  The systems and methods described herein relate to techniques for generating inertia and coefficient of friction estimates for a controlled mechanical system. In one or more embodiments disclosed herein, these parameters can be estimated substantially automatically by operating the mechanical system through a test sequence that will be described in detail below. The result of this test sequence can be used to generate an accurate inertia and coefficient of friction estimated for the system. These estimated parameters can be used substantially to facilitate simplified precise tuning and control of the operating system.

(Estimation of inertia and friction coefficient)
FIG. 1 shows a simplified closed loop motion control structure. The controller 102 is programmed to control the motor 104 that moves the mechanical load 106. Controller 102, motor 104 and load 106 include the basic elements of the illustrated motion control system. In a non-limiting example application, the load 106 represents one axis or positioning system of a single-axis or multi-axis robot. In such an application, the controller 102 sends a control signal 108 that instructs the motor 104 to move the load 106 to the desired position at the desired speed. The control signal 108 may be given directly to the motor 104, or may be given to a motor drive unit (not shown) that controls the power supplied to the motor 104 (and the speed and direction of the motor). The feedback signal 110 indicates the current state (ie, position, speed, etc.) of the motor 104 and / or load 106 in substantially real time. In a servo drive system, the feedback signal 110 can be generated by, for example, an encoder or analyzer (not shown) that tracks the absolute or relative position of the motor. In sensorless systems that lack a speed sensor, the feedback signal is provided by a speed or position estimator. During the move operation, the controller monitors the feedback signal 110 so that the load 106 reaches the target position accurately. The controller 102 compares the actual position indicated by the feedback signal 110 with the target position and adjusts the control signal 108 to reduce or eliminate errors between the actual and target positions.

  In other exemplary applications, load 106 represents a rotary load (eg, pump, washer, centrifuge, etc.) driven by motor 104, and controller 102 controls the rotational speed of the load. In this example, the controller 102 gives the motor 104 a command to transition from the first speed to the second speed (via the control signal 108) and makes the necessary adjustments to the control signal 108 based on the feedback signal 110. It should be appreciated that the parameter estimation technique for this application is not limited to using the illustrated form of the motion control system described above, but can be suitably applied to any motion control application.

  The control signal output generated by the controller 102 in response to an error (transmitted by the feedback signal 110) between the desired position or speed and the target position or speed depends on the gain factor of the control loop. Since the choice of a suitable gain depends on the physical characteristics of the mechanical system being controlled, design engineers often use a trial and error approach (ie, control loop tuning) to determine the preferred gain factor. Must be. For example, mechanical systems with large inertia (resistance to acceleration or deceleration), especially applications that require fast convergence to a target position or speed, require a relatively large initial torque to move to a new position or speed right. However, large torque increases the likelihood of overshoot and requires reverse correction to return the system to the target. Without an optimal gain setting, the system will perform a compensating interaction before it settles to the target position or speed, resulting in unwanted mechanical vibrations. Such vibrations can make the system unstable and cause system delays. And excessive power is consumed as a result of the additional operations required to stabilize the system. The friction of the motor also affects the degree to which the mechanical system responds to the given control signal, which is a factor to consider when tuning the control system.

  Knowing an accurate estimate of the inertia and friction coefficient of the mechanical system can simplify the tuning of the control system. Knowledge of these parameters also improves the performance of the operating system. Accordingly, in one or more embodiments of the present application, the inertia and friction coefficient of the controlled mechanical system can be accurately estimated in a substantially automated manner.

  FIG. 2 is a block diagram illustrating a non-limiting inertia estimation system that can generate an estimate of the inertia and friction coefficient of a mechanical system. The inertia estimator 202 includes a torque command generation unit 204, a speed monitoring unit 206, an inertia calculation unit 208, a friction coefficient calculation unit 210, an interface unit 212, one or more processors 214, and a memory 216. In various embodiments, one or more of the torque command generator 204, the speed monitor 206, the inertia calculator 208, the friction coefficient calculator 210, the interface 212, the one or more processors 214, and the memory 218 may perform inertia estimation. In order to perform one or more functions of the vessel 202, they can be electrically or communicably coupled to each other and can be electrically and communicably coupled to each other.

  In some embodiments, the torque command generator 204, the speed monitor 206, the inertia calculator 208, the friction coefficient calculator 210, and the interface 212 are stored in the memory 216 and execute software instructions executed by the processor 214. Including. Inertial estimator 202 can also interact with other hardware and software components not represented in FIG. For example, the processor 214 interacts with an interface device with one or more external users, such as a keyboard, mouse, display monitor, touch screen, or other interface device.

  The interface unit 212 accepts user input and provides output to the user in any suitable format (eg, visual, audio, tactile, etc.). The user input may be, for example, user input parameters used in the inertia estimator when executing an inertia estimation sequence (described in detail below). The torque command generation unit 204 can be configured to output a torque control command that changes continuously in time according to a defined test sequence. Speed monitor 206 may receive mechanical system speed data for use in inertia and coefficient of friction calculations. In some embodiments, the speed monitor 206 is applied with the torque control command generated by the torque command generator 204 and measures and records the motor speed in response thereto. The speed monitoring unit 206 can also receive speed data measured from another measuring instrument. The inertia calculation unit 208 and the friction coefficient calculation unit 210 calculate the inertia and the friction coefficient based on the time-varying torque command generated by the torque command generation unit 204 and the speed curve acquired by the speed monitoring unit 206. Each is configured to calculate. One or more processors 214 perform one or more functions described below with reference to the disclosed systems and / or methods. The memory 216 may be any computer-readable storage medium and can be executed by a computer to perform the functions described below with reference to the disclosed system and / or method. Store instructions and / or information.

  The inertia estimator generates an estimate for the inertia and friction coefficient of the mechanical system by operating the system through a test sequence and calculating an estimate based on the result. FIG. 3 is a block diagram representing inputs and outputs associated with inertia estimator 302 (similar to inertia estimator 202). Inertial estimator 302 can generate a torque command 310 that commands the motor driving the operating system to rotate in the direction specified by the applied torque. Rather than issuing one or more constant torque commands that cause transitions between constant torque values to occur in sudden steps, resulting in a stepped torque output, inertia estimator 302 can generate maximum and minimum torques. The torque command 310 is controlled so that the torque value changes continuously with respect to time. As will be discussed in more detail below, inertia estimator 302 controls the torque value output via torque command 310 according to a test sequence having user-defined parameters.

  The motion system accelerates or decelerates according to the torque command 310 issued from the inertia estimator, and the velocity feedback 304 from the motion control system is provided to the inertia estimator 302. Speed feedback 304 represents the speed of the operating system with respect to time. In the illustrated test sequence, inertia estimator 302 can control torque command 310 as a function of speed feedback 304 and one or more set points defined by the user. The user-defined set points include one or more limit torques 306 that determine the upper and lower limits of the torque command signal and / or one or more speed detection points 308 that determine the trigger speed value. The trigger speed value is used to control the torque command 310 and to generate an estimate.

  Upon completion of the test sequence, inertia estimator 302 generates motion system inertia estimate 312 and motion system friction coefficient estimate 314. Inertial estimator 302 is output to the operating system and determines these estimates based on torque command 310 corresponding to speed feedback 304. In one or more embodiments, the inertia estimator 302 integrates selected portions of the torque curve (corresponding to the torque command 310) and the velocity curve (corresponding to the speed feedback 304) over time and as a function of these integrals. An estimated inertia 312 and an estimated friction coefficient 314 can be calculated.

  FIG. 4 illustrates the interaction of the inertia estimator and the motion control system during execution of the illustrated test sequence. In this example, operating system 424 includes a motor 424 that is responsive to a control signal 420 provided by controller 418. The motor 424 is used to drive a load (not shown), such as a position shaft, a rotating part of the machine, or other motor driven load. Controller 418 monitors feedback 422 that provides data (eg, position, speed, etc.) indicating the real-time state of motor 424.

  In the illustrated example, inertia estimator 402 is specified as a separate element from controller 418. In such a configuration, the inertia estimator 402 can exchange data with the controller 418 or other elements of the operating system 424 via any suitable communication means. Communication means include, but are not limited to, wired or wireless networks, wired data links or other communication means. In other embodiments, inertia estimator 402 may be integrated into controller 418. For example, the inertia estimator 402 may be a function part of an operating system of the controller and / or control software executed by one or more processors existing on the controller 418. The inertia estimator 402 may be a hardware component such as a circuit board or an integrated circuit that exchanges data with other functional elements in the controller 418. Other suitable implementations of inertia estimator 402 are within the scope of some embodiments of the present disclosure.

Prior to testing, one or more user-defined parameters 412 are provided to the inertia estimator 402 via an interface unit 406 (similar to the interface unit 212 described in connection with FIG. 2). These parameters include a maximum torque u _max and a minimum torque u _min that determine an upper limit and a lower limit of a torque command generated by the torque command generation unit 408 (similar to the torque command property western portion 204 of FIG. 2). In some embodiments, the inertia estimator 402 requires only the maximum torque u _max determined by the user and uses the determined magnitude of the maximum torque as a limit value for both the direction of travel and the reverse direction. In other embodiments, the inertia estimator 402 accepts both u _max and u _min values and allows different torque setpoints for each direction of travel and reverse. The values selected for u _max and u _min correspond to the scheduled operating limits of the operating system 424, thereby determining the inertia and coefficient of friction based on the characteristics of the operating system 424 relative to the overall torque profile of the system. Is allowed to do. As will be described in more detail below, the user-defined parameter 412 also includes one or more speed detection points (v1, v2, v3,...) That determine the critical speed used to define the stages of the test sequence. .

  The interface unit provides a user-defined parameter 412 to the torque command generation unit 408. When the test is started, the torque command generator 408 outputs a torque command 414 to the operation system 424. Since the torque command generation unit 408 continuously changes the torque command with respect to time, the torque command 414 is expressed as u (t). In the configuration shown in FIG. 4, the inertia estimator 402 sends a torque command 414 to the controller 418 so that the controller 418 rotates in the direction indicated by the motor 424 with the indicated torque (control signal 420). Command). The speed monitoring unit 410 reads speed data 416 from the controller 418 according to the rotation of the motor. (The controller 418 itself measures the speed of the motor 424 via the feedback 422.) The speed 416 measured against time is expressed as v (t).

As the test progresses, the torque command generator 408 changes the torque command 414 according to a predetermined test sequence, and each phase of the test sequence is initiated by a speed feedback 416 compared to a user-defined parameter 412. The An example test sequence is described below with reference to FIG. 5 which shows an example of a torque command u (t) and a corresponding speed feedback v (t) as a graph over time. As shown in the torque graph 502, the torque command signal u (t) is constrained by u _max and u _min . The speed monitoring points v1, v2, and v3 shown in the speed graph 504 determine the phase transition of the test sequence. The values of u _max , u _min , v 1, v 2, and v 3 are determined by the user prior to testing (eg, as user-defined parameter 412 in FIG. 4).

When the test is started at time t = 0 (zero), the applied torque signal u (t) and motor speed v (t) are both zero. Initially, the torque command generator sends a negative torque signal to the operating system to accelerate the operating system in the negative direction. In the first phase of the test, the torque command generation unit gradually decreases the torque command u (t) until the motor speed v (t) reaches v1 or the torque command u (t) reaches u _min . . In this example, the motor speed v (t) reaches v1 at time t = t ₁ and starts the second phase of the test. As shown in graph 502, the torque command u (t) continuously decreases at a substantially constant rate between times t = ₀ and t = t ₁ . In one or more embodiments, the rate at which torque commands decrease or increase (ie, the slope of u (t)) can be configured as a user-defined parameter of inertia estimator 402 (eg, via interface 406).

For the second phase of the test (starting at time t = t ₁ ), the torque command generation unit determines whether the motor speed v (t) reaches the speed detection point v3 or the torque command u (t) is the torque set point u. _The torque command u (t) is gradually increased until _max is reached. In this example, the torque command u (t) reaches the upper limit umax before the motor speed v (t) reaches the speed detection point v3. Since the motor is still accelerating at this time, the torque command generator maintains the torque command signal at u _max until the speed v (t) reaches v3. As represented in the speed graph 504, the motor speed reaches the v3 at time t = _{t 4.} If the speed v (t) does not reach the speed detection point v3 by a defined time after the torque command signal reaches u _max (ie, the physical speed of the operating system for whatever reason the speed detection point v3 is If it is set higher than the critical speed), the inertia estimator can initiate a suitable timeout processing routine. The timeout processing routine includes, for example, interrupting the test sequence and displaying an error message via the interface unit 406.

  During this phase, the operating system is accelerating towards v3, so the speed passes through the speed detection point v2, which indicates the acceleration phase of the test sequence. As will be discussed in more detail below, speed detection point v2 is set to be greater than zero and less than v3 and is used to represent the start of the acceleration phase and the end of the deceleration phase of the test sequence.

If detecting that the motor speed has reached the v3, the torque command generator, by gradually decreasing the torque command u (t) at time t = t _4, starts a third phase of the study. As the torque command u (t) decreases, the motor continues to accelerate for a while until the value of the torque command u (t) is less than the friction force of the operating system. When the value of the torque command u (t) becomes smaller than the frictional force of the operating system, the motor starts to decelerate. Motor, when the speed reaches the v3 at time t = t _3, since the still accelerated, even after the torque command began to decrease, during some time, continued state beyond the v3. According to the definition of the test sequence, the torque command generator continues to decrease u (t) until the motor speed v (t) returns to the speed detection point v3 (time t = t6). Thereafter, u (t) is kept constant until the motor speed v (t) returns to the speed detection point v2 (time t = t7). At this point, the inertia estimator obtains the data necessary to calculate the inertia and friction coefficient estimates for the mechanical system. The torque command generator returns the torque command signal u (t) to zero (time t = t8) and gradually stops the operating system by gradually decreasing the end of the v (t) curve as shown in the graph 504. Let

  The above test sequence described in connection with FIG. 5 is only intended to represent an example and does not limit the test sequence. Any suitable test sequence that continuously varies the torque command u (t) with respect to time and measures the corresponding speed profile v (t) of the operating system can be obtained from some embodiments disclosed herein. It should be understood that it is in category. For example, in the above-described example, the torque command u (t) that changes the direction in response to the speed v (t) that has reached each speed detection point has been described. However, in some test sequences, the direction of the torque command May include a phase that only changes the rate of increase or decrease of the torque command u (t) when the speed detection point is reached without changing (that is, the increasing torque command has reached the phase detection point) Responsive to v (t) and may continue to increase at a slower rate).

  When the test sequence described above is performed, the inertia estimator 402 compares the torque command signal u (t) generated by the torque command generator 408 and the corresponding motor speed v (t) read by the speed monitor 410. Record both. These torque and speed curves characterize the motion system 424 so that accurate estimates of inertia and coefficient of friction can be calculated based on the curves. In one or more embodiments, the inertia estimator calculates these estimates based on the integral of u (t) and v (t). The following illustrates a non-limiting technique that exploits the integral of u (t) and v (t) to derive an estimate of inertia and coefficient of friction for the motion system.

The operating system can be represented by a differential equation.
Here, J is inertia and B is a friction coefficient. u (t) is the torque command signal, and v (t) is the corresponding speed of the operating system in response to the torque signal u (t) (eg, u (t) and v (t) are shown in FIGS. 5).

If both sides of equation (1) are integrated in the acceleration and deceleration stages, respectively, the following equation is obtained.
Here, u _acc (t) and v _acc (t) are part of u (t) and v (t), respectively, and correspond to the acceleration phase of the test sequence. u _dec (t) and v _dec (t) are part of u (t) and v (t), respectively, and correspond to the deceleration phase of the test sequence.

Equations (2) and (3) can be solved to determine inertia J and coefficient of friction B.

In the torque curve and speed curve examples shown in FIG. 4, the acceleration phase begins when the speed v (t) first reaches the speed detection point v2 (time t = t ₃ ), and the torque signal u (t ) Crosses zero (time t = t ₅ ). The speed of the operating system at the end of this acceleration phase is recorded as v4 (shown in graph 504). The deceleration phase starts when the torque signal u (t) crosses zero (time t = t ₅ ) and ends when the speed v (t) returns to v2 (time t = t7). Inertial estimator 402 can be configured to recognize depictions of these acceleration and deceleration phases to derive estimated inertia and estimated friction coefficients based on equations (4) and (5). It should be appreciated that other criteria for depicting the acceleration and deceleration phases are within the scope of some embodiments disclosed herein.

Given these acceleration and deceleration phase definitions, the integration ranges of u _acc (t) and u _dec (t) are represented by the shaded regions of graph 502 labeled U _acc and U _dec , respectively. The integration ranges of v _acc (t) and v _dec (t) are represented by the shaded areas of the graph 504 labeled V _acc and V _dec , respectively. Therefore, U _acc , U _dec , V _acc and V _dec are determined as follows.

By substituting the equations (6) to (9) into the equations (4) to (5), the inertia J and the friction coefficient B can be expressed as follows.
Here, the speed changes Δv _acc (t) and Δv _dec are defined as follows.

  Equations (12) and (13) are exemplary and are non-limiting equations for calculating the estimated inertia and coefficient of friction of the operating system based on continuous torque and speed data. It can be appreciated that any suitable formula for calculating these parameters via integration of the continuous torque signal and the corresponding speed curve is within the scope of some embodiments disclosed herein. It is.

  When the above test sequence is completed in connection with FIGS. 4 and 5, the inertia estimator derives equations (12) and (13) (or other suitable equations) and estimators of inertia and coefficient of friction. This can be applied to continuous torque data u (t) and motor speed data v (t) obtained by a test for performing the above. FIG. 6 is a block diagram illustrating an inertia estimator 602 having an inertial computation unit 606 and a friction coefficient computation unit 608 in accordance with one or more embodiments disclosed herein. Although inertia estimator 602 is shown to include both inertia calculator 606 and friction coefficient calculator 608, some embodiments of inertia estimator 602 may be used without departing from the scope of this disclosure. Only one of these computing units can be included. That is, the inertia estimator 602 may be configured to calculate either one or both of inertia and the coefficient of friction.

After the torque data u (t) and the speed data v (t) are obtained, the torque command generator 604 (similar to the torque command generators 408 and 204) includes an inertia calculator 606 and a friction coefficient calculator 608 (FIG. 2). Torque data is given to the inertia calculation unit 208 and the friction coefficient calculation unit 210. Similarly, the speed monitor 606 gives the obtained speed data v (t) to the inertia calculator 606 and the friction coefficient calculator 608. According to one or more embodiments, the inertia estimator 602 can derive the torque data and the values of U _acc , U _dec , V _acc and V _dec using equations (6)-(9) above. The speed data is separated into acceleration phase data (u _acc (t) and v _acc (t)) and deceleration phase data (u _dec (t) and v _dec (t)).

The inertia calculation unit integrates u _acc (t), u _dec (t), v _acc (t), and v _dec (t), and a function of the integrated value (for example, based on the equation (12) or a modification thereof) As a result, the estimated inertia J610 is calculated. Similarly, the friction coefficient calculator 608 can calculate the estimated friction coefficient B616 as a function of the integral value (eg, based on equation (13)). As a result, the inertia estimator 602 can output the estimated inertia J610 and the estimated friction coefficient B612 according to the requirements of the individual application in which the inertia estimator operates. For example, inertia estimator 602 provides inertia J 610 and friction coefficient B 612 to motion controller 614, which uses the values of J and B to facilitate tuning of one or more gain factors. The inertia estimator 602 can output the output to the display device (for example, via the interface unit 212) so that the estimated values of J and B can be manually input for another operation control or tuning application. Accurate estimation of operating system inertia J610 and coefficient of friction B612 simplifies the tuning process and facilitates accurate parameter tuning. This results in a precise and energy efficient machine operation. Further, the inertia estimator calculates J and B values based on data collected from the entire torque profile of the operating system (rather than estimating based on the system's response to one or more constant torque commands). Thus, the inertia and friction coefficient estimates derived by the inertia estimator are more accurate over the entire operating range of the operating system.

  In the example described above, the inertia estimator sends a torque command u (t), receives speed feedback v (t) via an operation control unit (eg, controller 418 in FIG. 4), and operates via the controller. However, other configurations are also within the scope of some embodiments disclosed herein. For example, FIG. 7 shows a configuration in which the inertia estimator 706 operates as an element independent from the controller 702. In this example, inertia estimator 706 can generate its own torque command signal independent of controller 702. The tested and controlled motor 704 can receive a torque command signal from the controller 702 or inertia estimator 706 depending on the state of the switch 712. Speed feedback 710 from motor 704 is provided to both controller 702 and inertia estimator 706. During the test sequence, switch 712 is set such that torque command u (t) is transmitted from inertia estimator 706. Tests are performed as described in the previous example, and inertia estimator 706 generates an estimate of the motion system inertia J and coefficient of friction B. Inertia estimator 706 then provides an estimate of J and B to controller 702, which can use that value to determine a suitable control gain factor or other control parameter. Once the control parameters are set, the switch 712 is switched to a position that provides the torque command 708 from the controller 702 to the motor 704, and normal operation of the motor system using the control gain factor derived based on J and B Is executed.

  FIG. 8 shows an application example of motion control tuning using the estimated inertia and estimated friction coefficient generated by the inertia estimator. In this example, the tuning unit 804 adjusts the control gain for the controller 806, and the controller 806 controls the operation of a motor-driven operating system (not shown). Inertial estimator 802 can generate estimates of the operating system's inertia J808 and friction coefficient B810 using the techniques described above. Specifically, the inertia estimator 802 instructs the controller 806 to send a continuous torque command to the motor of the operating system, the torque command being continuously over time according to a predetermined test sequence. Change. Also, in embodiments where the inertia estimator 802 operates independently of the controller 806 (as in the example configuration depicted in FIG. 7), the inertia estimator 802 generates its own continuous torque command to the operating system. It may be output. The test sequence can include an acceleration and deceleration phase, during which the inertia estimator 802 monitors and records the speed of the operating system in response to the applied torque command. Inertial estimation based on time sequence of torque command signal and corresponding time-varying operating system speed integral (eg, equations (12) and (13)) for test sequence results Unit 802 can calculate an estimate of inertia J808 and coefficient of friction B810.

  The inertia estimator 802 can provide the tuning unit 804 with the inertia J808 and the friction coefficient B810. Instead, the inertia estimator 802 may give the values of J and B to the user interface, and the user may manually input the estimated inertia and the estimated friction coefficient to the tuning unit 804. Knowledge of J and / or B causes the tuning unit 804 to generate a suitable estimate of one or more control gains 812 based on the mechanical characteristics of the operating system. The tuning unit 804 may include a control system bandwidth 814 (eg, overlapping frequencies) manually adjusted by the user via the interface 816 to obtain the desired operating characteristics, an inertia J and a coefficient of friction B 810, or any of them. A suitable value for the control gain 812 can be generated as a function of heel.

  In normal applications, the inertia estimator described herein can produce a reliable estimate of the motion system inertia J and coefficient of friction B while initially preparing the motion control system prior to normal operation. . Specifically, the inertia estimator is used in connection with the configuration and tuning of control parameters (eg, control gain factor). Once set, and after it is not decided to readjust the system at a later time, these parameters usually remain fixed even after the system is up and running. However, in some embodiments, the inertia estimator can be configured to automatically recalculate the values of J and B periodically or continuously during the operating time. With such a configuration, control parameters based on the estimation of J and B are adjusted transiently during normal operation (eg, as a result of mechanical wear, load changes seen on the monitor, etc. ) The mechanical characteristics of the operating system can be corrected for the step change in substantially real time.

  9 and 10 represent several procedures according to some disclosed aspects. For ease of explanation, the procedures are shown and described as a series of actions, but the disclosed aspects are not limited to the order of the actions, and some actions are shown and described herein. It should be understood and recognized that they may be performed concurrently with other actions in a different order than those, or any of them. For example, those skilled in the art will understand and appreciate that a procedure is selectably represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all displayed acts may be required to perform a procedure in accordance with some disclosed aspects. It should be further appreciated that the procedures set forth below throughout this disclosure can be stored in a product that facilitates the transfer of such procedures to a computer.

  FIG. 9 depicts an example procedure 900 for estimating the inertia and coefficient of friction of a controlled mechanical system. In step 902, a continuous torque command u (t) is sent to the controller of the operating system, and the torque command u (t) varies over time between the determined maximum torque and minimum torque set points. In one or more embodiments, the torque command u (t) is such that the output u (t) depends on the phase of the test sequence and the response of the mechanical system compared to one or more user-defined set points. Follow a defined test sequence. The test sequence comprises both an acceleration phase and a deceleration phase that correspond to motor speed increases and decreases, respectively. In a two-way test, the torque command u (t) changes between positive or negative torque values during the test sequence, accelerating the operating system in both directions during the test.

In step 904, the operating system speed v (t) in response to the torque command u (t) is recorded. As a result, upon completion of the test sequence, the curve data of the applied torque command u (t) and the curve data of the resulting operating system speed v (t) for time t = 0 to t _end are obtained. Both are obtained. Here, t _end is the duration of the test sequence.

  In step 906, an estimate of at least one of inertia and friction coefficient based on the integration of torque curve u (t) and speed curve v (t) is calculated. In one or more embodiments, the u (t) and v (t) curves may be divided into an acceleration phase and a deceleration phase, and the inertia and friction coefficients may be calculated based on the respective integration of the acceleration phase and the deceleration phase. it can. (For example, using equations (12) and (13) or other suitable equations.) In step 908, one or more parameters of the operating system are used to calculate the estimated inertia and coefficient of friction calculated in step 906, or any Set as a function. As a non-limiting example, one or more control gain factors can be set based on the estimated inertia and / or estimated friction coefficients calculated according to steps 902-906.

  FIG. 10 illustrates an example procedure 1000 that is performed in the motion control system to estimate inertia and coefficient of friction. In step 1002, the torque command applied to the operating system is the first speed detection point (eg, the speed detection of FIG. 5) until the maximum torque set point is reached or in response to the applied torque command. It increases continuously until it is accelerated to point v3). The maximum torque set point and the first speed detection point correspond to the upper operating limit of the operating system and can be set prior to testing (eg, as maximum torque and speed in normal operation of the operating system). The increase rate of the torque command can also be determined by the user. In one or more embodiments, if the torque command reaches a maximum torque value before the speed of the operating system reaches the first speed monitoring point, the torque command is accelerated until the operating system is accelerated to the first speed detection point. Is held at the maximum torque value. If the speed of the operating system does not reach the first speed detection point within a predetermined time-out period, an appropriate time-out process is started.

  Since the operating system is accelerated from a standstill to a first speed detection point, the speed will pass through a second speed detection point (eg, speed detection point v2 in FIG. 2). Here, the second speed detection point is larger than zero and smaller than the first speed detection point. The acceleration phase of the test begins when the velocity first reaches the second velocity detection point.

  If it is detected that the operating system has accelerated to the first speed detection point, the torque command is continuously reduced at step 904 until the torque command reaches the initial torque set point. In this case, when the first speed detection point is reached in step 1002, the operating system is accelerating. Therefore, even if the torque signal starts to decrease in step 1004, the speed is kept at the first speed detection point for a while. Increase beyond. Decreasing the torque command signal substantially decelerates the operating system and returns it to the first speed detection point. As in step 1002, the rate at which the torque command is reduced can be configured as a user-defined parameter. In this example, before the operating system returns to the first speed detection point, the torque command is reduced to zero and negative until a minimum torque set point is reached or until the first speed detection point is decelerated. Continue to decrease in the direction. That is, the torque command crosses the zero point during this phase of the test sequence. This marks the end of the acceleration phase and the beginning of the deceleration phase. As in step 1002, if the torque command is reduced to the minimum torque set point before the operating system reaches the first speed detection point, the torque command is reduced to the minimum torque until the first speed detection point is reached. Held in value.

  When the speed of the operating system returns to the first speed detection point, the torque command value when the speed reaches the first speed detection point is the same as that in step 1006 until the operating system decelerates and returns to the second speed detection point. Maintained as a constant value. This triggers the end of the deceleration phase.

In step 1008, the time that the torque command crosses zero during step 1004 is detected. This time is denoted as _TCROSSOVER and is used to _delimit the acceleration and deceleration phases of the test sequence. (In the above example associated with FIG. 4, T _CROSSOVER = t ₅ ). In step 1010, integration is performed in the acceleration phase portion of the operating system torque command curve and the corresponding velocity curve. That is, the torque command data is integrated from time T ₀ to T _CROSSOVER . Here, T ₀ is the start time of the acceleration phase (the time at which the speed first crosses the second speed detection point, for example, the time t _{3 in} FIG. 4). The result of integration in the acceleration phase of the torque command is shown as _Uacc . Similarly, continuous speed data measured from the motion control system in response to the applied torque command is integrated from time T ₀ to T _CROSSOVER to obtain the result V _acc of speed integration in the acceleration phase.

In step 1012, similar integration is performed on the deceleration portion of the torque and speed data. That is, the torque and speed data is integrated from time T _CROSSOVER to T _FINAL corresponding to the time at which the operating system decelerates at step 1006 and returns to the second speed detection point. Here, T _FINAL is the end time of the deceleration phase. (In the above example related to FIG. 4, T _FINAL = t7.) These integration results in the deceleration phase of torque and speed data are denoted by U _dec and V _dec , respectively.

In step 1014, the estimated inertia and / or estimated friction coefficient of the motion system is calculated based on the integrals U _acc , V _acc , U _dec and V _dec . For example, the estimated inertia and estimated coefficient of friction will be calculated based on equations (12) and (13) or variations thereof.

[Operation profile generator]
FIG. 11 is a block diagram illustrating a non-limiting motion profile generation system capable of generating a motion profile for two-point movement of the motion control system. The motion profile generation system 1102 includes a position profile generation unit 1104, a speed profile generation unit 1106, an interface unit 1108, one or more processors 1110 and a memory 1112. In some embodiments, one or more of position profile generator 1104, velocity profile generator 1106, interface unit 1108, one or more processors and memory 1112 perform one or more functions of motion profile generation system 1102. In order to be electrically and / or communicably coupled to each other. In some embodiments, the position profile generator 1104, the velocity profile generator 1106, and the interface 1108 comprise software instructions stored in the memory 112 and executed by the processor 1110. The motion profile generation system 1102 may interact with other hardware and software not shown in FIG. For example, the processor 1110 may interact with a user interface device such as a keyboard, display monitor, touch screen.

  Interface 1108 receives user input and provides output to the user in any suitable form (eg, visual, audible, tactile form). User inputs are, for example, user-set constraints (eg, maximum acceleration, maximum speed, etc.) and are used by the motion profile generation system 1102 to calculate a motion profile (described in detail below). The position profile generator 114 is configured to receive a command of a desired target position for the motion system and calculate a motion profile for transitioning to the target position within a parameter that represents a user-defined constraint. Similarly, the speed profile generator 1106 receives a command of a desired target speed for the motion control system and a motion profile for transitioning the motion system from the current speed to the target speed to meet the defined constraints. Can be generated. FIG. 11 depicts a motion profile generation system that includes both a position profile generation unit 1104 and a velocity profile generation unit 1106, but some embodiments of the motion profile generation system may be used without departing from the scope of this disclosure. It should be appreciated that only the position profile generator 1104 or the velocity profile generator can be included. One or more processors 1110 may perform one or more of the functions described herein with reference to the disclosed systems and / or methods. Memory 1112 stores computer-executable instructions and / or information for performing one or more of the functions described herein with reference to any of the disclosed systems and / or methods. A computer-readable storage medium.

  In some embodiments, the profile generator described herein may be an integrated part of the operation controller. FIG. 12 illustrates an operation control system 1200 including a main control unit 1202 that uses a profile generation unit 1206 in accordance with one or more embodiments of the present disclosure. The main control unit 1202 is, for example, a programmable logic controller (PLC) that monitors and controls a system (eg, an industrial process, an automatic system, a batch process, or the like) that includes one or more operating devices, or such a controller. . In this example, the profile generation unit 1206 may be a controller operation system and control software executed by one or more processors existing on the main control unit 1202, or any functional component thereof. The profile generation unit 1206 may be a hardware component existing inside the main control unit 1202, such as a circuit board or an integrated circuit that exchanges data with other functional elements of the controller 1208. Other suitable examples of profile generator 1206 are also within the scope of some embodiments of this disclosure. For example, the profile generator 1206 is represented in FIG. 12 as an element integrated in the main controller 1202, but in some embodiments, the profile generator 1206 is an element separated from the main controller 1202. It may be. In such a configuration, the profile generator 1206 exchanges data with the main controller 1202 or other elements of the operating system via suitable communication means. The communication means includes, but is not limited to, a wired or wireless network, a wired data link, or such communication means.

  The exemplary operation control system 1200 also includes a motor drive unit 1222 that includes an operation control unit 1214 for controlling an operation device (eg, a motor (not shown)) according to an operation profile 1212 provided by the main control unit 1202. The motion profile 1212 determines a trajectory for moving the motion device from the current position or speed to the target position or speed. Here, the trajectory is determined from one or more viewpoints among a position reference, a speed reference, an acceleration reference, and a jerk reference. In response to receiving motion profile data from main controller 1202, motor controller 1214 converts motion profile 1212 to control signal 1216, which causes the motion device to transition to a target position or target speed. Sent to the operating device. If the motor controller 1214 is a closed loop controller, while outputting the control signal 1216, the motor controller 1214 also monitors a feedback signal 1220 that indicates the actual state of the operating device (eg, real time position, speed, etc.). To do. The motor control unit 1214 adjusts the control signal 1216 based on the feedback signal 1220 so that the operating device moves as close to the operating profile 1212 as possible according to the operating profile 1212. In addition, if the motor control unit 1214 is an open loop controller, the motor control unit 1214 continues to generate the control signal 1216 based on the operation profile 1212. As a result, while the operation device is operating, the feedback signal 1220 is generated. Never monitor.

  In this example, the main control unit 1202 controls the system according to a control program 1210 stored and executed in the main control unit 1202. During operation, the control program 1210 requires the operating device to move to a new position or transition to a new speed. The target position and speed 1208 are given to the profile generation unit 1206, and the profile generation unit 1206 calculates the motion profile 1212 to determine the movement trajectory. The profile generator 1206 calculates the motion profile 1212 as a function of one or more motion constraints 1204 that represent the user's preference regarding motion of the motion system or motion of the motion device. The operation constant 1204 is given by the user before the operation (for example, via the interface unit 1108 in FIG. 11). In some embodiments, as will be described in detail below, the profile generator 1206 may additionally include a main controller 1202 to ensure that the segments of the profile match the controller sample points. An operation profile 1212 can also be calculated based on the sampling time 1218.

  As will be described in more detail below, the motion profile 1212 determines a trajectory with respect to the time of movement between two points as a reference position criterion, a velocity criterion, an acceleration criterion, and a jerk criterion. These reference values represent the functions calculated by the motion profile generator 1206 and determine how the characteristics of each motion are controlled as a function of time for a given point-to-point movement. These reference values have a mathematical correlation as differential coefficients. That is, jerk is a differential coefficient of acceleration, acceleration is a differential coefficient of speed, and speed is a differential coefficient of position. As will be discussed in detail below, the profile generator 1206 can calculate these reference values for each stage of the trajectory profile.

  Once the motion profile 1212 for movement is calculated, the profile generation unit 1206 gives the motion profile 1212 to the motor control unit 1214, and the motor control unit 1214 converts the motion profile 1212 into a control signal 1216. The control signal 1216 instructs the operating device to perform the desired point-to-point movement according to the operating profile 1212. As described above, if the motor control unit 1214 is a closed loop controller, the control signal 1216 is a function of the operation profile 1212 and at the same time, the feedback signal 1220 that informs the motor control unit 1214 of the actual state of the operation device in real time. It is also a function. For an open loop controller, the control signal 1216 is a function of the motion profile 1212 only.

  The configuration depicted in FIG. 12 is intended only to illustrate the background in which the profile generator 1206 operates, and other operating environments are included in this disclosure. For example, in some scenarios, the main control unit 1202 may include a controller that integrates a function capable of controlling a motor. In such a form, the main control unit 1202 converts the operation profile 1212 into a suitable control signal 316 and sends the control signal 1216 to the operation device rather than providing the operation profile 1212 to the separated motor drive unit 1222. In other exemplary structures, the profile generator 1206 may be integrated into the motor driver 1222.

  The profile generation unit 1206 may be either or both of a position profile generation unit and a speed profile generation unit. These two types of profile generators are represented in FIGS. 13 and 14, respectively. As shown in FIG. 13, the position profile generator 1302 receives as input a set of constraints 1304 representing the user's preferences regarding the mechanical constraints of the controlled system or the behavior of the operating system. These constraints include sampling time, speed, acceleration, deceleration, and jerk limits that represent the updated period of the controller control signal (usually measured in milliseconds). In some embodiments, the position profile generator 1302 automatically determines the controller's sampling time, although these constraints may be set by the user (eg, via the interface unit 1108 of FIG. 11). . These constraints 1304 may be set once while preparing the operation control system, or may be reconfigured for each operation. The position profile generation unit 1302 allows acceleration and deceleration limits in order to provide a profile having asymmetric acceleration and deceleration, respectively. As will be described in detail below, this sampling time is used by the profile generation unit 1302 to improve the accuracy of the operation profile.

  During operation, the position profile generator 1302 receives a position step command 1308 that identifies a new target position for the operating system. The position step command 1308 may be generated by a control program executed by the controller (for example, the control program in FIG. 12) or may be an operation command manually input by the user. In response to the position step command 1308, the position profile generation unit calculates a temporally optimized motion profile 1306 based on the constraints. The motion profile 1306 defines a trajectory for moving the load from its current position to the target position defined by the position step command 1308. The motion profile 1306 includes one or more of a jerk criterion, an acceleration criterion, a velocity criterion, and a position criterion. These have a mathematical correlation as differential coefficients. The position profile generator 1302 defines these criteria as a function of time for each determined motion profile stage or segment combination. Table 1 summarizes the seven segments of the motion profile between two points.

  Initially, during the first stage (ACC_INC), the acceleration increases continuously from zero to a constant acceleration. In some scenarios, this constant acceleration is the maximum acceleration defined by constraint 1304. However, in a relatively short position step, the position profile generator 1302 will reveal that a small acceleration results in a more accurate transition to the target position. In the second stage (ACC_HOLD), the acceleration is held at a constant rate. When the system approaches the target speed calculated by the position profile generation unit 1302, a third stage (ACC_DEC) is entered in which the acceleration gradually decreases until a constant speed is reached. When a constant speed is reached, this constant speed is maintained during the fourth stage (VEL_HOLD) so that the system approaches the target position. As the system approaches the target position, the trajectory enters the fifth stage. In the fifth stage, the system begins to decelerate, gradually increasing the rate from zero to the target deceleration defined by the motion profile. When the target deceleration is reached, this deceleration is held during the sixth stage (DEC_HOLD). Finally, during the seventh stage (DEC_DEC), the deceleration gradually decreases until the system reaches zero speed, ending the operation sequence.

  When the position step command 1308 is given, the position profile generation unit 1302 determines which one of these seven profile segments is necessary for the temporally optimized motion profile, and changes the time-varying jerk. One or more of the criteria, acceleration criteria, velocity criteria and position criteria are calculated for each segment deemed necessary for motion. The criteria calculated for each stage are combined to complete the motion profile. The completed motion profile can be used in an open loop or closed loop motion controller (eg, motor drive) to drive the motion system through the trajectory determined thereby.

  FIG. 14 illustrates an example of a speed profile generator 1402 according to one or more embodiments. The speed profile generator 1402 is similar to the position profile generator 1302 but is used to calculate a motion profile that responds to a desired change in speed rather than a change in position. That is, the speed profile generation unit 1402 calculates a temporally optimized motion profile 1406 for the transition of the motion system from the current speed to the target speed specified by the speed set point 1408. Since the transition to the desired speed setpoint is usually independent of the position of the operating system, the constraint 1404 defined for the speed profile generator 1402 may not include position limits. Similarly, the motion profile 1406 generated by the profile generation unit 1402 may not include a position reference, and is exclusive from at least one of a time-varying jerk reference, an acceleration reference, and a speed reference. The operation profile may be determined.

  In some motion control applications, the motion controller generates either a trapezoidal motion profile or an S-curve profile. In addition to or instead of these profiles, the profile generation unit according to the present disclosure can generate a third type profile referred to as an ST profile hereinafter. FIG. 15 compares an example of a normal trapezoidal and S curve profile with an ST curve profile. The time graph shown in FIG. 15 shows the position and speed for a given trajectory between position 0 (disclosed position) and position 2.5 (target position determined by the position step command 1308 in FIG. 13). , Acceleration and jerk plots. As is generally understood, the plotted values are mathematically related to each other as derivatives. That is, speed is a derivative of position (ie, rate of change of position), acceleration is a derivative of speed, and jerk is a derivative of acceleration.

  The trapezoidal motion profile only uses three of the above seven stages, constant acceleration (second stage), constant speed (fourth stage) and constant deceleration (sixth stage). The result of the trapezoidal velocity profile is represented by a broken line velocity curve in FIG. The steep subsequent between the constant acceleration phase or constant deceleration phase and the constant speed phase results in a sharp corner at the top of the trapezoidal velocity curve. The acceleration and deceleration phases of the trapezoidal profile are always constant, and the acceleration curve for this profile changes stepwise between constant values, as represented by the dashed line in the acceleration graph. In this example, the rate of deceleration is twice the rate of acceleration, and the acceleration curve in the trapezoidal case is 0.5 during the acceleration phase, 0 (zero) at the constant speed phase, and the deceleration phase. Then, it is -1.0. The jerk curve (representing the rate of change in acceleration and deceleration) is a short pulse (not plotted) during the transition, and the acceleration or deceleration is constant as represented by the dashed line in the jerk graph of FIG. At time, it remains zero.

  Because the trapezoidal profile always accelerates to a constant speed step at a constant rate and decelerates from a constant speed step to a constant rate without a gradual transition, the trapezoidal curve profile is between the current position and the target position. Move relatively quickly. However, the abrupt transition between the acceleration or deceleration phase and the constant speed phase causes undesirable mechanical disturbances of the system. In addition, the trapezoidal motion profile is the first transition because the motion system does not slow down gradually as it approaches the target position, maintains a constant deceleration until it reaches the target position, and then suddenly moves to zero speed. It is likely that the target position will be passed at the end of the process, and the controller needs to output a compensation control signal that returns the load to the target position. This process is repeated several times until the system has settled to the target position, causing undesirable vibrations of the system.

  In contrast to the trapezoidal profile, the S-curve profile (represented by a thin solid line in the graph of FIG. 15) uses all seven successive acceleration and deceleration phases of the profile phase. This allows a gradual transition between a constant (or zero) speed phase and a constant acceleration and deceleration phase. These gradual acceleration transitions are clearly represented in the acceleration graph. Instead of starting at a constant acceleration from time 0 (zero) as in the trapezoidal profile, the acceleration of the S-curve profile gradually increases from time 0 (zero) to a constant acceleration. When the speed reaches a maximum (between 1s and 2s), the acceleration does not decrease steeply to zero as in the trapezoidal case, but gradually decreases to zero to obtain a constant speed. A similar step change in acceleration is also seen in the deceleration phase after the S-curve profile. The effects of these stepwise acceleration changes can be seen in the velocity and position graphs, respectively. Specifically, the corner of the speed profile of the S curve is rounded compared to the trapezoidal curve, representing a smooth transition between acceleration and deceleration stages and a constant speed stage. Similarly, the S-curve position profile shows a smooth transition between the initial position and the target position, but spends additional time to reach the target.

  One or more embodiments of the profile generator described herein support generation of S-curve motion profiles. Typically, motion control systems that use S-curve motion profiles only support contrasting acceleration and deceleration. That is, the absolute values of constant acceleration and constant deceleration are equal. In contrast, the profile generator described herein can support an S-curve motion profile having asymmetric acceleration and deceleration. This is represented in the acceleration graph of FIG. 15 and represents an S curve having a limit of 0.5 for acceleration and a limit of −1 for deceleration. In order to provide such asymmetric acceleration and deceleration, the profile generator allows different acceleration and deceleration limits (see, for example, constraint 1304 in FIG. 13) as system constraints, and these The operation profile is calculated in consideration of the constraints.

  As represented in the jerk graph, in the case of the S curve, the rate at which the step acceleration increases and the deceleration decreases during the first, third, fifth and seventh stages of the motion profile is always the same. is there. That is, in this example, at any stage of the motion profile, the jerk is either 1, 0 or −1 and is always a constant value. This results in a steep transition between an increasing or decreasing acceleration (or deceleration) phase and a constant acceleration phase, as represented in the acceleration graph.

  In order to obtain a smoother operation than the trapezoidal and S-curve profile of a normal motion control system that obtains a time-optimized transition between positions, the profile generator according to one or more embodiments described herein includes: An operation profile according to the ST curve type profile can be calculated. An example of the ST curve profile is represented by a thick solid line in the graph of FIG. In contrast to trapezoidal and S-curve profiles, in the ST-curve profile, the change in jerk over time is continuous and gradual in increasing and decreasing acceleration and deceleration. As a result, the transition of acceleration in the acceleration graph of FIG. 15 becomes smooth, and the velocity and position curves respectively shown in the velocity and position graphs correspondingly become smooth.

  In addition, the ST curve profile can support asymmetric acceleration and deceleration. (Ie, the profile generator can calculate a profile having an acceleration rate that differs from the rate of deceleration for a given motion profile.) While finding a temporally optimized solution, a function of time Deriving a mathematical trajectory representation as is a challenge when using asymmetric acceleration and deceleration. To solve this, one or more embodiments of the profile generator described herein include an algorithm that utilizes the relationship between acceleration and deceleration and the relationship between jerk during acceleration and jerk during deceleration. And apply these relationships to the derivation process. This makes it possible to derive an analytical expression of the trajectory and find a solution that is optimized in terms of time.

  An example of the position profile of the ST curve is derived below. One or more embodiments of the profile generation unit described herein can generate a reference for an operation profile based on the following derivation process. However, the profile generator described here is not limited to this technique for generating motion profiles based on ST curves, and any suitable jerk curve that is defined as a function of time. It should be understood that the algorithm is within the scope of this disclosure.

In the following equations, θ ^... , Θ ^·· , θ ^·, and θ are jerk, acceleration, velocity, and position, respectively, and t ₁ , t ₂ , t ₃ , t _4, and t ₅ are respectively The duration of the ACC_INC, ACC_HOLD, VEL_HOLD, DEC_INC, and DEC_HOLD phases (see Table 1) of the operation profile. In this example, it is assumed that the durations of ACC_INC and ACC_DEC are equal. That is, t ₁ is the duration of both the ACC_INC and ACC_DEC phases. Similarly, the duration of DEC_INC, the same as DEC_DEC, _{t 4} is the time duration of both DEC_INC and DEC_DEC. K is a gain value determined for each stage in each motion profile of jerk, acceleration, speed and position according to the following equation. (Here, for each of the seven stages, t = 0 represents the start time of each stage.)

Given these relationships, the maximum acceleration jerk, the maximum deceleration jerk, the maximum acceleration, the maximum deceleration and the maximum speed can be represented by the duration of the segment.
Here, P is a position step, Je is a maximum acceleration jerk, I is a maximum deceleration jerk, A is a maximum acceleration, D is a maximum deceleration, and V is a maximum speed.

P, V, A, _D, Je, the relationship between _{I, t 1, t 2,} t 3, t 4 and _{t 5} are obtained as follows.

Assuming that t ₁ , t ₂ , t ₃ , t ₄ and t ₅ are all equal to or greater than 0 (zero), the following relationship is assumed:
The following inequality holds.
By solving the inequalities (33) to (36), appropriate values of V, A, D, Je and I (maximum values of velocity, acceleration, acceleration jerk and deceleration jerk) are obtained.

By substituting these maximum values into the equations (25) to (29), the values of t ₁ , t ₂ , t ₃ , t ₄ and t ₅ can be obtained. The values of V, A, D, Je, I, t ₁ , t ₂ , t ₃ , t ₄ and t ₅ derived from the above equations (14) to (36) are determined mechanical constraints. Alternatively, it provides a smooth trajectory that is optimized in time and operates within the range of the user's request.

Based on the above relationship, the profile generation unit can calculate a motion profile of a suitable ST curve for a given movement between two points. However, the initially calculated values for t ₁ , t ₂ , t ₃ , t ₄ and t ₅ are not multiples of the controller sampling time and will consequently not match the operating controller sample points. If the duration of the profile segment falls between the two sample times of the controller, the controller will need to compensate for the small difference between the desired output of the control signal and the actual output of the control signal. . In order to solve this point, one or more embodiments of the profile generator described herein include, as described above, maximum values V, A, D, Je and I and segment durations t ₁ , t After deriving ₂ , t ₃ , t ₄ and t ₅ , additional calculations are performed.

Specifically, after the profile generation unit calculates t ₁ , t ₂ , t ₃ , t ₄ and t ₅ according to the above procedure, the respective durations are upwardly corrected to the nearest sampling time, and t _1New , t _2New , t _3New , t _4New and t _5New are obtained. This modification step can be based on the sampling time given to the profile generator as one of the constraints 1304 or 1404. Then, the profile generation unit calculates new values of V, A, D, Je, and I using the values of the modified durations t _1New , t _2New , t _3New , t _4New, and t _5New . This calculation results in a final motion profile that includes the duration of the segment that is a multiple of the sampling time, and ensures that the control signal output from the controller matches the sample point of the controller. This can reduce the need for compensation for small differences that occur when the time of the motion profile falls between two sample points.

  Instead of or in addition to the ST curve described above, one or more embodiments of the profile generator described herein can generate an S-curve profile having asymmetric acceleration and deceleration. An example of an S-curve profile with asymmetric acceleration and deceleration is derived below. One or more embodiments of the profile generator described herein can generate a reference for an operation profile based on the following procedure or variations thereof.

As in the above ST curve equation, θ ^... , Θ ^·· , θ ^·, and θ are jerk, acceleration, velocity, and position, respectively. t ₁ , t ₂ , t ₃ , t _4, and t ₅ are the respective durations of the ACC_INC, ACC_HOLD, VEL_HOLD, DEC_HOLD, DEC_INC, and DEC_HOLD stages of the operation profile (see Table 1). Similar to the illustrated ST curve, the durations of ACC_INC and ACC_DEC are the same, and t ₁ is the duration in both stages of ACC_INC and ACC_DEC. Similarly, the duration of DEC_INC is the same as DEC_DEC, _{t 4} is the time duration of both DEC_INC and DEC_DEC. K is a gain value determined for each stage of the motion profile for each of jerk, acceleration, velocity and position according to the following equation: (Here, for each of the seven stages, t = 0 represents the start time of each stage.)

Given these relationships, the maximum acceleration jerk, maximum deceleration jerk, maximum acceleration, maximum deceleration, and maximum speed are represented by the duration of the segment.
Here, P is a position step, Je is a maximum acceleration jerk, I is a maximum deceleration jerk, A is a maximum acceleration, D is a maximum deceleration, and V is a maximum speed.

P, V, A, _D, Je, the relationship between _{I, t 1, t 2,} t 3, t 4 and _{t 5} are obtained as follows.
Assuming that t ₁ , t ₂ , t ₃ , t ₄ and t ₅ are all equal to or greater than 0 (zero), the following relationship is assumed:
The following inequality holds.

  By solving the inequalities (53) to (56), appropriate values of V, A, D, Je and I (maximum values of velocity, acceleration, current velocity, acceleration jerk and deceleration jerk) for the S curve profile are obtained. can get.

By substituting these maximum values into the equations (47) to (51), values of t ₁ , t ₂ , t ₃ , t ₄ and t ₅ (the duration of each segment of the S-curve motion profile) are obtained. be able to. The values of V, A, D, Je, I, t ₁ , t ₂ , t ₃ , t ₄ and t ₅ derived according to the above equations (37) to (56) give asymmetric acceleration and deceleration. It is possible to create an S-curve profile that has a predetermined mechanical constraint or operates within a range required by the user.

In some embodiments, the profile generator adapts the resulting S-curve motion profile to the controller sampling time in a manner similar to the additional calculations described above in connection with the ST curve profile. That is, after calculating t ₁ , t ₂ , t ₃ , t _4, and t ₅ according to the above procedure, the profile generation unit extends the respective durations according to the nearest sampling time, and t _1New , t _2New. , _T3New , _t4New and _t5New . Then, the profile generation unit calculates new values of V, A, D, Je, and I using the values of the modified durations t _1New , t _2New , t _3New , t _4New, and t _5New .

  A motion profile typically includes the seven stages listed in Table 1, but several two-point movements may not require all seven segments. For example, when the distance between the current state of the operating system and the target state is relatively short, the VEL_HOLD (constant speed) segment of the operating system may be omitted. Accordingly, in one or more embodiments of the profile generator described herein, segment skipping may be performed automatically or functionally. That is, if one or more stages are not used in the final trajectory rather than performing calculations for all seven stages of the profile, in some embodiments of the profile generator described herein, For a given movement between two points, calculations can only be made for the stage used for the final trajectory.

  The motion profile automatically determines which segments can be skipped during the motion profile calculation when a new motion command is received. In some embodiments, the profile generator is somewhat dependent on the overall difference between the current position and the target position (for position change) or between the current speed and the target speed (for speed change). Based on this, it can be determined which segments can be skipped, and the smaller the difference between the current state and the target state, the more segments of the motion profile can be omitted. In such an embodiment, the difference between the current state and the target state is compared to a plurality of defined difference ranges, each defined difference range being omitted from the corresponding motion profile. Associated with one or more segments.

  One or more embodiments of the profile generator described herein may estimate which segments can be skipped based on a history of motion data. For example, the profile generation unit may output the history of the motion command and the data of the trajectory corresponding to the motion in response to the command (for example, data for position, speed, acceleration and jerk, or any time) May be recorded. The profile generator can analyze this historical data to make inferences about which segments can be omitted for a particular type of operation. Therefore, when a new movement command between two points is received, before the motion profile for that movement is calculated, the profile generator may receive similar characteristics (eg, similar distance to be traversed, motion command received). It is possible to estimate which segments can be skipped based on the shape of the trajectory executed in response to a past motion command having a similar speed).

  16 to 19 show the segment skip of the illustrated seven-stage position profile. FIG. 16 represents an example of an S-curve profile using all seven stages. FIG. 17 shows a profile in which segment 4 (constant speed step) is skipped. The profile generator can calculate such a profile if the traversed position or speed step is small enough and does not reach a constant speed step before reaching the target position or speed. Upon receiving such a position step or speed set point command, the profile generator can make this determination before performing the profile calculation for the desired operation, with steps 1-3 and 5-7. Perform only the calculation for the stage. Similarly, FIG. 18 shows an example of a profile in which segments 2 and 6 are skipped, and FIG. 19 shows an example of a profile in which segments 2, 4 and 6 are skipped.

  20-22 illustrate a procedure according to some disclosed aspects. For ease of explanation, the procedures are shown and described as a series of actions, but the disclosed aspects are not limited to the order of the actions, and some actions are shown and described herein. It should be understood and recognized that they may be performed concurrently with other actions in a different order than those, or any of them. For example, those skilled in the art will understand and appreciate that a procedure is selectably represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all displayed acts may be required to perform a procedure in accordance with some disclosed aspects. It should be further appreciated that the procedures set forth below throughout this disclosure can be stored in a product that facilitates the transfer of such procedures to a computer.

  FIG. 20 shows an example procedure 2000 for calculating an operation profile for movement between two points in the operation control system. In step 2002, operation constraint conditions are determined for the operation control system. These constraints represent the physical constraints of the mechanical system controlled by the motion control system and can include speed, acceleration, deceleration and jerk limits. The constraints can include a definition of the motion controller sampling time used to control the mechanical system. In step 2002, a command is received that causes the controlled mechanical system to transition to a new position or speed. This command may be caused by an operation control program executed by the operation controller, or may be a manual operation command input by the user. The command may be received by a profile generation unit (for example, the profile generation unit 1206, 1302, or 1402 described above) related to the motion controller.

  In step 2006, in response to receiving the command received in step 2004, a motion profile is calculated to move the mechanical system from the current position or speed to the new position or speed indicated by the command. The profile generator may calculate the motion profile to include a continuous jerk criterion defined as a function of time for at least one of the motion profile segments. In some embodiments, the motion profile can be calculated as an ST curve according to the procedure described above in relation to equations (14)-(36). Such a motion profile provides a jerk criterion having the general form depicted by the jerk graph represented by the bold solid line in FIG. 15, where the jerk is a maximum and minimum value according to the calculated jerk function. It changes slowly over time. In step 2008, the controlled mechanical system is instructed to transition from the current position or speed to a new position or speed according to the motion profile defined in step 2006. Along with this, for example, the operation profile calculated in step 2006 is given to the motor drive unit, and the motor that drives the mechanical system according to the feedback profile that gives the operation profile and real-time data representing the state of the mechanical system. To control.

  FIG. 21 illustrates an example procedure 2100 for calculating a temporally optimized motion profile that is tuned to the motion controller sampling time and based on constraints. In step 2102, constraints on the mechanical system to be controlled are established. As in the previous example, these include the sampling time of the controller and the speed, acceleration, deceleration and jerk limits. These constraint conditions can be given to a profile generation unit (for example, the profile generation unit 1206, 1302, or 1402 described above) related to the controller. In step 2104, a command is received (eg, by the profile generator) that causes the machine system to transition from the current position or speed to a new position or speed. In step 2106, at least one of a maximum acceleration jerk (Je), a maximum deceleration jerk (I), a maximum acceleration (A), a maximum deceleration (D) and a maximum velocity (V) is determined for each segment of the motion profile. By calculating as a function, an operation profile for controlling the trajectory of the mechanical system is generated in response to the command. (Here, the profile can include the seven segments defined in Table 1.) In addition, the duration of each segment of the profile (eg, the above described in relation to equations (14)-(36)). Calculated using technology).

  In step 2108, it is determined whether the duration of all profile segments calculated in step 2106 is a multiple of the controller sampling time. If the duration is a multiple of the sampling time for all segments, then go to step 2114 and based on the profile segment duration and the values of Je, I, A, D and V calculated in step 2106 Generate. On the other hand, if one or more profile segments are not equal to a multiple of the cycle time, the process moves to step 2110 where the duration of all profile segments is upwardly modified to the nearest multiple of the sampling time. In step 2112, one or more values of Je, I, A, D and V are recalculated based on the duration of the profile segment modified in step 2110. In step 2114, a motion profile is generated based on the modified profile segment duration and / or the recalculated Je, I, A, D and / or V.

  FIG. 22 shows an example procedure 2200 for effectively calculating an operation profile for movement between two points using segment skip. In step 2202, a command is received (e.g., at profile generator 1206, 1302, or 1402) that causes the controlled mechanical system to transition to a new position or a new speed. In step 2204, it is determined which of the seven segments of the motion profile are required to perform the requested movement between the two points. This determination is based on, for example, measuring the distance to be moved between the current position and the desired position (in the case of a position change) or the difference between the current speed and the desired speed (in the case of a speed change). Automatically performed by the profile generation unit.

  In step 2206, based on the determination in step 2204, it is determined whether all seven segments are required to perform the desired operation. If all segments are determined, move to step 2210 to generate a motion profile for movement between two points by performing profile calculations on all seven segments. On the other hand, if it is determined in step 2206 that one or more profile segments are not required, the process moves to step 2208, and as determined in step 2204, the calculation is performed only for the necessary segments, so that Generate an action profile for movement of Segment skipping according to example procedure 2200 more efficiently facilitates calculation of temporally optimized motion profiles based on constraints by reducing extra processing associated with unnecessary profile segment calculations To do.

[Example of networked and distributed environment]
Those skilled in the art will appreciate that some embodiments described herein may be any part of a computer network or any distributed storage environment that is connected to any data storage device including media. It will be appreciated that implementation is possible using a computer, client device, or server device. In this regard, some embodiments of the image editing system described herein may include any number of memories or storage devices (eg, memory 216 in FIG. 2 or memory 1112 in FIG. 11) and any number of storage devices. Can be implemented in any computer system or environment with any number of applications and processes using. This includes, but is not limited to, an environment with server computers and client computers having remote or local storage devices located in a network environment or a distributed computing environment. For example, referring to FIG. 2, the torque command generation unit 204, the speed monitoring unit 206, the inertia calculation unit 208, the friction coefficient calculation unit 210, and the interface unit 212 are stored in one memory 216 related to one device. Can do. It may also be distributed over multiple memories associated with each of multiple devices. Similarly, the torque command generation unit 204, the speed monitoring unit 206, the inertia calculation unit 208, the friction coefficient calculation unit 210, and the interface unit 212 may be executed by one processor 214, or many related to a large number of devices. You may perform using the processor of.

  In the distribution of computation, computer resources and computer services are shared by communication between the computing device and the computing system. These resources and services include the exchange of information of interest, cache and disk storage. These resources and services also include sharing the processing power of multiple process units for load balancing, resource expansion, processing dedication, and the like. Distributed computing has advantages in network connectivity and allows clients to use the collective power to benefit the entire enterprise. In this regard, some devices have applications, objects, or resources that can contribute to some embodiments of this disclosure.

  FIG. 23 is a schematic diagram illustrating a networked and distributed computing environment. The distributed computing environment includes computing objects 2310, 2312, etc., and computing objects or computing devices 2320, 2322, 2324, 2326, 2328, etc., each of which is provided by applications 2330, 2332, 2334, 2336, 2338, respectively. As represented, it includes programs, methods, data storage devices, programmable logic, and the like. Arithmetic objects 2310, 2312, etc. and arithmetic objects or arithmetic devices 2320, 2322, 2324, 2326, 2328, etc. are PDAs (personal digital assistants), auditory and visual devices, mobile phones, MP3 players, personal computers, notebook computers, Inertia estimator embodiments described herein, including tablets and the like, reside on and interact with such devices.

  The calculation objects 2310 and 2312 and the calculation objects or calculation devices 2320, 2322, 2324, 2326, and 2328 are respectively calculated as calculation objects 2310 and 2312 and the calculation objects or calculation devices 2320, 2322, 2324, 2326, 2328 or other devices such as 2328 may communicate directly or indirectly via communication network 2340. Although represented as one element in FIG. 23, the communications network 2340 may include other computing objects and computing devices that provide services to the system of FIG. It may be a network. Each of the computing objects 2310 and 2312 and the computing object or computing device 2320, 2322, 2324, 2326, 2328, etc., communicates with, or is suitable for execution of, some embodiments of this disclosure, or Of applications 2330, 2332, 2334, 2336, 2338 (eg, inertia estimator 202, motion profile generation system 1102 or elements thereof) that use other objects, software, firmware and / or hardware Such an application program can also be included.

  There are several system, element and network configurations that support a distributed computing environment. For example, the computing system can be coupled together by a wired or wireless system, a localized network or a widely distributed network. Currently, many networks are provided as a social infrastructure that can widely distribute operations and are connected to the Internet, which encompasses many different networks. And in some embodiments, any suitable network infrastructure can be used for the exemplary communications associated with the system, as described herein.

  As described above, a client / server, peer-to-peer (P2P) or hybrid structure is used as a network topology and network-based host. A client is a member of a hierarchy or group that uses services of another hierarchy or group. A client may be a set of instructions or tasks that seek a service provided by a computer process, eg, another program or process. The client process uses the requested service without knowing all the work details about the other program or service itself.

  In a client / server structure, particularly a network system, a client may be a computer that accesses network resources provided and shared by other computers, eg, servers. Any computer can be considered a client, a server, or both depending on the environment, but in FIG. 23, as non-limiting examples, computing objects or computing devices 2320, 2322, 2324, 2326, 2328, etc. Can be considered as clients, and the computation objects 2310, 2312, etc. may be considered as servers. Here, the computation objects 2310 and 2312 receive data from the client computation object or the client computation devices 2320, 2322, 2324, 2326, 2328, etc., store the data, process the data, and execute the client computation object or the client computation device. A data service that transmits data to 2320, 2322, 2324, 2326, 2328, etc. is provided. As described herein for one or more embodiments, any of these computing devices may process data and request transaction services or tasks related to the technology of the system.

  The service is usually a remote computer system that can be accessed via a remote or local network, such as the Internet or a wireless network infrastructure. Client processing is available in the first computer system, and server processing is available in the second computer system. The first computer system and the second computer system communicate with each other via a communication medium. Therefore, it is possible to provide a distributed function and allow many clients to use the information collection capability of the server. Arbitrary software used in conformity with the technology described here may be provided independently, or may be distributed to a number of arithmetic devices or arithmetic objects.

  For example, in a network environment where the communication network / bus 2340 is the Internet, the computation objects 2310, 2312, etc. may be web servers, file servers, media servers, etc., and client computation objects or computation devices 2320, 2322, 2324, 2326, 2328, etc. communicate via a known protocol such as HTTP (hypertext transfer protocol). The computing objects 2310, 2312, etc. may function like client computing objects or client computing devices 2320, 2322, 2324, 2326, 2328 to characterize the distributed computing environment.

[Example of arithmetic unit]
As mentioned above, the techniques described herein can be advantageously applied to any suitable device. Thus, it should be understood that all types of use, such as portable computing devices and other computing devices, computing objects, etc. are expected in connection with some embodiments. Therefore, the computer described in FIG. 24 is an example. In addition, suitable servers can include one or more aspects of the following computers, such as media servers or other media management server elements.

  Although not required, embodiments may be implemented in part through an operating system for use by a developer of a device or instrument service, and some may be described herein. It may be included in the scope of application software that operates to implement one or more functional aspects of the embodiments. Software may be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers or other devices. Those of skill in the art will recognize that computer systems should not be limited to a particular configuration and protocol because they have different configurations and different protocols used for data communication.

  FIG. 24 illustrates an example of a suitable computing system environment 2400 that can implement one or more aspects of the embodiments described herein. As noted above, the computing system environment 2400 is only one example of a suitable computing environment and is not intended to limit any scope of use and functionality. It is to be understood that the computing system environment 2400 does not have any dependency or requirement associated with any of the elements depicted in the exemplary computing system environment 2400 or the combination thereof.

  With reference to FIG. 24, an exemplary computing device implementing one or more embodiments in the form of a computer 2410 will be described. The components of computer 2410 include, but are not limited to, process unit 2420, system memory 2430, and system bus 2422 that couples several components including system memory to process unit 2420. The process unit 2420 performs functions related to the processor of the inertia estimator 202, for example, and the system memory 2430 performs functions related to the memory 216.

  Computer 2410 typically includes a number of computer readable media, ie, any available media that can be accessed by computer 2410. The system memory 2430 may include volatile and non-volatile memory such as read only memory (ROM) and random access memory (RAM), or any form of computer storage medium. By way of example and not limitation, the system memory 2430 may store an operating system, application programs, other program modules, and program data.

  A user can enter commands and information into computer 2410 via input device 2440. Input device 2440 includes, but is not limited to, a keyboard, keypad, pointing device, mouse, touch pen, touch pad, touch screen, trackball, motion detector, camera, microphone, joystick, game pad, scanner, or user with a computer Any device that can interact can be included. A monitor or other type of display device is also connected to the system bus 2422 via an interface, such as an output interface 2450. In addition to the monitor, the computer can include other peripheral output devices such as speakers and printers connected via an output interface 2450. In one or more embodiments, the input device 2440 can provide user input to the interface unit 212, and the output interface 2450 can receive information related to the operation of the inertia estimator 202 from the interface unit 212.

  Computer 2410 may operate in a networked or distributed environment that is logically coupled to one or more other remote computers, such as remote computer 2470. The remote computer 2470 may be a personal computer, server, router, network personal computer (PC), peer device or other common network node, or any other remote media device or remote media transmission device. Any or all of the elements described in connection with computer 2410 may be included. The logical connections depicted in FIG. 24 include a network 2472, such as a local area network (LAN) or a wide area network (WAN), but may also include other networks / buses, such as a cellular network.

  As described above, exemplary embodiments have been described in connection with several computing devices and network structures, but the underlying concept is that media can be output or utilized in a less restrictive manner. It can be applied to any desired network system and any computing device or computing system.

  There are also many ways to achieve the same or similar functionality. For example, an appropriate API (Application Programming Interface), tool kit, driver code, operating system, control software, independent or downloadable software, and the like, enables applications and services using the technology described here. As described above, in the embodiment, it is expected that one or more modes described here are executed from the viewpoint of API (or other software having the same function) as in the case of software or hardware. Some embodiments described herein may be all hardware, some hardware, all software, and some software aspects.

  Here the word “exemplary” is used to mean an example or a schematic. For the avoidance of doubt, the embodiments disclosed herein are not limited to such examples. Moreover, by way of example, any aspect or design described herein is not necessarily to be construed as preferred or advantageous over other aspects or designs, and may exclude equivalent structures and techniques. Absent. Further, in order to avoid doubt, as long as “including”, “having” and other similar terms are used either in the detailed description or in the claims, such terms shall be “comprising”. Similar usage does not exclude any additions or other elements.

  The computing device typically includes a number of media including a computer readable storage media (eg, memory 216 or 1112) and / or communication media. As used herein, these two terms differ from each other as follows. Computer-readable media can be any available media that can be accessed by the computer and usually has non-transient properties, both volatile and nonvolatile, removable and Includes both non-removable ones. By way of non-limiting example, a computer readable storage medium can be any method or technique for storing information such as computer readable instructions, program modules, structural data, or unstructured data. Implemented in association. Computer-readable storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD (digital versatile disk) or other optical recording disk, magnetic cassette, magnetic tape, magnetic storage disk Or including, but not limited to, other magnetic storage devices, other specific and non-transitory media used to store desired information, or any of them. A computer readable storage medium may be used by one or more local or remote computing devices, eg, via access requests, search requests, or other data search protocols, for some operations relating to information stored therein. Accessed.

  Communication media, on the other hand, typically converts computer readable instructions, data structures, program modules or other structured or unstructured data into data signals such as modulated data signals which are carrier waves or other transport means. Integrate and include any information delivery or transport medium. The term “modulated data signal” or signal refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in one or more signals. By way of non-limiting example, communication media includes wired media such as wired networks or direct wire connections, and wireless media such as acoustic, high frequency, infrared and other wireless media.

  As described above, some techniques described herein may be implemented in connection with hardware or software, or a combination thereof, as appropriate. As used herein, terms such as “element”, “system” and the like further refer to elements associated with a computer that are either hardware, a combination of hardware and software, software, or execution of software. Intended. For example, the element may be a process executed by a processor, a processor, an object, an execution file, an execution thread, a program and / or a computer, but is not limited thereto. By way of illustration, both an application running on a computer and the computer can be an element. One or more elements may reside in the process and / or execution thread, and the elements may be localized on one computer or distributed across two or more computers. In addition, a “device” is a specially designed hardware, or a generalized implementation of software that causes the hardware to perform a specific function (eg, encoding and / or decoding). May be provided as hardware.

  The aforementioned system will be described in connection with the interaction of several elements. Such systems and elements include these elements or specified subelements, some of the specified elements or subelements, and any additional elements, or any of the above, some replacements It should be recognized that and follow the bond. The quasi-element may not be included in the parent element (hierarchical structure), but may be implemented as an element that is communicably coupled with another element. In addition, one or more elements may be combined into a single element that provides aggregate functionality, may be divided into several spaced subelements, and any such as a management layer It should be noted that one or more of the intermediate layers may be communicatively coupled to such sub-elements to provide integrated functionality. Any element described herein is not specifically described herein, but may interact with one or more other elements generally known to those skilled in the art.

  In order to provide or serve many of the interfaces described herein (eg, acoustic segments), the elements described herein test the entire or a subset of data authorized for access, and / or events and / or data. The state of the system, environment, etc. can be demonstrated or estimated from the observation results captured via The estimation can be used to determine a specific background or action, for example, to generate a probability distribution of states. The estimation may be probabilistic, i.e. a calculation of the probability distribution of the state of interest based on data and event considerations. Estimates can also refer to techniques used to construct higher-level events from events and / or data.

  Such an estimate is a set of observed and stored event data, and whether events correlate in temporary proximity, and events and data are one or several events and data A new event or action can be constructed from whether it originated from the source. A number of classification schemes and / or systems (either explicitly and implicitly provided or either) (eg, support vector machines, neural networks) , Expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, etc., perform automated and estimated operations related to the claimed subject matter. Can be used for implementation.

  The classifier maps the input attribute vector, x = (x1, x2, x3, x4... Xn) with a function f (x) and determines that the input belongs to one class. Such classification uses probabilistic and statistical analysis (eg, incorporation into analysis equipment and analysis costs) to predict or estimate the actions that the user desires to be performed automatically. A support vector machine (SVM) is an example of a classifier that can be used. SVM works by finding a hyper-surface in the possible input space. Here, the hypersurface divides the incentive criteria from non-incentive events. Intuitively, this corrects the classification for test data that is close but not identical to the training data. Other direct and indirect models for classification include naive Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, and Probabilistic classification models that give different patterns of independence can be used. The classification used here also includes statistical defects used to elucidate model priorities.

  In view of the exemplary system above, the procedures performed in accordance with the described subject matter may be better appreciated with reference to several flowcharts (eg, FIGS. 9, 10 and 20-22). For ease of explanation, the procedures are shown and described as sequential blocks, but the claimed subject matter is not limited by the order of the blocks, and some blocks are represented here. It should be understood and appreciated that the order may be different than that described, or may be executed concurrently with other blocks. Although a non-sequential branching flow is represented in the flowchart, it can be appreciated that some other branching, flow path and block ordering is performed, yielding the same or similar results. In addition, implementation of the procedure described below may not require all blocks.

  In addition to some of the embodiments described herein, other similar embodiments can be used and depart from the above embodiments to perform the same or similar functions of the corresponding embodiments. The modification and addition are possible. Further, multiple process chips or multiple devices can perform one or more functions described herein in concert, and storage across multiple devices is possible as well. Accordingly, the invention is not limited to any embodiment, but is capable of interpreting the breadth, spirit and scope of the appended claims.

Claims (20)

Generate a torque command signal that changes continuously over time,
Measuring speed data of the operating device representing the speed of the operating system in response to the torque command signal;
A motion system parameter estimation method for determining at least one of inertia and a coefficient of friction of the motion system based on at least a portion of the speed data and the torque command signal.   The operational system parameter estimation according to claim 1, wherein the determination is made based on at least a part of one or more integrals of the speed data in a time domain and one or more integrals of the torque command signal in the time domain. Law. Generating the torque command signal includes adjusting the torque command signal according to a predetermined test sequence;
The operating system according to claim 1 or 2, wherein the adjustment changes at least one of a direction or a rate of change of the torque command signal in response to the speed of the operating system that has reached a predetermined speed detection point. Parameter estimation method. In the determination, the first segment in the time domain is an acceleration phase, the second segment in the time domain is a deceleration region,
Integrating the torque command signal and the speed data in the acceleration phase, respectively, to obtain U _acc and V _acc ;
Integrating the torque command signal and the speed data in the acceleration phase to obtain U _dec and V _dec , respectively;
The method for estimating a parameter of an operating system according to claim 2 or 3, wherein at least one of the inertia and the coefficient of friction is determined as a function of U _acc , V _acc , U _dec and V _dec .
here,
u _acc (t) is a part of the torque command signal corresponding to the acceleration phase;
v _acc (t) is a part of the speed data corresponding to the acceleration phase;
u _dec (t) is a part of the torque command signal corresponding to the deceleration phase;
v _dec (t) is a part of the speed data corresponding to the deceleration phase. The determination of at least one of the inertia and the coefficient of friction includes at least one of determining the inertia according to the function and determining the coefficient of friction according to the function. Item 5. A parameter estimation method for an operation system according to Item 4.
Here, the function J representing the inertia is
And
The function B representing the friction coefficient is
And
Δv _acc (t) is the difference between the speed of the operating system at the end of the acceleration phase and the speed of the operating system at the start of the acceleration phase;
Δv _dec (t) is the difference between the speed of the operating system at the end of the deceleration phase and the speed of the operating system at the start of the deceleration phase.   The operating system parameter estimation method according to claim 1, wherein a control gain coefficient of the operating system is determined based on at least one of the inertia and the friction coefficient. Memory,
A processor that executes computer-executable elements stored in the memory,
The computer executable elements are:
A torque command generator that generates a torque command signal that continuously changes over time during the test sequence;
A speed monitor that acquires speed data representing the speed of the operating system in response to the torque command signal with respect to time;
An inertia calculation unit that estimates the inertia of the operating system based on the torque command signal and the speed data, and a friction coefficient calculation that estimates a friction coefficient of the operating system based on the torque command signal and the speed data At least one of the parts,
A parameter estimation system for an operating system including:   In a time domain that is at least part of the duration of the test sequence, at least one of the inertia calculator and the friction coefficient calculator is one or more integrals of velocity data in the time domain, and 8. The operating system parameter estimation system according to claim 7, wherein the inertia or the friction coefficient is estimated based on at least a part of one or more integrals of the torque command signal in the time domain. The torque command generator controls the torque command signal according to a torque function u (t) based on a predetermined command in relation to each phase of the test sequence;
The system according to claim 7 or 8, wherein each of the phases is started in response to the speed of the operating system that has reached a value of a speed detection point determined in each.
10. The motion system parameter estimation according to claim 8, wherein at least one of the inertia calculation unit and the friction coefficient calculation unit estimates the inertia as a function of U _acc , V _acc , U _dec, and V _dec. system.
here,
And
u _acc (t) is a part of the torque command signal corresponding to the acceleration phase of the test sequence;
v _acc (t) is a part of the speed data corresponding to the acceleration phase;
u _dec (t) is a part of the torque command signal corresponding to the deceleration phase of the test sequence;
v _dec (t) is a part of the speed data corresponding to the deceleration phase. The system according to claim 10, wherein the inertia calculation unit estimates the inertia based on the function.
Here, the function J representing the inertia is
And
Δv _acc (t) is the difference between the speed of the operating system at the end of the acceleration phase and the speed of the operating system at the start of the acceleration phase;
Δv _dec (t) is the difference between the speed of the operating system at the end of the deceleration phase and the speed of the operating system at the start of the deceleration phase. The system according to claim 10, wherein the friction coefficient calculation unit estimates the friction coefficient based on the function.
Here, the function B representing the inertia is
And
Δv _acc (t) is the difference between the speed of the operating system at the end of the acceleration phase and the speed of the operating system at the start of the acceleration phase;
Δv _dec (t) is the difference between the speed of the operating system at the end of the deceleration phase and the speed of the operating system at the start of the deceleration phase.   13. The parameter estimation system for an operating system according to claim 7, further comprising a tuning unit that generates at least one control gain coefficient as a function of at least one of the inertia and the friction coefficient. Receiving a set point indicating at least one of a target position and a target speed of the operating device;
Generating an operation profile for transferring the operation device to at least one of the target position and the target speed;
A method of generating a motion profile, wherein the motion profile defines a jerk criterion that continuously changes as a function of time for at least one segment thereof.   15. The generation of a motion profile according to claim 14, wherein the generation of the motion profile includes defining at least one of an acceleration criterion, a velocity criterion, and a position criterion as a function of time for the at least one segment. Method. The generating calculates at least one of the jerk criteria, velocity criteria and position criteria for each segment of the motion profile;
Calculating the duration of each segment of the motion profile;
Modify the duration to the nearest multiple of each of the motion controller sampling times;
The method according to claim 14 or 15, wherein the modified duration is used to recalculate at least one of the jerk criterion, the acceleration criterion, the deceleration criterion and the speed criterion. The generation is
The method for generating a motion profile according to claim 14, wherein the motion profile is generated in accordance with the relationship:
Where P is the position of the operating device, Je is the maximum acceleration jerk, I is the maximum deceleration jerk, A is the maximum acceleration, D is the maximum deceleration, and V is the maximum speed.
t ₁ is the duration of the stage in which the acceleration in the motion profile increases and decreases, t ₂ is the duration of the stage in which the acceleration of the motion profile is constant, and t ₃ is the stage of the constant speed of the motion profile. , T ₄ is the duration of the phase in which the deceleration in the motion profile increases and decreases, t ₅ is the duration of the phase in which the deceleration of the motion profile is constant,
ρ is
It is represented by Memory,
A processor that executes computer-executable elements stored in the memory,
The computer-executable element includes a motion profile generator that generates a motion profile in response to receiving a target position or target speed of the motion device;
The motion profile has a jerk criterion that varies continuously with time in at least one of its phases, and generates a motion profile that defines a trajectory for transitioning the motion device to the target position or the target speed. system. The motion profile generation unit generates a motion profile that depends on at least one defined constraint,
The system of claim 18, wherein the at least one defined constraint includes at least one of a sampling time, a speed limit, an acceleration limit, a jerk limit, and a deceleration limit. The motion profile generation unit
20. The motion profile generation system according to claim 18 or 19, wherein the motion profile is generated in accordance with the relationship:
Where P is the position of the operating device, Je is the maximum acceleration jerk, I is the maximum deceleration jerk, A is the maximum acceleration, D is the maximum deceleration, and V is the maximum speed.
t ₁ is the duration of the stage in which the acceleration in the motion profile increases and decreases, t ₂ is the duration of the stage in which the acceleration of the motion profile is constant, and t ₃ is the stage of the constant speed of the motion profile. , T ₄ is the duration of the phase in which the deceleration in the motion profile increases and decreases, t ₅ is the duration of the phase in which the deceleration of the motion profile is constant,
ρ is
It is represented by