KR20210095624A - Method and Apparatus for Calibrating Zero Rate Output of Sensors - Google Patents

Abstract

A method of correcting a zero rate offset (ZRO) of a first inertial sensor located in a device, the method comprising: determining a level of stability of the device based on information related to at least one non-inertial sensor located in the device; and performing ZRO correction of the first inertial sensor when the stability level is above the threshold.

Description

Method and Apparatus for Calibrating Zero Rate Output of Sensors

Related applications

This application is a US Provisional Patent Application No. 62/736,355 filed on September 25, 2018 under the title of "Method and Apparatus for Correcting Zero Rate Output of Sensors", "Method and Apparatus for Correcting Zero Rate Output of Sensors" U.S. Provisional Patent Application No. 62/779,336, filed on December 13, 2018, and U.S. Provisional Patent Application No. 62/856,953, filed on June 4, 2019, entitled “Method and Apparatus for Correcting Zero Rate Output of Sensors” All claims of priority from, relate to, and the contents of these three applications are hereby incorporated by reference.

background

Electronic devices containing so-called motion sensors, such as 9-axis sensors, in particular mobile devices, such as cellular telephones, digital cameras, GPS devices, laptop and palmtop computers, automobiles, robotic vacuums, etc. It is becoming increasingly popular and widespread. It is referred to as 9-axis because it contains a total of 9 sensors, including one gyroscope, one accelerometer and one magnetometer for each of the three orthogonal directions. A chip or other electronic component having such a motion sensor is commonly referred to as an IMU or inertial motion unit. A 3-D gyroscope measures angular velocity. A 3D accelerometer measures linear accelerations. A magnetometer measures the local magnetic field vector (or its deviation). Despite their popularity, the predictable capabilities of these 9-axis sensors are not fully exploited, among other things, because of the difficulty of correcting and eliminating undesirable effects from the sensor. For example, gyroscopes tend to be susceptible to a phenomenon well known as zero rate offset (ZRO), in which the output is non-zero (indicating rotation) when the gyroscope is not actually rotating. Magnetometers suffer from several different well-known noise factors, such as near-field interference, soft-iron effect, and hard-iron effect.

In addition, cell phones, virtual reality glasses and headsets, augmented reality glasses and headsets, television remote control devices and other 3-D pointing devices, and other portable communication devices are now commonly available with IMUs, including but not limited to gaming applications, It is used in the 3D field for many different uses, including the fields of virtual reality (VR) and augmented reality (AR), as well as photography and video graphics. An example of a 3D pointing device can be found in US Pat. No. 7,118,518 to Matthew G. Liberty (hereinafter referred to as the '518 patent), the disclosure of which is incorporated herein by reference.

The '518 patent describes, for example, a 3D pointing device comprising one or two rotation sensors and an accelerometer. Rotation sensor(s) are used to sense the angular velocity in the 3D pointing device being rotated by the user, as described in more detail below. However, the output of the rotation sensor(s) does not perfectly represent the angular velocity at which the 3D pointing device is being rotated, for example due to the aforementioned “zero rate offset” or the ZRO output of the sensor. For example, when the 3D IMU is not moving, the rotation sensor typically has a non-zero output due to ZRO. For example, when an IMU is integrated into a 3D pointing device used as an input device for a user interface to move a cursor or display a virtual reality scene, for example, when the user intends to hold the cursor in a stationary state , will have the unwanted effect of causing the cursor to drift across the screen. As another example, ZRO can cause the VR scene to drift when it should be stationary and cause the robot cleaner to move in the wrong direction. Therefore, it is highly desirable to estimate and remove ZRO from the sensor output. What makes this process more difficult is that the bias varies from sensor to sensor, even for individual sensors, and varies over time due to changes in temperature and/or aging.

Many ZRO algorithms do not directly solve for temperature gradients, they dynamically learn ZRO when the device is stable, i.e. at rest, and attempt to continuously improve this estimate.

Factory calibration of sensors that calibrate for temperature is common. However, this type of ZRO compensation has its drawbacks. For example, the device has a high calibration cost because it has to be measured at different temperatures. This requires more equipment than no calibration or performing a single temperature calibration, and takes substantially more time. Also, the temperature performance can change over time or when the device is mounted, so having a dynamic algorithm in the device can maintain a corrected temperature gradient.

PCT Published Patent Application 2018/118574, which is incorporated herein by reference in its entirety, discloses a method and apparatus for performing ZRO compensation that directly resolves the temperature gradient of ZRO.

summary

According to one embodiment, a method of correcting a zero rate offset (ZRO) of a first inertial sensor located on a device includes determining a stability level of the device based on information related to at least one non-inertial sensor located on the device, and when the stability level is above a threshold, performing calibration of the ZRO of the first inertial sensor.

According to one embodiment, a method of operating a robotic device comprises: sending a plurality of motion control requests to a controller based on a current zero rate offset (ZRO) associated with one or more inertial sensors located on the robotic device; and controlling the movement of the robotic device.

According to one embodiment, a method of correcting a zero rate offset (ZRO) of a first inertial sensor located in a device includes stopping the device for a first period for reasons not related to the ZRO calibration; accumulating ZRO correction data during the first period; moving the device after the first period; suspending the device for a second period of time for reasons not related to the ZRO calibration; accumulating ZRO correction data for a second period; and performing ZRO correction using the accumulated ZRO correction data from the first and second periods.

According to one embodiment, the device comprises at least one non-inertial sensor; at least one inertial sensor; at least one motor; a controller for correcting a zero rate offset (ZRO) of an inertial sensor located in the device by determining a stability level of the device based on information related to the at least one non-inertial sensor; and when the stability level is above the threshold, performing calibration of one ZRO of the at least one inertial sensor.

According to one embodiment, the robot device includes at least one motor; and receiving one of a plurality of motion control requests based on a current zero rate offset (ZRO) error level associated with one or more inertial sensors located on the robotic device; and a controller configured to control movement.

According to one embodiment, the device comprises at least one motor; and suspending the device for a first period for reasons unrelated to zero rate offset (ZRO) correction; accumulate ZRO correction data during the first period; move the device after the first period; stop the device for a second period of time for reasons unrelated to the ZRO calibration; accumulate ZRO correction data for a second period; and a controller configured to perform a ZRO correction using the accumulated ZRO correction data from the first and second periods.

A more detailed understanding may be obtained from the following detailed description, given by way of example in conjunction with the accompanying drawings herein. In the detailed description, the drawings are examples. Accordingly, the drawings and detailed description are not to be regarded as limiting, and other equally effective embodiments are possible and possible.

Brief description of the drawing
Also, like reference numbers in the drawings indicate like elements, where:
1 is a block diagram showing the components of an exemplary system in accordance with one embodiment;
2A and 2B show state diagrams for a processing system according to an embodiment;
3A and 3B show state diagrams for a processing system according to another embodiment;
4 is a table illustrating an exemplary embodiment of how a device may be programmed to respond to various states of a MotionRequest flag;
5 to 7 are flowcharts illustrating a method according to an embodiment.

detailed description

BRIEF DESCRIPTION OF THE DRAWINGS The following detailed description of the invention refers to the accompanying drawings. Like reference numbers in different drawings indicate the same or similar components. Moreover, the following detailed description does not limit the present invention. Instead, the scope of the invention is defined by the appended claims.

As mentioned above, an IMU may be used in robotics, such as a robotic vacuum cleaner, which may have an IMU comprising one or more accelerometers, magnetometers and gyroscopes to provide orientation information for use in controlling the robot. there is. The robot may also integrate with sensors such as a wheel encoder to measure the linear motion of the wheels and/or with a camera or lidar for navigation. The robot may also have a controller, such as a processor, that has access to data from all sensors, thus calculating the robot's motion and position and/or orientation status. For example, if both the wheel encoder and the camera are motionless, and all motors are idle, the controller can reasonably assume that the robot is stationary.

Robots also include rotation about any axis and/or translation in any direction, and rotation and translation of robot parts relative to other parts of the robot (eg, a machine moving relative to the body of the robot). arm), including motors to cause movement of the robot in any number of ways. The controller may also be configured to direct the motion of the robot by controlling the motor.

According to one embodiment, the controller (or other processing device) uses data from both the IMU sensor and other sensors and components (eg, camera, wheel encoder) to improve the calibration of the IMU sensor(s). do.

As mentioned above, proper bias correction (eg, ZRO) of the gyroscope is critical to the performance of the IMU and thus the orientation of the robot. It is usually easiest to calibrate the ZRO when the sensor is stationary. However, what makes this process more difficult is the fact that the bias varies from sensor to sensor and even for individual sensors changes over time, for example with aging and temperature changes.

Many ZRO algorithms dynamically learn ZRO when the device is stable, i.e. stationary, and try to continuously improve this estimate. This works fine if the device is periodically stable, but it doesn't work if the device is in continuous motion for a long time after it is stable. For example, a robotic vacuum cleaner may take a long time to clean a large room after the initial stabilization window, during which time the ZRO of the gyroscope may vary. One possible solution is to periodically stop the robot for ZRO calibration. However, ZRO changes can depend on many factors, so ZRO recalibration is not necessarily required at fixed time intervals. Stopping the robot when not needed is a waste of time. Therefore, it is useful for the controller to know when ZRO correction is needed and when it is not.

Moreover, although sometimes the robot is not absolutely stable, indicating that the inertial sensor is not a good time to perform a ZRO calibration, this may be stable enough to allow for a reasonable ZRO calibration. For example, when the robot vacuum cleaner is stationary, i.e. there is no linear and angular motion, but the blower is running, the inertial sensor can detect a significant amount of measurement noise due to the vibration of the blower, so, inertial A stable detection algorithm based on sensor output is likely not to determine that the robot is stable enough for ZRO to perform. However, in practice a good ZRO correction can be performed (although it is stable and not as good as with the blower off), especially when the robot is not moving, rotating, and just vibrating, especially in relatively long data collection windows (eg, a few seconds). Therefore, it may be highly desirable to perform a ZRO calibration when the robot is not translating or rotating and the blower is on, especially when a long time has elapsed since the last ZRO calibration.

Another special case is when the robot is rotating about the axis of gravity at a constant angular velocity (eg on a gimbal), and the robot's IMU has one or more gyroscopes and one or more accelerometers, but no magnetometer. Since the gyroscope and accelerometer data are the same as when the robot is stationary, and there is no magnetometer to detect a change in orientation, the stable detector is "fooled" into thinking the robot is stationary, and thus the rotational angular velocity is ZRO. is considered In this case, a flag from the robot indicating that the robot is moving makes it possible to avoid false stability detection.

For the reasons mentioned above, it would be beneficial to incorporate the interaction between the robot controller and the Zero Rate Offset (ZRO) calibration unit/process to obtain a much more accurate estimate of whether the robot is stationary, and thus where ZRO calibration is desirable. (or at least do a ZRO correction when it shouldn't, or at least reduce the number of times it doesn't perform a ZRO when it should). More specifically, providing data indicative of whether the device is stable, such as wheel encoder data and/or camera data, from the robot controller to the ZRO calibration unit would allow for more frequent ZRO calibrations, where in the past it might not have been considered appropriate. allowing, thus making ZRO corrections performed when necessary or desirable. Complementarily, the ZRO calibration unit can communicate with the robot controller to request that the robot be stopped when a ZRO calibration is needed, which in other cases cannot be performed because the robot is moving.

1 is a block diagram of an exemplary robotic system, eg, a robotic vacuum cleaner, in accordance with an embodiment. The system includes a robot controller, which may include a processor for processing data received from the IMU 102 and other sensors 104 on the robot, such as wheel encoders and cameras. IMU 102 includes inertial sensors, such as one or more gyroscopes for sensing rotation about one or more axes, accelerometers for sensing acceleration along one or more directions, and one or more magnetometers for sensing orientation relative to the Earth's magnetic field. may include The robot controller 100 may communicate with one or more motors 106 that may cause the robot and/or discrete portions thereof to move and perform functions including translational and rotational movements. Both robot controller 100 and IMU 102 may include one or more processors and one or more memories (not shown separately). For example, a processor inside or otherwise associated with the IMU may interact with the inertial sensor to implement a bias offset compensation technique. Likewise, the processor within the robot controller can interact with and control other components of the system, such as motors. The processor associated with the robot controller 100 and the processor associated with the IMU 102 may be configured as a single processor configured to perform both sets of functions. In fact, each component of Figure 1 may comprise one or more software modules executing on a processor, including a general purpose computer, or as described below, an ASIC, a state machine, a logic circuit, an analog circuit, a digital circuit, a processor or any of the above-mentioned It may consist of hardware components dedicated to hardware configuration to perform functions, including but not limited to combinations of elements. The IMU can also perform the function of determining whether a device (eg a robot) is stationary/steady based on data from an inertial sensor.

According to an embodiment, in addition to the components, functions and signals described above, the robot controller component 100 and the IMU component 102 may exchange a MotionRequest flag signal and a Motionlntent flag signal. In addition, the robot controller may further include a separate stability detection function.

As explained in more detail below, the stability sensing function of the robot controller determines whether the robot is stable and/or how stable the robot is based on data received from other sensors (i.e. not the inertial sensors located on the IMU). or stopped).

As will be described in more detail below, the Motionlntent flag is a signal issued by the robot controller to the IMU indicating the operating state of the robot. It is called the Motionlntent flag because data from non-inertial sensors can cause the robot controller to miscalculate the robot's actual motion. For example, wheel encoder data may indicate that the wheel is not rolling, which can be reasonably used by the robot controller to conclude that the robot is stationary. However, if the robot is on a slippery surface, you can imagine that the robot is actually sliding along the floor. The camera output may not accurately reflect the robot's movement status. The MotionRequest flag is a signal the IMU issues to the robot controller that indicates whether the IMU wants the robot to stop so that the IMU can perform ZRO calibration.

I. Stability detection with adaptive sensor noise level

Stability sensing is desirable for ZRO calibration purposes. When the robot/sensor is stable, the average of the gyroscope output data over the time window is essentially an estimate of the ZRO. The accuracy of this estimate depends on the gyroscope noise level and the length of the time window over which the noise is observed. In other embodiments, the ZRO estimate may be much more complex than simply averaging the gyroscope output data over a time window. For example, the previously mentioned PCT published patent application 2018/118574 discloses a method and apparatus for performing ZRO compensation that directly solves the temperature gradient of ZRO to obtain an accurate ZRO estimate at the current temperature.

If the noise level of the sensor is known, then a determination that the robot is stable (eg, so bias estimation can be done) determines that (1) the peak-to-peak variation of the sample in the window is a first threshold ) and (2) whether the window average has not changed beyond a second threshold (referred to herein as an average threshold). If there are multiple sensors (e.g. accelerometers, gyroscopes and magnetometers inside the IMU), stability detection should be based on measurement data from all sensors, e.g. a robot can only be considered stable when all sensors are stable. there is.

Both the sample threshold and the average threshold are calculated from the sensor noise level. However, within the same model, different sensors have different noise levels. The nominal value for each sensor model noise (eg, provided by the manufacturer, provided by pre-operational tests, or determined prior to the current time) can be used as the noise level. However, this value is generally not accurate for most sensors. If the actual noise level is greater than the nominal value, the sensor is very sensitive to movement, so it is difficult to accurately determine stability with such a sensor. On the other hand, if the actual noise level is much smaller than the nominal value, it is not sensitive enough to movement, in which case the robot can be judged to be stable when actually moving slowly, which will reduce the ZRO accuracy. Therefore, it is important to "learn" the actual noise level of each sensor.

In one embodiment, described in more detail below, the stability sensing function may start by using a nominal value as the sensor noise level, and update the noise level for each sensor each time stability is sensed. In this way, the sensor noise levels used to calculate the sample threshold and average threshold continue to become more accurate over time.

Vibration in addition to sensor noise makes it more complicated to determine if a device is stable. In the example of a robotic vacuum cleaner (RVC), for example, this can happen when the RVC is stationary and not rotating, but at least one motor is on. Because different combinations of motors or floor types in operation can result in different vibration levels, alternative solutions may be needed to reasonably accurately detect device stability. In an embodiment, weighted statistics for dynamically learning vibration noise may be used, so that the stability sensor may adapt to different levels of vibration after a certain time and still detect unintended sudden movements.

II. Example 1

A. Motionlntent flag from robot controller to IMU

Motionlntent flags are generated by the robot controller based on output data from cameras, wheel encoders, the robot's inertial sensors, or other mechanical components of the robot, which can provide data about the robot's mobility status. This flag is sent to the IMU, which uses this flag to determine if and/or how stable the robot is. As just one example, if the motor controller determines that the wheel is not moving from the wheel encoder, the image detected by the camera is not changing, the blower motor is off, and the wheel motor is off, it indicates that the robot is stable. A Motionlntent flag may be generated indicating that it believes. On the other hand, except that the blower is not turned off and on (and possibly shaking the images received by the camera), all things being equal, it means that the robot is not translating and rotating, but overall motionless. You can create a Motionlntent flag to indicate that you believe it is not (eg, it is oscillating).

In one embodiment, the Motionlntent flag may be a 2-bit flag with 4 states indicating one of the following states:

UNKNOWN:

This state indicates that the robot controller does not believe that it can provide an accurate estimate of the robot's operating state. It is still possible that the robot is stable.

STATIONARY_WITHOUT_VIBRATION:

This state of the Motionlntent flag indicates that the robot controller expects the robot to be stationary without further vibration. This is when the robot is intended to be still, i.e. there is no linear motion, no rotation and no vibration. Therefore, the noise in the gyroscope data should be just sensor noise, and the ZRO estimate captured in the gyroscope output data should be accurate.

Stationary-with-vibration (STATIONARY_WITH_VIBRATION):

This state of the Motionlntent flag indicates that the robot controller predicts that the robot is essentially stationary but vibrating. It can be in this state when the robot does not move linearly and rotates but vibrates (eg when the vacuum blower is On in a robotic vacuum cleaner). In such a moving state, it can be assumed that the noise of the gyroscope output data includes both sensor noise and noise caused by vibration in the IMU processor (eg, ZRO estimation function). The IMU can use this data to calculate a fairly accurate estimate of ZRO, but this estimate may require a longer time window for observation and/or may be less accurate than when the robot is fully stable.

IN_MOTION:

This state of the Motionlntent flag indicates that the robot controller predicts that the robot is moving and is not expected to be stationary. When the Motionlntent flag is in this state, the IMU should normally not perform any ZRO calibration at all.

As mentioned above, these flags are just the "intents" of the robot. Even when the flag indicates a stationary state, there may be "unintentional" movement. For example, the robot may suddenly bump into an object or the robot may slide on the floor (wheel encoders indicate that the robot is stationary). Therefore, in one embodiment, even when the Motionlntent flag indicates that the robot is stationary, a separate stability detector in the IMU (e.g., using data from an inertial sensor) indicates that the robot is It continues its motion prediction operation, which is used to predict that it is moving, and prevents the IMU from attempting to estimate the ZRO under these conditions, which can produce a very erroneous ZRO estimate.

B. MotionRequest flag from IMU to robot controller

The IMU may determine the ZRO state (eg, the current ZRO estimate is likely to be correct or the current ZRO estimate may not be accurate), and may send a MotionRequest flag to the robot controller according to the ZRO state. For example, if the ZRO needs to be recalibrated, the sensor may ask the robot to stop or to remain stationary if the robot is already stopped. Flags may be designed according to different levels of urgency of the need to update the ZRO estimate.

In one embodiment, ZRO quality may be primarily determined by the following aspects:

a. Time elapsed since last ZRO correction due to aging effects, Δt;

b. temperature change since last calibration, ΔT;

c. Calibration quality of the last calibration (this can be expressed as ΔZRO, which is the standard deviation of the ZRO estimate)

The maximum ZRO error can be estimated as

"ZRO_Err" = △t aging_slope + △T temperature_slope + △ZRO (One)

The goal is to minimize the total "ZRO_Err", thereby maximizing the robot orientation accuracy for a given sensor.

In one embodiment, the MotionRequest flag may be 2 bits and may have 4 states as follows:

NO_CONSTRAINT:

The MotionRequest flag can be issued when the robot is in a steady state, in which case it indicates that the IMU has acquired enough data during the current pause to generate an accurate ZRO estimate. Thus, the robot can freely move or stop as desired. This condition can also occur when the robot is moving and does not need to stop for ZRO purposes.

STAY_STATIONARY:

The MotionRequest flag may be issued while the robot is stationary, indicating that a stable window for good ZRO calibration has not yet been met, and a request is made to keep the robot stationary.

Non-agent-stationary (NON_URGENT_STATIONARY) :

The MotionRequest flag can be issued when the robot is moving, and when the IMU thinks stopping sooner or later will help identify the ZRO. In short, it is a request to the robot controller to stop sooner or later, though not urgently. The robot controller shall stop the motion of the robot at a convenient time in response to receipt of this flag. The level of convenience depends on the knowledge of when to stop the robot, the function currently being performed by the robot, and/or the orientation of the robot, regardless of the state of the MotionRequest flag that synchronizes the next stop to respond to future events such as battery level, bumping into an obstacle, etc. This inaccuracy can be judged as a function of one or more of several factors, such as the critical state assigned to the level of risk that may occur.

Agent-stationary (URGENT_STATIONARY):

The MotionRequest flag can be issued while the robot is moving and the IMU believes it should calibrate the ZRO as soon as possible. In short, it is important to stop as quickly as possible to prevent the orientation error from getting worse than desired.

In one embodiment, there may be three different levels of thresholds for "ZRO_Err": ZRO_Lo, ZRO_Md, and ZRO_Hi. These three levels can be used to set the MotionRequest flag according to the following equation:

If the Motionlntent flag from the robot controller is UNKNOWN or IN_MOTION, then:

If the Motionlntent flag is STATIONARY_WITHOUT_VIBRATION or STATIONARY_WITH_VIBRATION, then:

C. ZRO Calibration Process in IMU

The Motionlntent flag can be used by the IMU as an indicator of the robot's operating state, and the IMU process for ZRO calibration may vary depending on the state of the Motionlntent flag.

For example, when in the STATIONARY_WITHOUT_VIBRATION state, the IMU performs stability detection with an adaptive noise level. This involves the use of stability sensing algorithms to determine the amount of dynamic motion present in the gyroscope and accelerometer signals over a period of time. An "on table" stability detector allows a certain amount of sensor "noise" and vibration, but still has a fixed threshold that is declared stationary. The noise level used in this process is either the initial nominal value of the sensor or the stored static noise level from the most recent previous standstill. If the stability detection process performed on the IMU does not float with the robot controller's Motionlntent flag that the robot is stable, this is most likely if some unintended motion, such as slipping or bumping, has occurred, or if not, the IMU has a simple window. Perform a process for ZRO recalibration, such as the averaging algorithm or the more complex process disclosed in the aforementioned PCT published patent application 2018/118574. The IMU must also store the standard deviation of the ZRO, the timestamp, and the temperature at that time.

Initially, while calculating the updated ZRO, the IMU sets the MotionRequest flag to STAY_STATIONARY . Next, after the ZRO estimate reaches a certain accuracy, for example in equation (3), or after a predetermined time window has elapsed, the MotionRequest flag is changed to NO_CONSTRAINT.

When the Motionlntent flag changes the state from STATIONARY_WITHOUT_VIBRATION to another state, the IMU will use the new fixed noise level value to store the static sensor noise level and continue the STATIONARY_WITHOUT_VIBRATION state in the future.

When the Motionlntent flag is in the STATIONARY_WITH_VIBRATION state, the IMU can run the stability detection process with different noise levels. In particular, the noise level may be a fixed preset value, for example based on some typical vibration of the robot. It could possibly be larger than the value for the STATIONARY_WITHOUT_VIBRATION state (usually represented by a longer time window to determine ZRO). Although that is an option, learning the noise level along with vibration may not be particularly useful for STATIONARY_WITHOUT_VIBRATION, since varying levels of vibration can be caused by various combinations of motors or floor types that are running. On the other hand, in other embodiments, a separate noise level may be learned and stored for each combination of possible states of motor states (and/or other factors). Then, during operation, the device can sense the motor state (and/or other factors) and select one of several noise levels that correspond to a particular combination of motor states (and/or other factors).

In an alternative embodiment, the robot controller may communicate these motor states for use in classifying different noise levels. In another alternative embodiment, instead of learning and storing discrete noise levels, the system may dynamically adapt to the current noise level. The rate of adaptation can be adjusted so that the noise level increases fast enough to quickly adapt to new vibrations that are larger than before, but can change slowly enough to reject unexpected motion events such as collisions.

To calculate the ZRO during oscillation, the running average of the samples during the quiescent period can be taken as a reasonable estimate of the ZRO. For shorter windows and larger oscillations, the fundamental frequency of the oscillations can be determined, and the length of the average window can be adjusted to be a multiple of the fundamental frequency of the oscillations. This can help avoid biasing the ZRO estimate. The fundamental frequency can be detected by frequency domain analysis (eg FFT-based analysis) or time domain analysis (eg zero cross analysis).

If the IMU stability detection process performed by the IMU does not agree with the Motionlntent flag in the robot controller that the robot is stationary but there is vibration/noise, this is likely unless some unintentional movement such as wheel slipping or bumping occurs. High, the IMU recalibrates the ZRO. The IMU must also store the ZRO's standard deviation, timestamp, and temperature.

Initially, while calculating the updated ZRO in this state, the IMU sets the MotionRequest flag to STAY_STATIONARY. Then, after the ZRO estimate has reached a certain accuracy, e.g., see equation (3), or after a predetermined time window, the MotionRequest flag is changed to NO_CONSTRAINT.

When the Motionlntent flag changes state from STATIONARY_WITH_VIBRATION to another state, the IMU saves the time and temperature of the last ZRO estimate for later use.

When the Motionlntent flag is in the IN_MOTION state, the IMU will not perform stability detection to avoid false stability detection, thus avoiding potential recalibration of the ZRO which may be inaccurate. Also in this state (that is, the Motionlntent flag is set to IN_MOTION), the IMU sets the MotionRequest flag to NO_CONSTRAINT, NON_URGENT_STATIONARY, or URGENT_STATIONARY depending on other factors. For example, in one embodiment, the state of the MotionRequest flag is set according to equation (2). In another embodiment, the state of the MotionRequest flag is simply set as a function of time since the last ZRO calibration, eg, from NO_CONSTRAINT to NON_URGENT_STATIONARY and finally URGENT_STATIONARY as time progresses.

Finally, when the Motionlntent flag is in the UNKNOWN state, the IMU will perform stability detection with a static noise level. If the IMU's stability sensing process determines that the robot is stable, this is possible, and the next IMU recalibrates the ZRO. The next IMU, when the Motionlntent flag is in IN_MOTION state, for example, NO_CONSTRAINT, NON_URGENT_STATIONARY or URGENT_STATIONARY, depending on several factors), can set the Motionlntent flag the same as mentioned above.

Moreover, whenever the Motionlntent flag changes state, the noise threshold used by the IMU's stability detection algorithm should also be considered and potentially updated. For example, whenever the Motionlntent flag changes the state to STAIONARY_WITHOUT_VIBRATION, the noise threshold should be set to the stored static noise level (which can be a nominal value or a recently updated value, as previously described). This is also true for all transitions from other states of the Motionlntent flag to the UNKNOWN state. On the other hand, any transition from any other state to the STATIONARY_WITH_VIBRATION state must be performed in conjunction with setting the noise threshold used by the IMU stability sensing process to a fixed "vibration" noise level, as mentioned earlier. Finally, whenever the Motionlntent flag is switched to IN_MOTION , no action needs to be taken regarding the setting of the noise level, as the IMU's stability sensing process is always turned off in this state.

Figures 2a and 2b show state tables showing the functions performed when the Motionlntent flag is changed from one state to another, as well as the functions performed by the IMU for each given state of the Motionlntent flag, as summarized above. . More specifically, in FIGS. 2A and 2B , the current state of the Motionlntent flag is listed under the first (leftmost) column, and the state transitioned at the end of that state is listed in the first (top) row. Therefore, the cells along the diagonal of the table (the gray cells) do not contain the state change of the Motionlntent flag. Thus, what is described in these cells is the function they perform when the Motionlntent flag is in that state. On the other hand, other cells (not on the diagonal of the table) correspond to state changes in the Motionlntent flag. Thus, the text in these cells describes the action to be performed when changing between the two corresponding states.

So, for example, the cells in the second row and second column reflect the process(es) that are performed when the Motionlntent flag is in the STATIONARY_WITHOUT_VIBRATION state. On the other hand, for example, the cells in the second row and third column reflect the process performed when the Motionlntent flag transitions from the STATIONARY_WITHOUT_VIBRATION state to the STATIONARY_WITH_VIBRATION state. Similarly, the cells in the second row and fourth column reflect the process performed when the Motionlntent flag transitions from the STATIONARY_WITHOUT_VIBRATION state to the UNKNOWN state.

Moreover, text in any cell printed without parentheses indicates that it is performed by (or in connection with) the stability detection function of the IMU. Text in arrow brackets indicates which variables are being updated and saved. Text printed in parentheses indicates that the IMU is setting the MotionRequest flag. Finally, the text printed in standard parentheses indicates what is being done with respect to the noise threshold. Two things happen with regards to noise level, at least in some cells. For example, (1) the noise level recorded at the end of the previous state may be stored for future use, and (2) the noise level may be set for use in the current state.

Ⅲ. Example 2

A. Motionlntent flag from robot controller to IMU

There is no significant change with respect to the Motionlntent flag compared to the first embodiment.

B. MotionRequest flag from IMU to robot controller

The two main factors in ZRO quality are temperature and time elapsed since the last calibration. Time-related ZRO errors are caused by sensor instability, non-linearity, hysteresis, and aging. Temperature-related ZRO errors are caused by ZRO fluctuations due to temperature changes. The temperature-ZRO fitting can be learned and applied to obtain a ZRO estimate at the current temperature, as disclosed in the aforementioned PCT Published Patent Application 2018/118574. Temperature-ZRO fittings may also provide ZRO errors based on fit condition (eg slope, fit quality, applied temperature range, etc.).

Using these considerations, in another embodiment of the MotionRequest flag, the goal is to limit the ZRO error to a first, lower (or acceptable) level of accuracy for robot heading accuracy requirements; A second, higher (or preferred) level of accuracy is achieved when reasonably possible without adversely affecting certain other robot performance parameters. The two goals are sometimes referred to below as LoPerfGoal and HiPerfGoal respectively.

In this exemplary embodiment, when the robot is stationary (eg, the Motionlntent flag state is either STATIONARY_WITHOUT_VIBRATION or STATIONARY_WITH_VIBRATION), the MotionRequest flag may have the following possible states:

STAY_STATIONARY_REQUIRED:

The MotionRequest flag may be issued when the stability window for ZRO calibration has not yet met even the lower (acceptable) performance target, and it is considered necessary to keep the robot stationary.

Stay-stationary-optional (STAY_STATIONARY_OPTIONAL) :

The MotionRequest flag may be issued when the stability window for ZRO calibration meets the low-performance target, but does not meet the high-performance (preferred) target, where the state of keeping the robot stationary is considered an option.

NO_CONSTRAINT:

The MotionRequest flag can be issued when the IMU has enough information to calculate, from the current stop, a ZRO estimate that satisfies the higher accuracy requirements, so the robot is free to move or stop as desired, regardless of the ZRO estimate. there is.

In an exemplary embodiment, reaching a specific performance target (eg, a lower and acceptable performance target or a higher and preferred performance target) for a ZRO estimate is a stated goal for which the accuracy (or in particular the standard deviation) of the ZRO estimate is stated. means better than Since the ZRO estimate is the gyroscope sample average over a stationary window, the longer the window, the more accurate the calculated ZRO estimate. The simplest model, the Additive White Gaussian Noise (AWGN) noise model, means that the standard deviation of ZRO is proportional to the standard deviation of the gyroscope samples and the square root of the number of samples.

However, it has been observed that the ZRO_Std calculated by equation (4) can be very different from the actual value, sometimes up to an order of magnitude, due to color noise.

In this embodiment, a new method of estimating ZRO_Std is used, which does not require the storage of all previous samples. Specifically, an IIR filter is used to mimic the averaging filter, and the standard deviation of the filtered sample is used to estimate ZRO_Std. This provides better information about when the quiescent window is long enough to meet certain performance goals.

In one embodiment of the MotionRequest flag as described above, there are two different level thresholds for ZRO_Std: HiPerfGoal and LoPerfGoal. The states of the MotionRequest flag can be implemented as a function of ZRO_Std as follows.

Meanwhile, when the robot is not stopped (eg, when the Motionlntent flag state is UNKNOWN or IN_MOTION), the MotionRequest flag may have the following state.

Timer-stationary (TIMER_STATIONARY):

The MotionRequest flag can be issued in this state when the robot has been moving for a certain amount of time, suggesting a stop for ZRO recalibration.

Agent-stationary (URGENT_STATIONARY):

The MotionRequest flag may be issued in this state when the IMU determines that the ZRO needs to be corrected as soon as possible, so it is important to stop it to prevent heading errors from falling below a certain threshold.

Non-agent-stationary (NON_URGENT_STATIONARY) :

A MotionRequest flag can be issued in this state when the IMU determines that stopping sooner or later will help identify the ZRO. In short, it is a request to the robot controller to stop sooner or later, if not urgently. The robot controller should, when convenient, stop the robot's motion upon receiving this flag. The level of convenience depends on the level of battery life, knowledge of how long the robot can stop, regardless of the state of the MotionRequest flag that synchronizes the next stop to respond to future events such as encountering an obstacle, the function currently being performed by the robot, and/or It can be judged as a function of one or more of several factors, such as the critical state assigned to the level of harm that can occur if the robot is oriented incorrectly.

In one embodiment, there may be two different level thresholds for "ZRO_Err", namely NonUrgentErr and UrgentErr. These two levels can be used to set the MotionRequest flag according to the following equation:

C. ZRO Calibration Process in IMU

The Motionlntent flag can be used as an indicator of the robot's motion state in the IMU, and the IMU process for ZRO calibration may vary depending on the state of the Motionlntent flag.

For example, when in the STATIONARY_WITHOUT_VIBRATION state, the IMU performs stability detection with an adaptive noise level. The noise level used in this process is either the initial nominal value of the sensor or the stored static noise level from the most recent previous standstill. If the stability detection process performed by the IMU matches the robot controller's Motionlntent flag that the robot is stable, then this is very likely unless some unintended motion such as slipping or bumping has occurred. Perform the same process for ZRO recalibration as the more complex process disclosed in the aforementioned PCT published patent application 2018/118574. The IMU must also store the standard deviation of the ZRO, the timestamp, and the temperature at that time.

In addition, the standard deviation of ZRO is obtained through statistics of IIR low-pass filtered gyroscope samples. This standard deviation is used to determine when the MotionRequest flag can change from the STAY_STATIONARY_REQUIRED state to the STAY_STATIONARY_OPTIONAL state and then to the NO_CONSTRAINT state according to Equation 5.

Also, whenever the Motionlntent flag is changed from the STATIONARY_WITHOUT_VIBRATION state to another state, the last ZRO estimate time is saved for future use in determining how much has passed since the last ZRO calibration. As mentioned above, this can be used as an element to determine the state of the MotionRequest flag.

Also, to automatically detect when the device is stationary independently of the Motionlntent flag, when the Motionlntent flag is STATIONARY WITHOUT VIBRATION, the stationary sensor noise level at that time can be saved for future use.

Returning to the Motionlntent flag, in STATIONARY_WITH_VIBRATION state, stable detection, ZRO update, and MotionRequest generation can be the same as in STATIONARY_WITHOUT_VIBRATION state except how noise level is tracked and used.

In STATIONARY_WITHOUT_VIBRATION state, the noise level is just sensor noise, learned whenever stability is detected and stored for future use. In STATIONARY_WITH_VIBRATION state, the noise level is vibration noise generated by the motor and can be changed at any time. In one embodiment, weighted statistics are used to dynamically learn vibration noise, so that the stability detector can adapt to different levels of vibration after a certain time and still detect unintentional sudden movements.

When the Motionlntent flag is in the IN_MOTION state, the stability detection process is turned off to avoid the possibility of false stability detection. As mentioned earlier, the MotionRequest flags that can be generated when the Motionlntent flag is in the IN_MOTION state are NO_CONSTRAINT, NON_URGENT_STATIONARY, or URGENT_STATIONARY for temperature-related requests. One way to select the state of the MotionRequest flag is shown in Equation (6) above. There is also a counter, TIMER_STATIONARY, that generates a time-related request for the robot to stop moving.

When the Motionlntent flag is in the UNKNOWN state, stability detection through a fixed noise level process is performed. When stability is detected, the ZRO is updated whenever possible. If the Motionlntent flag is in this state, the MotionRequest flag state is generated in the same way as when the Motionlntent flag is in the IN_MOTION state.

3a and 3b show the functions performed when the Motionlntent flag is changed from one state to another, as well as the functions performed by the IMU for each given state of the Motionlntent flag, as discussed above, according to the second embodiment. A state table showing the function is shown. The example described above with respect to FIGS. 2A and 2B is also applicable to FIGS. 3A and 3B . More specifically, in Figures 3a and 3b, the current state of the Motionlntent flag is listed under the first (leftmost) column and the state it transitions to at the end of that state is listed in the first (top) row. Therefore, the cells along the diagonal of the table (the gray cells) do not contain the state change of the Motionlntent flag. So, what is described in these cells is the function performed when the Motionlntent flag is in that state. On the other hand, other cells (not on the diagonal of the table) correspond to state changes in the Motionlntent flag. Thus, the text in that cell describes what happens when transitioning between the two corresponding states.

Also, text in any cell printed without parentheses indicates what is being done by (or in connection with) the stability sensing function of the IMU. Text in arrow brackets indicates which variables are being updated and saved. Text printed in parentheses indicates the state in which the IMU sets the MotionRequest flag. Finally, the text printed in standard parentheses indicates what is being done with respect to the noise threshold. There are two things with respect to the noise level in at least some cells: (1) the noise level recorded at the end of the previous state can be stored for future use, and (2) the noise level for use in the current state. Note that it is happening that the level can be set.

In the embodiment illustrated in the table of Figures 3A and 3B. STAY_STATIONARY_REQUIRED is the default MotionRequest when entering one of the stop states from some other state (ie, IN_MOTION state, UNKNOWN state, or the other of two stop states). Also, as the ZRO estimate is computed while in one of the stationary states, the MotionRequest flag goes from the STAY_STATIONARY_REQUIRED state to the STAY_STATIONARY_OPTIONAL state and eventually to the NO_CONSTRAINT state. However, in another embodiment, when the Motionlntent flag transitions from one stop state to another, the MotionRequest flag does not necessarily start at STAY_STATIONARY_. Rather, when changing from one stop state to another, the MotionRequest flag can continue from the state it is already in. In particular, the ZRO accuracy can already be above the threshold of either HiPerfGoal or LoPerfGoal when transitioning from one stationary MotionIntent state to another, so there is no need to go through all three MotionRequest states again.

In short, in alternative embodiments, the MotionRequest flag may remain unchanged during any Motionlntent flag state transitions between STATIONARY_WITH_VIBRATION and STATIONARY_WITHOUT_VIBRATION. Referring to FIG. 3 , the difference between this embodiment and that illustrated by FIG. 3 is that the MotionRequest flag is set to STAY_REQUIREDSTATIONARY_ in the cell at 3 row 2 (converting STATIONARY WITHOUT_VIBRATION to STATIONARY_WITH_VIBRATION) and in the cell at 2 row 3 (converting STATIONARY_WITH_VIBRATION to STATIONARY_WITHOUT_VIBRATION). It would be to remove the step of setting it to . The "MotionRequest = STAY_STATIONARY_REQUIRED" step in these two cells will simply be removed, since we are not taking any action regarding the MotionRequest flag (it remains unchanged during the transition between the two stationary states).

D. Using MotionRequest on the robot side

Because the MotionRequest flags have different levels of importance, the robot can make a MotionRequest in different ways depending on, for example, sensor properties, performance requirements, use cases, etc. For example, some sensors are known to have good stability and temperature-ZRO linearity, in which case the TIMER_STATIONARY state of the MotionRequest flag can be omitted (or at least ignored by the robot controller), and doing so does not significantly degrade performance. .

4 is a table illustrating an exemplary embodiment of how a robot may be programmed to respond to various states of a MotionRequest flag according to a given performance. In Figure 4, a number of exemplary possible predetermined performance conditions for a robotic vacuum cleaner are listed in the first (leftmost) column, and whether the RVC is stopped (or held stationary) in response to each possible state of the MotionRequest flag. Whether or not is listed in the first (top) row. The rest of the table is then populated with YES or NO depending on whether RVC will stop running (or stay stopped for the last column) in response to the MotionRequest flag status for that column.

So, for example, the top row of a table marked High Performance corresponds to the highest ZRO accuracy performance, and is therefore chosen when an accurate ZRO estimate is extremely important. If this performance is required, RVC is stopped allowing ZRO calibration to respond to all requests to stop RVC (or, for the last column, it remains stopped, so ZRO calibration is low and acceptable level of ZRO accuracy is low). It will not allow the RVC to move again at any time after it has been achieved, but will continue until a higher and preferred level of ZRO accuracy is achieved).

In an embodiment, the performance condition (item in the leftmost column) may be defined as follows.

High Performance - Chosen if you always want the best ZRO estimate, regardless of how often you need to stop RVC and how long you need to stay stopped.

Frequency Short Stops - ZRO accuracy may be lower than under high performance conditions, however, generally the downtime is relatively short (eg, this option can be selected when frequent short stops are preferred);

Low Duty Cycle-ZRO accuracy may be lower than in high performance conditions, however, the total time taken to stop for ZRO calibration is relatively less (in terms of the combination of stop duration and stop frequency).

No Timer Stop - RVC does not stop for timer-based stop requests (e.g., as mentioned above, this option can be selected when sensors are known to have great stability and temperature-ZRO linearity) .

Rare Long Stops - The ZRO accuracy may be lower than in high performance conditions, but generally the stops are long enough so that a higher and preferred ZRO accuracy level can be obtained, but with relatively low frequency (e.g. , this option is longer but less frequent stops are preferred);

Timer Stop Only - RVC will only stop on timer based stop requests (you can choose this option if, for example, the sensor is known to have good temperature-ZRO linearity).

No Interactive ZRO - This option basically turns off the interactive feature of the ZRO calibration disclosed in this specification. Baseline non-interactive ZRO correction algorithms, i.e. stability sensing followed by simple window averages or more complex temperature-ZRO fittings, can still be used. One way to achieve operation with non-interactive ZRO compensation (but still have traditional ZRO compensation behavior) is to permanently set the Motionlntent flag to the default state of UNKNOWN, and disable the MotionRequest flag or motor controller (100). so that it does not respond to it. In this condition, according to Example 3 described above, for example, stability sensing, adaptive learning of sensor noise level and traditional ZRO correction all still occur, and in fact, the same as the STATIONARY WITHOUT VIBRATION state (e.g. Fig. see 4). In addition, since the practicality of implementation is oriented towards ensuring compatibility between products using the interactive ZRO correction feature of the present invention and products without this capability, stability detection and noise tracking while the Motionlntent flag is in the UNKNOWN state. It is good to guarantee the same as when in this STATIONARY_WITHOUT_VIBRATION state. Referring to the embodiment represented by Figures 3A to 3B, this can be, for example, a cell on the diagonal corresponding to the row "from UNKNOWN" and the column "to UNKNOWN", i.e. row 4, column 4 (the row "from STATIONARY_WITHOUT_VIBRATION" and It entails adding a noise tracking step of "Update noise at stable" in the "to STATIONARY_WITHOUT_VIBRATION" column, i.e. as found in the diagonal cells corresponding to row 2, column 2. In particular, in the embodiment of FIGS. 3A and 3B , the noise is not updated in the UNKNOWN motion state, whereas it is updated in the STATIONARY_WITHOUT_VIBRATION state. While these changes have little or no performance impact, they can make products with interactive ZRO capabilities of the present invention compatible with products without them. Also, since the condition of both the Motionlntent flags (UNKNOWN and STATIONARY_WITHOUT_VIBRATION) has already been set to the same state (i.e. On), no change is required in the stability sensing behavior shown in the embodiment of Figures 3A and 3B. take note of

IV. more specific examples

A. Alternative embodiment for MotionRequest flag

1. Changes to the calculation of standard deviation of ZRO

The MotionRequest flag for this first alternative embodiment may function similarly to the first or second embodiment except as noted below with respect to calculating the standard deviation of ZRO (where the ZRO estimate is the ZRO estimate process). is used to determine if it is accurate enough to stop the

The first example used the white noise model technique to estimate the standard deviation of ZRO. However, as previously mentioned, this estimate can differ significantly from the actual standard deviation due to color noise. Therefore, in the second embodiment, an IIR filter-based technique was introduced for calculating the standard deviation of ZRO, which does not require storing all of the previous samples. However, if the sensor is heavily affected by low-frequency noise, IIR filter-based techniques may take a long time to converge to a solution. In this case, it may be more preferable to use the white noise method of the first embodiment, depending on the applicable constraints, especially for the time the robot is stationary, however, the marginal factor (observation experience with the sensor) The color noise is compensated for by multiplying the standard deviation determined using the above equation (4) by a limit factor determined based on Therefore, equation (4) can be rewritten as

where f is the limiting factor. Depending on the spectrum of sensor noise, this limiting factor should be centered at 1, ideally 1.0 for true white noise. For currently available sensors, the limiting factor is typically in the range of 0.4 to 1.5.

2. Changes Related to Temperature Fitting

In another alternative embodiment, when the MOTION_INTENT flag is in one of the non-stationary states (ie, IN_MOTION or UNKNOWN), the IMU 102 is based on the current quality of the ZRO estimate, as well as a function of the estimated quality of the overall temperature fit. It can be configured to set the state of the MotionRequest flag as For example, the IMU 102 may set the MotionRequest flag when the temperature fitting is below a certain quality threshold (thus, more samples will be important to maintain long-term ZRO accuracy, although the current ZRO quality itself may be acceptable). It may be configured to place in the URGENT_STATIONARY state and/or the NON-URGENT_STATIONARY state. For example, in one exemplary embodiment of this feature, the minimum temperature change (dT) required to trigger a MotionRequest flag to change to URGENT_STATIONARY and/or NONJJRGENT STATIONARY depends on the quality of the fit (e.g. mean squared error or MSE) and It may be a function of the temperature range. That is, if the current temperature is outside the temperature range of the fitting, the robot will stop more often, and/or if the fitting quality is poor, it will also stop more often.

In one exemplary variant of the second embodiment according to this principle, when the robot is in one of the non-stationary states (i.e., when the Motionlntent flag is set to IN_MOTION or UNKNOWN), the MotionRequest flag is configured to act as follows: can

Timer-stationary (TIMER_STATIONARY):

The MotionRequest flag can be issued in this state when the robot has been moving for a certain period of time and a stop for ZRO recalibration is proposed (the MotionRequest flag to enter this condition indicates that this condition is not changed from the second embodiment) Pay attention.)

Agent-stationary (URGENT_STATIONARY):

The MotionRequest flag can be issued in a state when either (1) the IMU needs the ZRO to be calibrated as soon as possible (it is important to stop the robot to prevent heading errors from falling below a certain threshold) (same as in Example 2), (2) when the quality of the ZRO estimate currently used for temperature is acceptable, but the quality of the temperature fit is poor, and more samples are important for long-term ZRO accuracy.

Non-agent-stationary (NON_URGENT_STATIONARY) :

The MotionRequest flag may be issued when either: (1) when the IMU determines that it may be helpful to pause from time to time to check the ZRO (as in the second embodiment), and (2) When temperature fitting prefers more samples for better (but not critical) long-term ZRO accuracy.

NO_CONSTRAINT:

The MotionRequest flag can be issued in this state when no stop is needed for ZRO calibration or temperature fitting.

Also, in this embodiment, "ZRO_Err, i.e. the two different level thresholds for NonUrgentErr and UrgentErr, and in addition to setting the MotionRequest flag state according to equation (6) as discussed above with respect to the second embodiment, Another set of conditions related to temperature fitting can be added to the mix, for example, for a temperature fitting-based request, define _{the temperature change from when ZRO was last calculated as ΔT = Tcurrent - T lastZR0 and} , define the two thresholds, Th nonUrgent and Th urgent, as decreasing functions of the temperature fitting MSE (mean square error).

Next, the state of the MotionRequest flag as a function of the fitting-based request can be generated as follows.

Combine (a) the conditions of the ZRO-based control of the MotionRequest flag, i.e., equation (6) (repeated below for convenience of reference) with (b) the conditions of the temperature fitting-based control of the MotionRequest flag, i.e., equation (8). This creates the overall action of the MotionRequest flag as shown in Equation (9) below.

B. ZRO temperature fitting

PCT published patent application WO 2018/118574, the content of which is fully incorporated herein, discloses a method and apparatus for calculating the ZRO of a sensor as a function of temperature using a learning algorithm.

For example, according to an embodiment disclosed in that patent application, the system can be configured by (a) a measurement value generated by the gyroscope, (b) the temperature of the gyroscope, and (c) at least one other operation of the device. It repeatedly receives generated measurements and, based on measurements generated by the gyroscope and other sensors, determines when the gyroscope is stationary and at a certain temperature. During this period, the system accumulates the mean and mean and variance of the gyroscope measurements to generate a sample data set, then based on the mean and variance of the mean and mean of the gyroscope measurements at multiple temperatures, the weighted RLS of ZRO as a function of temperature ( Recursive Least Squares) to create a fit. The device can then calculate a ZRO estimate using the weighted RLS fit and the current temperature of the gyroscope.

According to a particular embodiment, a temporal forgetting factor is applied to all samples already in the fit, so that older samples give less weight to building a fit than newer samples (the factors related to ZRO will change over time). because it can). However, in certain applications, for example, in robotic vacuums that spend a lot of time charging at docking stations overnight, while the room temperature fluctuates within very small temperature ranges, this is because the data points are forgotten so quickly that the accuracy of the fitting is lost. cause damage For example, a very accurate ZRO fit for a very narrow temperature range, while data points outside that narrow temperature range are forgotten, making the ZRO estimate outside of that narrow temperature range less accurate.

To prevent such operation with oblivion factors from detrimentally affecting the fit, it may be advisable to keep track of the temperature range over which successive samples are taken, and to limit the gravity applied to added samples within that temperature range. . For example, the algorithm may simply stop collecting sample data (within a narrow temperature range) after a certain number of samples have been applied to the fit. In this case, new samples are only allowed to be added when the temperature changes beyond the given range (and, accordingly, the new temperature range can start to be tracked).

In one such embodiment, the ZRO temperature fitting process includes current temperature statistics, previous temperature statistics and linear ZRO-temperature fitting (such as the aforementioned PCT application), as well as recent results from the interactive ZRO calibration techniques described herein. The tracking of the ZRO estimate can continue. Since the ZRO estimate from the most recent interactive ZRO calibration is the most recent data, it may be desirable to give a high priority to the ZRO when it is selected for use in fitting.

Therefore, when the interactive ZRO correction technology of the present invention as well as the technology of the aforementioned PCT patent application is used in a device, the most recent ZRO corrected through the interactive ZRO correction technology of the present invention is used for compensation. When choosing which ZRO estimate to be used, a higher priority is given. Thus, in one embodiment, it is assumed that the most recent ZRO determined using the interactive ZRO calibration technique according to the present invention is considered valid (e.g., sections II.B, III.B and IV.A above As described in , the standard deviation of the most recent ZRO accumulation is within a predetermined threshold as described above), and the overall ZRO compensation process is better used at that ZRO and the ZRO dictated by the fitting algorithm of the preceding PCT patent application. select For example, you can decide which of the two is considered better based on the least mean squared error. On the other hand, if the ZRO determined using the interactive ZRO correction technique is not reasonable, the entire ZRO compensation process defaults to choosing the best of the current temperature, the previous temperature and the linear fit as disclosed in the aforementioned PCT patent application. .

C. Special process for applications prone to frequent short shutdowns

In some applications, short outages may be frequently experienced for operational reasons (i.e. reasons unrelated to the interactive ZRO technology and ZRO calibration of the present invention) with few or no stops long enough for sufficiently accurate ZRO calibration to occur. can In order to avoid stopping the robot due to frequent and/or long ZRO calibration stops (which may adversely affect normal operation), appropriate ZRO calibration should be calibrated from a plurality of successive short stops to effectively form a long stop. By 'stitching' the data together, it can be obtained with fewer stops made solely for ZRO calibration purposes. For example, if the interval between two stop windows is less than a predetermined threshold (eg, 10 seconds), then ZRO correction data from these multiple stops may be combined. This can be implemented by maintaining an internal accumulator of correction data from several stops of the robot and starting a timer each time motion is initiated. If the next stop occurs before the timer expires, the totalizer continues to accumulate data for ZRO correction and the timer is reset again. In certain embodiments, a second timer and/or time limit may be used to set the maximum time any set of multiple consecutive short stops may be combined. Alternatively, a single timer may be used to monitor only the total period during which data from multiple pause sessions may be combined (eg, regardless of the duration of the gap of successive pause sessions of each pair).

One of ordinary skill in the art will recognize that the embodiments described herein may also be represented as a method, examples of which are illustrated in the flow charts of FIGS. 5-7 . In FIG. 5 , a method of calibrating a zero rate offset (ZRO) of a first inertial sensor located in a device is described, which is disposed in the device and determines a stability level of the device based on information related to at least one non-inertial sensor. and performing ( 502 ) a ZRO calibration of the first initial sensor when the stability level exceeds the threshold. In FIG. 6 , a method for operating a robotic device is illustrated, sending one of a plurality of motion control requests to a controller based on a current Zero Rate Offset (ZRO) error level associated with one or more inertial sensors located on the robotic device 600 . and controlling the movement of the robotic device based on the motion control request (602). 7, a method of correcting the zero rate offset (ZRO) of a first inertial sensor located in the apparatus is described, comprising the steps 700 of stopping the apparatus for a first period of time for reasons unrelated to the ZRO correction; Accumulating ZRO correction data for a period of time (702), moving the device after a first period of time (704), stopping the device for reasons unrelated to the ZRO for a second period of time (706), during a second period of time accumulating ZRO correction data (708), and performing ZRO correction using the accumulated ZRO correction data from the first and second periods (710).

V. Summary

Implementation of the Motionlntent flag sent from the robot controller to the IMU helps improve ZRO accuracy. A MotionRequest flag sent from the IMU to the robot controller ensures that the worst-case ZRO always meets the heading performance requirements. Overall, the interactive ZRO algorithm improves ZRO accuracy and meets the requirement with a minimum request to stop the robot.

VI. conclusion

A data processing system and method according to an exemplary embodiment of the present invention may be performed by one or more processors executing a sequence of instructions included in a memory device. Such instructions may be read into the memory device from another computer readable medium, such as secondary data storage device(s). Execution of the sequence of instructions contained in the memory device causes the processor to operate, for example as described above. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the present invention. Such software may be executed on a processor housed within a device, such as a robot or other device that includes a sensor, and the software may be executed on a computer or processor housed within another device. System controllers, game consoles, personal computers, etc. that communicate with devices that contain sensors. In this case, data may be transmitted by wire or wirelessly between the device including the sensor and the device including a processor executing software for performing bias estimation and compensation as described above. According to another exemplary embodiment, some of the processing described above with respect to bias estimation may be performed in a device including a sensor, and the remaining processing may be performed by a second processing device after receiving partially processed data from a device including performed on the device. sensor. Data may be transmitted by wire or wirelessly between a device comprising a sensor and a device comprising a processor executing software to perform bias estimation and compensation as described above. According to another exemplary embodiment, some of the processing described above with respect to bias estimation may be performed in a device including a sensor, and the remaining processing may be performed by a second processing device after receiving partially processed data from a device including performed on the device. sensor. Data may be transmitted by wire or wirelessly between a device comprising a sensor and a device comprising a processor executing software to perform bias estimation and compensation as described above. According to another exemplary embodiment, some of the processing described above with respect to bias estimation may be performed in a device including a sensor, while the remaining processing may be performed in a second process after acquisition of partially processed data from a device included in the sensor. can be performed on the device.

Although the above-described exemplary embodiment relates to a sensing package including one or more rotation sensors and an accelerometer, the bias estimation technique according to this exemplary embodiment is not limited to this type of sensor only. Instead, the bias estimation technique described herein may be used, for example, by accelerometer(s) alone, optical and inertial sensors (eg, rotational sensor, gyroscope or accelerometer), magnetometer and inertial sensor (eg, rotational sensor, gyroscope or accelerometer). ), magnetometers and optical sensors (eg, cameras, one or more photodiodes, one or more phototransistors), or other sensor combinations. Also, additionally, although the exemplary embodiments described herein relate to bias estimation in the context of robots, robotic vacuum cleaners and applications, such techniques are not limited and may be applied to methods and apparatuses related to other fields of application, e.g. For example, mobile phones, medical fields, games, cameras, military fields, robotic devices, and the like.

The above-described exemplary embodiments are intended to be illustrative rather than limiting in all aspects of the invention. Accordingly, the present invention is susceptible to many variations in the detailed implementation that can be derived from the description contained herein by those skilled in the art. For example, although the exemplary embodiments described above have described the use of inertial sensors to detect motion of devices, among other things, other types of sensors (eg, ultrasonic, magnetic or optical) may have inertial signal processing as described above. It may be used instead of or in addition to the sensor. All such variations and modifications are considered to be within the scope and spirit of the invention as defined by the following claims. No element, act, or instruction used in the description of the present invention should be construed as critical or essential to the invention unless explicitly described. Also, as used herein, “a” is intended to include one or more than one item.

Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a processor. Examples of non-transitory computer-readable storage media include read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, magnetic media such as removable disks; magneto-optical media and optical media such as CD-ROM disks and DVDs (Digital Versatile Disks). A processor associated with software may be used to implement a radio frequency modulation receiver for use in a WTRU 102, UE, terminal, base station, RNC, or any host computer.

Moreover, in the embodiments described above, other devices including a processing platform, a computing system, a controller and a processor are noted. Such devices may include one or more central processing units (“CPUs”) and memory. References to acts and symbolic representations of acts or instructions may be performed by various CPUs and memories, consistent with the practice of those skilled in the art of computer programming. Such acts and acts or instructions may be referred to as “execution”, “computer execution” or “CPU execution”.

Those of ordinary skill in the art will understand that acts and symbolically expressed actions or instructions include manipulation of electrical signals by a CPU. The electrical system represents the data bits that cause the resulting conversion or reduction of electrical signals and the retention of data bits in memory locations in the memory system, thereby reconfiguring or altering the operation of the CPU and other signal processing. A memory location where data bits are held is a physical location that has certain electrical, magnetic, optical, or organic properties that correspond to or represent data bits. It should be understood that the exemplary embodiments are not limited to the above-mentioned platforms or CPUs, and that the CPUs may support the methods provided.

Data bits may also include magnetic disks, optical disks, and any other volatile (eg, random access memory (“RAM”)) or non-volatile (eg, Read me-Only Memory (“ROM”)) that can be read by the CPU. may be maintained on computer-readable media including mass storage systems. Computer readable media may include cooperative or interconnected computer readable media residing exclusively on a process system or distributed among a plurality of interconnected process systems that may be local or remote to the process system. It is understood that the representative embodiments are not limited to the memories described above and that other platforms and memories may support the described methods.

In an exemplary embodiment, any operation, process, etc. described herein may be implemented as computer readable instructions stored on a computer readable medium. The computer readable instructions may be executed by a processor of the mobile unit, a network element, and/or any other computing device.

On the system side, there is little difference between hardware and software implementations. The use of hardware or software is usually (but not always, the choice between hardware and software can become important in certain situations) is a design choice that represents a cost-effectiveness trade-off. There may be various vehicles (eg, hardware, software, and/or firmware) on which the processes and/or systems and/or other technologies described herein may be affected, with preferred vehicles being the processes and/or systems and/or other technologies. Or it may change with the context in which other technologies are deployed. For example, if the developer determines that speed and accuracy are paramount, the executor may choose primarily a hardware and/or firmware vehicle. When flexibility is paramount, the developer has primarily a software implementation choice. Alternatively, the developer may choose some combination of hardware, software and/or firmware.

The foregoing detailed description describes various embodiments of apparatus and/or processes through the use of block diagrams, flow diagrams, and/or embodiments. To the extent such block diagrams, flowcharts, and/or embodiments include one or more functions and/or operations, those skilled in the art will recognize that each function and/or operations in such block diagrams, flowcharts, or embodiments may be implemented in a wide variety of hardware, software, firmware, or de facto thereof. It will be understood that combinations may be implemented individually and/or collectively. Suitable processors include, for example, general purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors in conjunction with DSP cores, controllers, microcontrollers, application specific integrated circuits (ASICs), ASSPs. (Application Specific Standard Products), Field Programmable Gate Array (FPGA) circuits, and any other type of IC (Integrated Circuit) and/or state machine.

This disclosure is not limited in terms of the specific embodiments described herein, which are intended to be illustrative of various aspects. As will be apparent to those skilled in the art, many modifications and changes can be made without departing from the spirit and scope thereof. No element, act, or instruction used in the description of this application should be construed as critical or essential to the invention unless explicitly provided. Functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It should be understood that this disclosure is not limited to any particular method or system.

In certain representative embodiments, various parts of the subject matter described herein may include Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs) and/or or other integrated forms.However, those skilled in the art will appreciate that some aspects of the embodiments disclosed herein may be implemented in whole or in part as one or more computer programs running on one or more computers (eg, on one or one system). one or more programs running on one or more processors), one or more programs running on one or more processors (such as one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, equivalently embodied in an integrated circuit, and It will be within the skill of those skilled in the art to design and/or write code for software or firmware.In addition, those skilled in the art will find that the mechanism of the subject matter described herein can be distributed as a program product in various forms, It will be appreciated that the exemplary embodiments apply regardless of the particular type of signal bearing medium used to actually perform the distribution, including but not limited to floppy disks, hard disk drives, CDs, DVDs, digital tapes. tangible media, such as recordable media, computer memory, and the like;

The subject matter described herein sometimes exemplifies other components incorporated into or connected to other other components. It should be understood that such a depicted architecture is merely an example, and in practice many other architectures may be implemented that achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same function is effectively "associated" such that a desired function can be achieved. Accordingly, any two components herein combined to achieve a particular function, regardless of architecture or intermediate component, may be viewed as "associated with" each other such that the desired function is achieved. Likewise, two components so associated can be viewed as being "operably connected" or "operably coupled" to each other to achieve a predetermined function, and any two components that may be related perform a predetermined function. can be seen as “operably coupled” to each other to achieve. Specific embodiments that may be operatively coupled include, but are not limited to, physically compatible and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or Logically interacting and/or logically capable of interacting with components.

Herein, with respect to the use of substantially any plural and/or singular term, one of ordinary skill in the art may translate from plural to singular and/or from singular to plural as appropriate to the context and/or context. Alternatively, various singular/plural permutations may be explicitly set forth herein for the sake of clarity.

Generally, terms used herein, particularly in the appended claims (eg, the body of the appended claims), are generally intended to be "open-ended" terms (eg, the term "comprising" means "including but not limited to"). It should be construed as "without limitation", the term "having" should be construed as "at least having", the term "comprising" should be construed as "including but not limited to", etc.) It will also be understood by those skilled in the art that where a description is intended, such intent will be made explicit in the claims, and in the absence of such description, no such intent. For example, if you want to use only one item, you can use the term "single" or similar language. To aid understanding, the following appended claims and/or the description of this specification may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitation. However, the use of such phrases means that the introduction of a claim description includes such introduced claim description, even if the same claim contains the introductory phrase "one or more" or "at least one" and the indefinite article "a" or "an" should not be construed to mean limiting a particular claim to an embodiment containing only one such recitation (e.g., “a” and/or “an” should be construed to mean “at least one” or “one or more”). should be). The same is true of the use of definite articles used to introduce assertive citations in the same argument. Further, even if a particular number of citations for an introduced claim are explicitly recited, those of ordinary skill in the art will recognize that such citation should be construed to mean at least the number of times recited (e.g., "twice citation", other modifiers means two or more descriptions or two or more descriptions.)

Also, where there is a convention similar to "at least one of A, B, and C," such construction is generally intended in the sense that one of ordinary skill in the art would understand the convention (eg, "at least one of A, B, and C"). "system with" is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B and C together). Where there is a convention similar to "at least one of A, B or C, etc.", such configuration is generally intended in the sense that one of ordinary skill in the art would understand the convention (eg, "a system having at least one of A, B or C"). is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, C together). Whether in the description, claims, or drawings, virtually any separating words and/or phrases that present two or more alternative terms are understood to be contemplated for the possibility that they may include one of the terms, either of the terms, or both. It will be further understood by those skilled in the art that For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B”. Also, as used herein, the term "one of" followed by a list of a plurality of items and/or items of a plurality of categories means "one of", "any combination of", "any multiple of" "and/or "combinations of multiples" are intended to include items and/or categories of items, individually or in conjunction with other items and/or categories of other items. Moreover, as used herein, the term “set” or “group” is intended to include any number of items, including zero. Additionally, as used herein, the term “number” is intended to include any number, including zero.

Further, where features or aspects of the present disclosure are described in terms of a Markush group, those skilled in the art will recognize that the present disclosure is also described in terms of any individual member or subgroup of Markush group members.

As will be understood by one of ordinary skill in the art, in providing such detailed descriptions, for any and all purposes, all ranges disclosed herein also include any and all possible subranges and combinations of subranges thereof. Ranges in any list can be readily recognized as sufficiently descriptive and enabling such ranges to be divided into at least equal halves, thirds, quarters, fifths, tenths, and the like. As a non-limiting example, each of the ranges discussed herein may be arbitrarily split into a lower third, a middle third, and an upper third. Also, as will be understood by one of ordinary skill in the art, all language such as "up to", "at least", "greater than", "less than", etc., includes the recited numbers and subsequently subranged as discussed above. It means a range that can be continuously divisible. Finally, as will be understood by one of ordinary skill in the art, ranges include each individual number. Thus, for example, a group having 1-3 cells means a group having 1, 2 or 3 cells. Similarly, a group having 1-5 cells means a group having 1, 2, 3, 4 or 5 cells, etc.

Moreover, the claims should not be construed as limited to the order or elements presented, unless the effect is recited. Also, use of the term "means for" in all claims is intended to call 35 USC §112.(6) or the means-plus-function claim form, and claims without the term "means for" are intended to do so. doesn't happen

Claims (84)

A method of correcting a zero rate offset (ZRO) of a first inertial sensor located in a device, the method comprising:
determining ( 500 ) a level of stability of the device based on information related to at least one non-inertial sensor located on the device; and
when the stability level is higher than the threshold, performing (502) calibration of the ZRO of the first inertial sensor. According to claim 1,
receiving data from at least one non-inertial sensor indicative of stability of the device;
assessing a first stability state of the device based on data from the at least one non-inertial sensor;
receiving data from at least one inertial sensor indicative of stability of the device, wherein the at least one inertial sensor may comprise a first inertial sensor;
evaluating a second stability state of the device based on data from the at least one inertial sensor;
determining an overall stability state of the device based on the combination of the first stability state and the second stability state; and
If the overall stability state indicates that the device is sufficiently stable with respect to the ZRO calibration, perform calibration of the ZRO of the first inertial sensor.
How to include more. 3. The method of claim 1 or 2,
assessing the quality of the current ZRO value for the first inertial sensor;
determining a level of need to perform ZRO calibration based on an assessment of the quality of the current ZRO value for the first inertial sensor; and
Controlling the behavior of the device as a function of the level of need to perform ZRO calibration
How to include more. 4. The method of claim 3,
A method wherein determining the level of need to perform ZRO correction comprises generating a first flag indicative of the level, wherein the flag is in one of the following states:
a no-constraint state indicating that there is currently no need to correct the ZRO;
A stay-stationary state where the overall stability state of the device indicates that the device should be stationary.
Conveniently, a non-urgent-request-for-the-device-to-become-stationary indicating that the device should be in a stationary state. ) state; and
If possible, an agent-request-for-the-device-to-become-stationary state indicating that the device should be stopped. 5. The method of claim 4,
(1) When ZRO correction is being performed, the first flag is generated in the stay-stationary state,
(2) when it is determined that the current ZRO value is within the first accuracy range, a non-urgent-request-to-become-stationary first flag is generated in the state and ;
(3) a first flag is generated in an agent-request-to-become-stationary state where it is determined that the current ZRO value is within the second accuracy range; And
(4) A method in which the first flag is generated in the no-constrained state when it is determined that the current ZRO value is within the third accuracy range. 3. The method of claim 2,
how the first stable state can have one of the following values;
a stable-without-vibration state indicating that the device is stationary enough to perform a first type of ZRO correction;
a stable-with-vibration condition indicating that the device is stable enough to perform a second type of ZRO calibration;
Unknown status indicating that the stability level of the device is unknown;
An IN-MOTION state indicating that the device is insufficiently stable to perform ZRO calibration. 3. The method of claim 2,
A method wherein the first stability state flag comprises a plurality of stability states indicating that a ZRO correction may be performed. 8. The method according to any one of claims 1 to 7,
wherein performing calibration of the ZRO of the first inertial sensor comprises performing one of a plurality of ZRO calibration processes as a function of a stability level of the device. 9. The method according to any one of claims 1 to 8,
At least one inertial sensor comprising a first sensor and a method in which non-inertial sensors are mounted to a device. 10. The method according to any one of claims 1 to 9,
How the device is a robot. 11. The method of claim 10,
How the device is a robotic vacuum cleaner. 12. The method according to any one of claims 1 to 11,
A method wherein the at least one non-inertial sensor comprises at least one wheel encoder and a camera. 12. The method according to any one of claims 1 to 11,
wherein the first inertial sensor is a gyroscope. 4. The method of claim 3,
a method in which the quality of the current ZRO value is based on at least one of the following;
time elapsed since ZRO calibration was performed;
temperature change after ZRO calibration is performed; and
Calibration of the quality of the last ZRO calibration. 4. The method of claim 3,
A method, wherein assessing the quality of the current ZRO value for the first inertial sensor includes determining a standard deviation with respect to the ZRO value. 16. The method of claim 15,
Determining the standard deviation associated with the ZRO value is
determining a standard deviation of output samples of the first inertial sensor used to generate the ZRO value;
dividing the standard deviation of the output samples of the first inertial sensor used to generate the ZRO value by the square root of the number of output samples of the first inertial sensor used to generate the ZRO value; and
multiplying the result by a limiting factor determined based on observation experience with the first inertial sensor.
How to include. 16. The method of claim 15,
Determining the standard deviation with respect to the ZRO value is
filtering the output samples of the first inertial sensor used to generate the ZRO value with an infinite impulse response (IIR) filter; and
Determining the standard deviation of filtered samples
How to include. 4. The method of claim 3,
maintaining the fitting of ZRO values as a function of temperature;
to evaluate the quality of fittings;
determining a level of need to perform a ZRO calibration based on an assessment of fit quality; and
Controlling the behavior of the device as a function of the level of need to perform ZRO corrections based on the assessed quality of the fit.
How to include. 19. The method according to any one of claims 1 to 18,
Performing the calibration of the ZRO of the first inertial sensor is
determining a temperature of the first inertial sensor;
collecting a plurality of samples of the output of the first inertial sensor during periods in which the overall stability state indicates that the device is sufficiently stable for ZRO calibration and the temperature of the first inertial sensor is stable; and
estimating the ZRO of the first inertial sensor at the temperature of the first inertial sensor during recruitment as a function of samples
How to include. 20. The method of claim 19,
determining whether the device is stable and substantially equally stable over at least two consecutive distinct periods during which the temperature of the first inertial sensor is stable and substantially the same over the at least two consecutive distinct periods; and
determining a gap time between at least two consecutive distinct periods;
wherein performing a ZRO calibration of the first inertial sensor comprises combining at least two consecutive distinct periods to generate a ZRO estimate when a gap time is below a threshold. A method of operating a robotic device, comprising:
sending ( 600 ) one of a plurality of motion control requests to the controller based on a zero rate offset (ZRO) error associated with one or more inertial sensors located in the robotic device; and
Controlling movement of the robotic device based on the motion control request (602)
How to include. 22. The method of claim 21,
When the robotic device is stopped, and when the current ZRO error level is less than or equal to the high performance threshold, one of the plurality of motion control requests notifies the controller that the motion of the robotic device is unrestricted. 23. The method of claim 21 or 22,
When the robotic device is stopped and the current ZRO error level is between the high performance threshold and the low performance threshold, one of the plurality of motion control requests notifies the controller that the robotic device can be arbitrarily stopped. 24. The method according to any one of claims 21 to 23,
When the robotic device is stopped and the current ZRO error level is less than or equal to the low performance threshold, one of the plurality of motion control requests notifies the controller that the robotic device is required to stop. 25. The method according to any one of claims 21 to 24,
When the robotic device is non-stationary, and the current ZRO error level is lower than or equal to the non-emergency threshold, one of the plurality of motion control requests notifies the controller that the motion of the robotic device is unrestricted. 26. The method according to any one of claims 21 to 25,
When the robotic device is non-stop and the current ZRO error level is between the non-emergency threshold and the emergency threshold, one of the plurality of motion control requests notifies the controller of a non-urgent need for the robotic device to stop. 27. The method according to any one of claims 21 to 26,
When the robotic device is non-stationary and the current ZRO error level is greater than or equal to the emergency threshold, one of the plurality of motion control requests notifies the controller that there is an urgent need for the robotic device to stop. 28. The method according to any one of claims 21 to 27,
A method in which the ZRO error level is determined based on the standard deviation of the ZRO estimate over time. 29. The method according to any one of claims 21 to 28,
How the controller can selectively ignore one of the plurality of motion control requests. 30. The method of claim 29,
A method in which a controller may ignore one of a plurality of motion control requests based on one or more sensor characteristics, desired performance, and use cases. 31. The method according to any one of claims 21 to 30,
A method for determining whether a robotic device is non-stationary or stationary based on data received by a controller from at least one non-inertial sensor. 32. The method of claim 31,
A method wherein the controller generates a motion intent signal based on data received from the at least one non-inertial motion sensor and transmits the motion intent signal to an inertial motion unit that generates one of a plurality of motion control requests. 33. The method of claim 32,
The method wherein the inertial operation unit is a software body running on the same chip as the controller. 33. The method of claim 32, wherein the inertial operation unit operates on a chip separate from the chip serving as the controller. A method of correcting a zero rate offset (ZRO) of a first inertial sensor located in a device, the method comprising:
suspending the device 700 for a first period of time for reasons unrelated to the ZRO calibration;
accumulating (702) ZRO correction data during the first period;
moving (704) the device after the first period of time;
suspending (706) the device for a second period of time for reasons unrelated to the ZRO calibration;
accumulating 708 ZRO correction data for a second time period; and
performing (710) ZRO correction using the accumulated ZRO correction data from the first period and the second period. 36. The method of claim 35,
after the first period, starting a timer after the device moves; and
and accumulating ZRO correction data for a second period only if the timer does not expire when holding is stopped. 37. The method of claim 36,
when accumulating ZRO correction data during the first period, starting a second timer; and
and continuing to accumulate the ZRO correction data only until the second timer expires. 38. The method according to any one of claims 35 to 37,
The method further comprising stopping the device specifically for a third period to perform the ZRO calibration. 39. The method according to any one of claims 35 to 38,
wherein the first period and the second period are less than the third period. 37. The method of claim 36,
How the timer is kind of after 10 seconds. 41. The method of any one of claims 35-40,
Performing ZRO Calibration in ZRO
determining a temperature of the first inertial sensor;
collecting multiple samples of the first inertial sensor output during a period in which the overall stability state indicates that the device is sufficiently stable for ZRO calibration and the temperature of the first inertial sensor is stable; and
A method comprising estimating the ZRO of the first inertial sensor at the temperature of the first inertial sensor during collection as a function of samples. 21. The method according to any one of claims 1 to 20,
determining a level of stability of the device based on information associated with at least one non-inertial sensor located on the device;
The method further comprising determining a level of stability of the device based on information related to at least one inertial sensors located on the device. at least one non-inertial sensor 104;
at least one inertial sensor 102;
at least one motor (106);
by determining a level of stability of the device based on information associated with the at least one non-inertial sensor (104); and a controller 100 for correction of a zero rate offset (ZRO) of an inertial sensor 102 located in the device by performing a ZRO correction of one of the at least one inertial sensor 102 when the stability level crosses a threshold. ;
device comprising a. 44. The method of claim 43,
the controller receives data from at least one non-inertial sensor indicative of stability of the device; estimate a first stability state of the device based on data from the at least one non-inertial sensor; receive data from the at least one inertial sensor indicative of stability of the device, and estimate a second stability state of the device based on the data from the at least one inertial sensor; determine an overall stability state of the device based on the combination of the first stability state and the second stability state, wherein the overall stability state indicates that the device is stable enough to perform a ZRO calibration and at least one of the first stability state and the device a second stability state indicating that it is not stable enough to perform a ZRO correction; and perform ZRO calibration of the at least one inertial sensor when the overall stability state indicates that the device is sufficiently stable for ZRO calibration. 45. The method of claim 43 or 44,
the controller
estimate a quality of a current ZRO value for the at least one inertial sensor;
determine a level of need to perform a ZRO calibration based on an estimate of a quality of a current ZRO value for the at least one inertial sensor; and
A device further configured to control the operation of the device as a function of a level of need for performing ZRO calibration. 46. The method of claim 45,
an apparatus wherein determining a level for a need to perform ZRO correction comprises generating a first flag indicating the level, wherein the flag is one of the following;
no-contract state indicating no need for current ZRO correction;
a stationary state where the overall stability state of the device indicates that the device must be stationary;
If convenient, a non-agent-request-for-the-devis-to-become-stationary state indicating that the device should be stationary; and
If possible, an agent-request-for-the-devis-to-become-stationary state indicating that the device should be stationary. 47. The method of claim 46,
(1) when ZRO correction is being performed, a first flag is generated in the stay-stationary state, and (2) when the current ZRO value is determined to be within the first accuracy range, non-agent-request-four When the first flag is generated in the -the-devis-to-become-stationary state, and (3) the current ZRO value is determined to be within the second accuracy range, agent-request-for-the-devis A device in which a first flag is generated in a to-become-stationary state, and (4) a first flag is generated in a no-contract state when the current ZRO value is determined to be within a third accuracy range. 45. The method of claim 44,
The first stable state is a device that may have any one of the following values;
a stable-we-out-vibration indicating that the device is stationary enough to perform a first type of ZRO correction;
stable-with-vibration indicating that the device is stable enough to perform a second type of ZRO correction;
Unknown state indicating that the level of stability of the device is unknown; and
In-motion state indicating that the device is insufficiently stable to perform ZRO calibration. 45. The method of claim 44,
A device comprising a plurality of stability states, wherein the stability state flag indicates that a ZRO correction may be performed. 50. The method according to any one of claims 43 to 49,
and performing calibration of the ZRO of the first inertial sensor comprises performing one of a plurality of ZRO calibration processes as a function of a stability level of the device. 51. The method according to any one of claims 43 to 50,
A device in which the at least one inertial sensor comprises a first sensor, and wherein non-inertial sensors are mounted to the device. 52. The method according to any one of claims 43 to 51,
The device is a robot device. 53. The method of claim 52,
The device is a robot vacuum cleaner. 54. The method according to any one of claims 43 to 53,
wherein the at least one non-inertial sensor comprises at least one wheel encoder and a camera. 55. The method according to any one of claims 43 to 54,
wherein the first inertial sensor is a gyroscope. 46. The method of claim 45,
a device wherein the quality of the current ZRO value is based on at least one of the following;
Time flow since ZRO calibration was performed,
temperature change since ZRO calibration was performed; and
Calibration quality of recent ZRO calibrations. 46. The method of claim 45,
wherein estimating a current ZRO value for the first inertial sensor includes determining a standard deviation associated with the ZRO value. 58. The method of claim 57,
Determining the standard deviation associated with the ZRO value is
determining a standard deviation of output samples of the first inertial sensor used to generate the ZRO value;
dividing the standard deviation of the output samples of the first inertial sensor used to generate the ZRO value by the square root of the number of output samples of the first inertial sensor used to generate the ZRO value; and
and multiplying the result by a limiting factor determined based on observational experience of the first inertial sensor. 58. The method of claim 57,
Determining the standard deviation associated with the ZRO value is
filtering the output of the sample of the first inertial sensor used to generate the ZRO value with an infinite impulse response (IIR) filter; and
Determining the standard deviation of filtered samples
device comprising a. 46. The method of claim 45,
maintaining the ZRO value as a function of temperature;
Estimating the quality of fittings;
determining a level of need to perform a ZRO correction based on the estimate of the quality of the fit; and
Controlling the motion of the device as a function of the level of need to perform ZRO corrections based on the estimated quality of the fit.
device comprising a. 61. The method of any one of claims 43 to 60,
Performing the calibration of the ZRO of the first inertial sensor is
determining a temperature of the first inertial sensor;
collecting a plurality of samples of the output of the first inertial sensor during periods in which the overall stability state indicates that the device is sufficiently stable for ZRO calibration and that the temperature of the first inertial sensor is stable; and
The apparatus further comprising estimating the ZRO of the first inertial sensor at the temperature of the first sensor during collection as a function of samples. 62. The method of claim 61,
determining whether the device is stable and substantially equally stable over at least two consecutive distinct periods during which the temperature of the first inertial sensor is stable and the at least two consecutive distinct periods; and
determining a gap time between at least two consecutive distinct periods;
wherein performing a ZRO calibration of the first inertial sensor comprises combining at least two consecutive distinct periods to generate a ZRO estimate when a gap time is below a threshold. The method comprises at least one motor (106); and
Receive one of a plurality of motion control requests based on a current zero rate offset (ZRO) error level associated with one or more inertial sensors 102 located in the robotic device, and a motion control request using at least one motor 106 . A controller 100 configured to control the movement of the robot device based on
A robot device comprising a. 64. The method of claim 63,
When the robotic device is stationary and the current ZRO error level is less than or equal to the high performance threshold, one of the plurality of motion control requests notifies that the robot device's movement is unrestricted. 65. The method of claim 63 or 64,
When the robotic device is stopped and the current ZRO error level is between the high performance threshold and the low performance threshold, one of the plurality of motion control requests notifies the controller that the robotic device can be arbitrarily stopped. 66. The method of any one of claims 63 to 65,
When the robotic device is stopped and the current ZRO error level is less than or equal to the low performance threshold, one of the plurality of motion control requests notifies the controller that the robotic device is required to be stopped. 67. The method according to any one of claims 63 to 66,
When the robot device is non-stationary, and the current ZRO error level is lower than or equal to the non-emergency threshold, one of the plurality of motion control requests notifies the controller that there is no restriction on the movement of the robot device. 68. The method according to any one of claims 63 to 67,
When the robotic device is non-stop, and the current ZRO error level is between the non-emergency threshold and the emergency threshold, one of the plurality of motion control requests notifies the controller of a non-urgent need for the robotic device to stop. 69. The method according to any one of claims 63 to 68,
When the robotic device is non-stationary and the current ZRO error level is greater than or equal to the emergency threshold, one of the plurality of motion control requests notifies the controller of an urgent need for the robotic device to stop. 70. The method according to any one of claims 63 to 69,
A robotic device in which the ZRO error level is determined based on the standard deviation of the ZRO estimate over time. 71. The method according to any one of claims 63 to 70,
The controller is a robotic device capable of selectively ignoring one of a plurality of motion control requests. 72. The method of claim 71,
A robotic device wherein the controller is capable of disregarding one of a plurality of motion control requests based on one or more sensor characteristics, desired performance, and use cases. 73. The method according to any one of claims 63 to 72,
A robotic device wherein the controller determines whether the robotic device is stationary or stationary based on data received by the controller from at least one non-inertial motion sensor. 74. The method of claim 73,
The controller generates a motion intent signal based on data received from the at least one non-inertial motion sensor, and sends the motion intent signal to an inertial motion unit that generates one of a plurality of motion control requests. 75. The method of claim 74,
The inertial operation unit is a robot device that is a software body operated on the same chip as the controller. 75. The robotic device of claim 74, wherein the inertial operation unit operates on a chip separate from the chip serving as the controller. at least one motor (106); and
stop the device 700 for a first period of time for reasons unrelated to the ZRO calibration;
accumulate (702) ZRO correction data for a first period;
move (704) the device after the first period of time;
halt 706 the device for a second period of time for reasons unrelated to the ZRO calibration;
accumulate ZRO correction data for a second period of time (708); and
The controller 100 configured to perform (710) ZRO correction using the accumulated ZRO correction data from the first period and the second period.
A device comprising a. 78. The method of claim 77,
a timer configured to start after the first period of time, after the device moves; and wherein the apparatus is further configured to accumulate ZRO correction data for a second period only when the timer does not expire when the apparatus is stopped. 79. The method of claim 78,
a second timer configured to start when accumulating ZRO correction data during the first period; and wherein the controller is further configured to continue accumulating the ZRO correction data only until the second timer expires. 80. The method according to any one of claims 77 to 79,
The apparatus further configured to cause the controller to pause the apparatus specifically for a third period to perform the ZRO correction. 81. The method of any one of claims 77-80,
wherein the first period and the second period are less than the third time period. 79. The method of claim 78,
The timer expires after 10 seconds. 83. The method of any one of claims 77-82, wherein
Performing ZRO Calibration in ZRO
determining a temperature of the first inertial sensor;
collecting a plurality of samples of the first inertial sensor output during a period in which the overall stability state indicates that the device is sufficiently stable for ZRO calibration and that the temperature of the first inertial sensor is stable; and
and estimating the ZRO of the first inertial sensor at the temperature of the first inertial sensor during collection as a function of samples. 63. The method according to any one of claims 43 to 62,
and the controller for correcting a zero rate offset (ZRO) of an inertial sensor located in the device further determines a stability level of the device based on the at least one inertia-related information.

Images