JPWO2019241811A5 - - Google Patents

Description

Embodiments of the present invention relate to autonomous mobile service robots such as robots that perform surface treatment (eg, floor cleaning), such as transporting objects or monitoring and inspecting areas, and control methods for such autonomous mobile robots.

In recent years, autonomous mobile robots, especially service robots, are increasingly used not only in home environments but also in work environments. For example, autonomous mobile robots can be used to clean floors, monitor buildings, enable position- and activity-independent communications, or transport objects.

In doing so, systems that generate maps of the environment for target navigation using the SLAM (Simultaneus Localization and Mapping) algorithm are increasingly being used (see, eg, Non-Patent Document 1). ). The algorithms used to control and monitor the robot can be highly optimized with respect to the sensors and actuators used and the particular shape of the robot. This has the disadvantage that the implemented software can only be reused in large-scale adaptive development. Another approach incorporates different levels of abstraction into the software to support different hardware configurations. These solutions are often computationally intensive and require more expensive hardware.

BH Durrant-Whyte and T.D. Bailey, "Simultaneus Localization and Mapping (SLAM): Part I The Essential Algorithms", IEEE Robotics and Automation Magazine, Vol. 2, pp. 6, 1999, pp. 13-99,

With the demand to develop and market increasingly intelligent systems, the complexity of behavioral routines used in autonomous mobile robots is constantly increasing. However, as complexity increases, it is usually more likely to malfunction in response to an error, as with many complex software applications. This is because the navigation software and control software have been detected, for example due to a failure, unrecognized programming error or unwanted external influence, even though the robot has sensors to detect dangerous situations. It means not responding properly to dangerous situations. Proving that a robot responds appropriately and accurately to all possible dangerous situations will require considerable effort as the complexity of navigation and control software increases. Proof of such functional safety may be required by law for certain applications. Functional safety requirements are also subject to various standards (eg EN / IEC 61508 and EN / IEC 62061).

Therefore, an object underlying the present invention is, among other things, to provide an inexpensive and reusable navigation solution, and an autonomous mobile robot having a robust safety mechanism for the autonomous mobile robot and a corresponding control method.

The above object is achieved by the autonomous mobile robot according to claim 1 and the method according to claim 12. Various exemplary embodiments and further developments are the subject of the dependent claims.

The autonomous mobile robot is described below. According to one embodiment, the autonomous mobile robot receives a control signal and is configured to move the autonomous mobile robot according to the control signal, a navigation sensor for detecting navigation features, and a navigation sensor. It has a navigation unit, and is coupled to. This navigation unit is configured to receive information from the navigation sensor and plan the movement of the autonomous mobile robot. The autonomous mobile robot further has a control unit configured to receive motion information representing the motion planned by the navigation unit and generate a control signal based on the motion information. The autonomous mobile robot is further coupled to the control unit and has additional sensors, which receive additional sensor information from the additional sensors. The control unit preprocesses further sensor information and provides the preprocessed sensor information to the navigation unit in a predefined format. The planning of the movement of the autonomous mobile robot by the navigation unit is performed based on the information from the navigation sensor and the preprocessed sensor information provided by the control unit. The robot configured in this way can completely functionally separate the navigation unit and the control unit. In addition, the corresponding method is described.

Inexpensive and reusable navigation solutions, and autonomous mobile robots with robust safety mechanisms for autonomous mobile robots and corresponding control methods can be provided.

As an example, various autonomous mobile robots and various possible dangerous situations are shown. It is a block diagram which illustrates the structure of the autonomous mobile robot. It is a block diagram of the exemplary structure of the control unit of an autonomous mobile robot, and the interface between the navigation unit and the motor control. It is a top view which shows an example of the lower surface of an autonomous mobile robot.

The present invention will be described in more detail below with reference to the embodiments shown in the figure. The figures are not necessarily on scale and the invention is not limited to the embodiments shown. Rather, the emphasis is on explaining the underlying principles of the invention.

FIG. 1 shows various examples of an autonomous mobile robot 100 that autonomously executes activities and navigates its environment by a map, as well as possible dangerous situations. Activities in the sense of the present application go beyond the mere navigation of a robot in its environment and include, for example, floor treatment, floor cleaning, inspection and monitoring activities, transport operations, or activities for user entertainment.

FIG. 1A is a diagram showing, for example, a cleaning robot configured to clean a floor surface, particularly to suck up dust on the floor surface. The cleaning robot typically moves forward on at least three wheels (usually two of which are driven) (not shown in FIG. 1 (a)). Further, the back side of the cleaning robot is usually provided with a rotating brush and / or a suction unit for collecting dirt while the robot 100 moves on the floor surface. As shown in FIG. 1 (b), if the robot falls over a falling edge such as a step on a staircase, the cleaning robot may be damaged. In addition, if the robot 100 falls on the floor or hits a nearby object or human, the floor, nearby object, or human may also be damaged. Therefore, some autonomous mobile robots 100 have a floor distance sensor (not shown in FIG. 1) that can timely detect falling edges such as steps of stairs in order to avoid falling. There is. The floor distance sensor is also called a floor detection sensor or a floor sensor.

FIG. 1 (c) is a diagram showing an example of a telepresence robot. Telepresence robots typically have an interface 101, such as a display, smartphone, tablet, etc. (a user interface also known as a human-machine interface (HMI)). The interface 101 is attached to the upper end of the vertical arm 102 of the robot 100. A robot body having a drive module 103 is attached to the lower end of the vertical arm 102. Due to the slim shape of the robot 100 and the attachment of the interface 101 to the upper end of the vertical arm 102, such a telepresence robot has a relatively high center of gravity. Basically, the robot balances itself. However, for example, when moving over a steep surface, the robot 100 can tip over, which can damage the device. Even if the acceleration is too high, or if the threshold or step is exceeded, the robot 100 may fall. Further, if the robot 100 is tilted or overturned, the surrounding floor surface, nearby objects and people may be damaged. An example of tilting the telepresence robot is shown in FIG. 1 (d). For this reason, the telepresence robot can have sensors (not shown in FIG. 1) configured to determine the state (particularly tilt), acceleration and / or angular velocity of the robot 100. Similarly, the telepresence robot can include sensors that detect thresholds (eg, door thresholds) or steps to adapt the robot's running behavior and avoid the robot's tilt.

FIG. 1 (e) is a diagram showing an example of an auxiliary robot, particularly a transport robot. The transport robot usually has a transport table 104 on which a transported object such as a plate or a glass is placed. On the back surface of the transport robot, for example, wheels (not shown in FIG. 1 (e)) are provided, whereby the transport robot can move. Such a robot 100 can, for example, support the elderly in their daily lives, thus allowing them to live independently. It is fundamentally important for the transporting robot to avoid collisions in order to avoid tilting the object to be transported or the entire robot 100. To this end, the robot 100 is configured with a wide variety of sensors (eg, lasers) configured to detect stationary or moving objects or people in the robot 100's environment (possibly with associated sensor signal processing). It can have a rangefinder, an optical triangulation sensor, a camera, etc.).

Therefore, basically, various methods are used to autonomously move the robot in the area of use, recognize the dangerous situation that may occur for the autonomous mobile robot 100 at that time, and make the recognized dangerous situation. Accidents can be avoided by taking appropriate action (which avoids, or at least mitigates) accidents. Such a robot 100 usually includes navigation software and control software for controlling the autonomous mobile robot 100. However, such navigation and control software executed by the processors in the control module is becoming more and more complex. Increasing the complexity of navigation and control software increases the risk of unwanted programming errors. In addition, more and more autonomous mobile robots 100 are connected to the Internet. Thereby, for example, the robot 100 can be controlled even if the user is not near the robot 100. Similarly, the robot 100's firmware, especially navigation software and control software, can be updated via the Internet. For example, software updates can be downloaded automatically or at the request of the user. This feature is also known as Over the Air Programming (OTA Programming), OTA Upgrade, or Firmware Over the Air (FOTA).

However, connecting the autonomous mobile robot 100 to the Internet poses a danger of strangers accessing the robot 100 (eg, so-called hacking, cracking, or jailbreaking of the robot), and the autonomous mobile robot 100 is correctly in a dangerous situation. It affects the autonomous mobile robot 100 so that it does not react, which may cause an accident. The entire navigation software and control software can be stored in the robot 100 itself or a storage medium arranged in the robot. However, it is also possible to store a part of the navigation software and the control software in an external device such as a cloud server. When part of the navigation software and control software is stored in an external device, part of the robot 100 is generally no longer real-time capable. The robot 100 is known to use non-deterministic Monte Carlo methods or machine learning such as, for example, deep learning learning (also known as deep machine learning) for its navigation and control software algorithms. The Monte Carlo algorithm is a randomized algorithm that is allowed to give false results with a certain upper probability. Monte Carlo algorithms are usually more efficient than deterministic algorithms. Deep learning is a type of optimization method for artificial neural networks, which usually has a large number of hidden layers between the input layer and the output layer, thereby having a large internal structure. Neither the Monte Carlo algorithm nor machine learning is difficult to understand because the causal relationship is not determined from the beginning. For this reason, it is very difficult to prove the safe operation of the robot 100 and ensure that the navigation software and control software of the robot 100 respond correctly and in a timely manner in any dangerous situation in order to avoid accidents. be. At the same time, the use of such new robot control methods is necessary to make the autonomous mobile robot 100 more intelligent. The improved intelligence allows the robot 100 to more easily adapt to the user's life and their environment.

Therefore, it may be important or necessary to enable robot behavior whose safety is provable without limiting the intelligence of the robot 100. According to one embodiment, the autonomous mobile robot 100 includes a safety module, also called a risk detection module, in addition to a navigation unit that executes routes and work plans using the navigation software. In the example described here, the safety module operates functionally independently of the navigation module. Basically, the safety module is configured to monitor the robot's behavior and recognize dangerous situations independently of the navigation module. If the robot's behavior in the detected danger situation is considered to be "wrong", "dangerous", or "inappropriate", the safety module can initiate appropriate measures (safety measures). As a countermeasure, for example, it is conceivable to stop the robot 100 or change the traveling direction of the robot 100. This takes advantage of the fact that it is usually easier to determine which action should not be performed because it is unsafe than to determine the correct action.

Autonomous mobile robots are increasingly providing services in private and business environments. One of the basic functions is to create a map of the environment using appropriate sensors and use the map for autonomous navigation. A fundamental problem in the further development of robotics is that the software and algorithms used are strongly tied to the underlying hardware such as drive motors or other work units required for activity and sensors built into the robot. It is that you are. Reuse of software in the construction of new robots is difficult due to such strong ties.

Two approaches are known to this problem. One is to make available a mobile platform that provides all the requirements for moving a robot. New applications will need to be built on this platform, making this approach inflexible. Another approach is to separate hardware-dependent and hardware-independent modules and strongly modularize the software. This may require a high level of hardware abstraction and usually has a negative impact on system performance.

In contrast, the approach pursued according to one embodiment of the invention aims at the functional separation of algorithms associated with specific hardware. This can be combined with the navigation unit and safety module separation described above.

FIG. 2 shows a block diagram of an exemplary structure of an autonomous mobile robot 100 having a plurality of functionally separated units. In general, a unit may be an independent assembly (hardware), a component of software for controlling a robot 100 to perform a desired task in a particular area of robot use, or a combination of both (eg, connected peripheral components). Dedicated hardware and appropriate software and / or firmware provided.

In the present embodiment, the autonomous mobile robot 100 includes a drive unit 170, and the drive unit 170 may include, for example, an electric motor, gears, wheels, and the like. The robot 100 may further include a work unit 160 (process unit) that performs a particular process, such as cleaning the floor or transporting items. The work unit 160 grabs and transports, for example, a cleaning unit (eg, a brush, a dust collector) for cleaning the floor, a height-adjustable and / or swivel carrier designed as a tray, or an object. It may be a gripping arm for the purpose. In the case of a telepresence robot, a monitoring robot, or the like, the work unit 160 is not always necessary. For example, a telepresence robot would typically have a multimedia unit with , for example, a microphone, camera, screen, etc., connected to a human-machine interface 200 to communicate between multiple people spatially separated from each other. It is equipped with a complicated communication unit 130. Another example is to use special sensors (eg cameras, motion sensors, microphones) to detect certain (abnormal) events (eg fires, lights, unauthorized persons, etc.) in surveillance driving and to it. It is a monitoring robot that can notify the control station accordingly.

The robot 100 may further include a communication unit 130 for establishing a communication connection to a human-machine interface (HMI) 200 and / or another external device 300. The communication connection may be, for example, a direct wireless connection (eg, Bluetooth®), a local wireless network connection (eg, WiFi or Zig-Bee), or an internet connection (eg, to a cloud service). As the human machine interface 200, for example, a tablet PC, a smartphone, a smart watch, a computer or a smart TV is used. In some cases, the human-machine interface 200 may be integrated directly into the robot 100 and may be operated via keys, gestures, and / or voice inputs and outputs. At least a portion of the aforementioned external hardware and software may be located at the human-machine interface 200. Examples of the external device 300 are computers and servers capable of exchanging calculations and / or data, external sensors providing additional information, or other home appliances (eg, other appliances) with which the autonomous mobile robot 100 interacts and / or exchanges information. Robot). For example, information about the autonomous mobile robot 100 (eg, battery status, current work instructions, map information, etc.) may be provided via the communication unit 130, or, for example, related to the work instructions of the autonomous mobile robot 100. An instruction to be executed (for example, a user command) may be received.

According to the example illustrated in FIG. 2, the robot 100 may have a navigation unit 140 and a control unit 150 configured to exchange information. At this time, the control unit 150 receives the movement information (movement information) and the work information generated by the navigation unit 140. The travel information is, for example, a planned route point, route segment (eg, arc), or velocity information. The path point can be specified, for example, based on the current posture of the robot (the posture represents the position and the direction). For example, in the case of a path segment, the distance to be moved and the rotation angle can be specified (when the distance is zero, the vehicle rotates on the spot, and when the rotation angle is zero, the vehicle goes straight). As the velocity information, for example, a translational velocity and an angular velocity driven for a predetermined time can be used. In this way, the navigation unit 140 plans a specific movement (eg, a specific route segment) in advance and transmits this to the control unit 150 (as movement information). The control unit 150 is configured to generate a control signal for the drive unit 170 from the movement information. These control signals can be all signals suitable for controlling the actuator (particularly the motor) of the drive unit. For example, it may be the required rotation speed of the left and right wheels of the differential drive device. Alternatively, the motor can be controlled directly by changing the voltage and / or current. In principle, the specific hardware configuration of the robot (actuator type and position) must be known in order to generate control signals from the movement information received from the navigation unit 140, but the movement information is more abstract. At a high level, it is determined primarily independently of the hardware used. Thus, if the drive unit 170 is modified, the required adaptive development is limited to the control unit 150.

Similar to the movement information, the work information may be converted into a control signal of the work unit 160. The work information can describe, for example, whether the work unit is active and with what ability it is active. For example, the work unit 160 may be a cleaning unit including a rotating brush and a suction unit. The work information includes whether the cleaning unit is currently active, how strong it should be, and so on. The control signal generated by this directly controls, for example, the power of the motor of the brush or the suction unit. In particular, the navigation unit 140 uses the information provided by the navigation sensor 125 for planning the movement plan described above and for constructing / updating a map of the robot use area. Such a navigation sensor 125 can be, for example, a non-contact optical sensor (eg, a triangulation sensor).

Further, the control unit 150 may collect information from the control sensor 120, which collects sensor information unique to the robot. This includes, for example, a safety sensor 122 for detecting safety-critical situations in an environment near the robot. An example of the safety sensor is the floor distance sensor for detecting the falling edge described above. The other safety sensor 122 may be a tactile sensor (eg, a contact switch) for detecting contact with an obstacle, or a short range sensor (eg, an infrared sensor) for detecting an obstacle near the robot. .. This makes it possible to satisfactorily detect an unintended collision with an obstacle. Another example of the control sensor 120 is the motion sensor 123, which is used to monitor the movement of the robot 100 specifically controlled by the control unit 150, which movement is actually a navigation unit. It does not exactly match the movement planned by 140. This includes, for example, mileage meters such as wheel encoders, accelerometers, gyroscopes (eg, integrated into an inertial measurement unit (IMU)) and the like. Another example of the control sensor 120 is a posture (position) sensor for determining the tilt of the robot 100 and its change. Another example of the control sensor 120 is a status sensor 124 for detecting the state of each part of the robot. This includes, for example, ammeters and voltmeters that determine the power consumption of the drive unit. Other status sensors (status sensors) may include a wheel contact switch for determining whether the robot is in contact with the floor surface, or a switch for indicating the presence or absence of parts such as brushes and dust bins.

The measured value of the control sensor 120 is detected and evaluated by the control unit 150. The result may be provided to the navigation unit 140 in a standardized format. This may be done at regular intervals, at periodic intervals, or after a request from the navigation unit 140. The type of information depends on the sensor and can be mapped to a sensor model typical of the sensor. For example, in the case of a differential drive device, the odometry data can describe the fraction of one rotation (wheel encoder) of the wheel. This makes it possible to determine how far the wheels belonging to the encoder have traveled. The combination of the two wheels of the differential drive and its position causes changes in mileage and orientation. The odometry information passed to the navigation module 140 indicates changes in the position and orientation of the robot since the last information. For example, a floor distance sensor can be used to determine the falling edge, and many measurement principles can be used for this determination. The control unit 150 determines whether or not any of the sensors has detected a falling edge based on the raw data from the floor distance sensor. Even if the detected falling edge position is transmitted to the navigation unit 140 in the form of a triggered floor distance sensor position with respect to the robot's fixed coordinate system (eg, starting from the center of motion of the differential drive). good. Alternatively, the number (ID) associated with the sensor may be transmitted to the navigation unit 140. In the navigation unit 140, this number (ID) determines the position associated with the triggered floor distance sensor from a predetermined parameter. Relevant parameters (sensor numbers and positions) can be loaded, for example, during navigation unit initialization. This reduces data traffic and shifts computation to the more powerful processors in the navigation unit. In this way, the information provided by the control sensor 120 is passed to the navigation unit 140 in an abstract form independent of the specific sensor.

Other examples of such sensors include tactile sensors for detecting contact with obstacles (eg, collisions). Corresponding information about the detected contact can be transmitted using the position or number (ID) of the triggered sensor (as if a falling edge was detected) when an event is detected. Sensors that avoid collisions can detect nearby obstacles without contact. For this purpose, for example, an infrared sensor that emits an infrared signal is used. The presence or absence of obstacles and the distance can be inferred from the reflection. For these sensors, in addition to the sensor position, for example, a distance that is reliably free of obstacles can be transmitted to the navigation device.

According to the example shown in FIG. 2, in addition to the sensor information from the control unit 150, the navigation unit 140 also provides information about the robot's environment that the robot can use to orient itself. Receives direct sensor measurements from one or more navigation sensors 125. This means that sensors 125 (s) can be used to determine the location of suitable navigation features for building a map. Such a navigation sensor 125 is, for example, a sensor for non-contact measuring the distance to a longer distance object, for example by triangulation or flight time measurement, especially such as a laser distance sensor or a 3D camera. It is a sensor that determines the distance. These sensors can provide information about the location of obstacles and record them on a map. Additionally or additionally, the navigation sensor 125 may be a camera that provides an image of the environment around the robot. The image can serve as a direct navigation feature. Additional or alternative, object recognition and image processing can detect features such as corners and edges of the surrounding image that serve as navigation features. In particular, by combining odometry information (mileage information) from the control unit 150 with navigation features, it is possible to build a map of the environment using an SLAM algorithm known per se and determine the position of the robot in the map. And can be used for navigation and work planning. Such maps can be built temporarily (ie, each time they are used), saved for repeated use, and loaded as needed. The advantage of this solution is the tight integration of the navigation sensor and its associated algorithms. Therefore, the combination of the navigation unit 140 and the navigation sensor 125 can be relatively easily incorporated into a new robot application. The only requirement is a control unit 150 having a predetermined interface for exchanging data in the standardized format described above (standardized format). In addition, some parameters such as the position and orientation of the navigation sensor 125 in the robot must be predetermined and / or determined (eg by calibration).

Further, in addition to the sensor for detecting the environment, other sensors essential for navigation can be closely connected to the navigation unit, and the signal can be directly evaluated by the navigation unit. One example is an inertial measurement unit (IMU) for measuring acceleration and angular velocity. This makes it possible to determine the consistency of the odometry information received from the control unit and improve the position determination of the robot on the map. In particular, the IMU can be used to detect accelerations that deviate from the planned movement, such as those that occur when the wheels spin. In addition, the relative position of the robot with respect to the acceleration due to gravity can be obtained. It is used to interpret environmental information and determine the measurement direction of the navigation sensor.

For example, the navigation unit 140 maps one or more of the sense and aid strategy and / or the Simultaneous Localization and Mapping (SLAM) algorithm and / or the robot use area. Can be used and worked. The robot can create a map (s) of such robot use areas during use, or use an existing map at the start of use. The existing map may have been created by the robot itself during previous use, such as reconnaissance travel, or may have been provided by another robot or human. For example, the navigation and work plan of the navigation unit 140 is to create a destination, to plan a route between destinations, and to determine the activity of the work unit 160 in or at the route to the destination. including. Further, the navigation unit 140 may manage a calendar (scheduler) in which a predetermined activity is input. For example, the user can register that the cleaning robot starts cleaning at a fixed time every day.

As in the embodiment shown in FIG. 2, the system having the communication unit 130, the navigation unit 140, and the control unit 150 is between the communication unit 130 and the navigation unit 140, and the navigation unit 140 and the control unit 150. It may be configured to exchange information only with. In particular, it is useful when the communication unit 130 processes high-speed communication with a large amount of data. This also simplifies the flow of data.

As will be described in more detail later, the navigation unit 140 including the navigation sensor 125 is functionally independent of the control unit 150 that processes the sensor information provided by the control sensor 120. The data / information exchanged between the navigation unit 140 and the control unit 150 is transmitted in a defined format independent of the sensor hardware used. If a different navigation sensor 125 is used in the successor model of the robot 100, only the software of the navigation unit 140 (and possibly some hardware components) needs to be adapted to the new navigation sensor, but this change It does not affect the control unit 150. Similarly, if different or additional control sensors 120 or different drive units 170 or different working units 160 are used in the successor model of the robot 100, the software of the control unit 150 (especially the driver and possibly some hardware). Only the wear component) needs to be adapted. Therefore, the navigation unit 140 and the navigation sensor 125 used are functionally completely separated from the control unit 150 and the hardware connected to the control unit (control sensor 120, work unit 160, drive unit 170). Both the control unit 150 and the navigation unit 140 may be implemented, at least in part, by software, as described above, which may run independently of each other on different processors (computational units) or processor cores. obtain. In addition, separate memory devices or separate (eg, protected) memory areas may be allocated to different processors or processor cores, allowing the software in control unit 150 and the software in navigation unit 140 to run independently of each other.

Due to the separate processing of sensor information and other events (eg, user input) by the control unit 150 and the navigation unit 140, time allocation is not easy. Timestamps can be assigned to each measurement and each event detected to simplify data processing, navigation, route planning, and work planning. This should be interpreted at least unambiguously by the navigation unit 140. For this, both the control unit 150 and the navigation unit need to use clocks synchronized via the clock generator 145. The clock generator may be, for example, a system clock that outputs time signals received by both the navigation unit 140 and the control unit 150 at regular intervals. Alternatively, a clock generator in the arithmetic unit of the navigation unit 140 or the control unit 150 may be used.

For example, the clock generator of the navigation unit 140 may be used. Based on this clock, the navigation unit 140 determines the time stamp to be given internally. A clock signal is transmitted from the clock generator 145 to the control unit 150 at periodic intervals (for example, every second). This clock signal is used to synchronize the internal clock of the control unit 150 with the clock used in the navigation unit. In this way, the control unit 150 can assign a time stamp synchronized with the time stamp of the navigation unit 140 to the sensor information and other detected events. For example, the control unit 150 determines the mileage information (odometry information) based on the measured value from the odometer. These are time stamped and transmitted to the navigation unit 140. The navigation unit 140 receives similarly time-stamped sensor information from navigation sensors (particularly navigation features). Based on the time stamp, the navigation unit 140 can now determine if it has already received the required mileage information and, if necessary, wait to receive new mileage information. Based on the time stamps, the measurements are sorted in chronological order and treated together within the framework of the SLAM algorithm to update the map state and the position (posture) of the robot in the map.

Further, the autonomous mobile robot 100 may have a power source such as a battery (not shown in FIG. 2). The battery may be charged, for example, when the autonomous mobile robot 100 is docked to a base station (not shown). The base station may be connected to, for example, a power grid. The autonomous mobile robot 100 may be configured to voluntarily proceed toward the base station when the battery needs to be charged or when the robot 100 completes the task.

FIG. 3 shows a more detailed embodiment of the control unit 150. The control unit 150 may include, for example, a safety module 151, a motor controller 152, and a prediction module 153. The motor controller 152 is configured to generate specific signals for controlling the motors and actuators of the drive unit 70 and the work unit 160 from the movement information and the work information received from the navigation unit 140. Therefore, it is possible to construct a buffer that temporarily stores the control signal for a predetermined period. In this case, the movement information can include an immediate stop of the robot, at which time all control signals contained in the buffer can be removed and replaced with the active brake control signal. For control, current and voltage measurement information (status sensor 124) and encoder information (motion sensor 123) can also be used in the control loop.

When generating control signals, hardware-specific adaptations may be required, which results in certain deviations between the movements actually controlled and the movements originally planned by the navigation unit 140. In addition, restrictions on the drive members (motor, power driver, etc.) used in the drive unit 170 (minimum curve radius, maximum acceleration, restrictions on control accuracy, etc.) may also lead to such deviations. Therefore, the prediction module 153 can determine the future movement of the robot based on the buffer of the control signal. A computational model can be used in doing so, which may take into account the inertia of the robot, the characteristics of the drive electronics, and / or the specific configuration of the drive unit (wheel position and size, etc.). can. The result is, for example, a change of position or orientation at one or more predetermined time intervals. This prediction is transmitted to the navigation unit 140 and can be taken into consideration during navigation and work planning.

The safety module 151 is configured to monitor selected safety-related perspectives of the autonomous movement of the robot 100 independently of the navigation unit 140. The safety module 151 is further configured to intervene in the event that the navigation unit 140 does not respond or responds inappropriately in dangerous situations. Inappropriate reactions are reactions that cannot avoid a dangerous situation or cause another dangerous situation. Inappropriate situations are, for example, the possibility of the robot 100 tilting or tipping over, which makes it impossible for the robot 100 to move further without human intervention, or the robot, surrounding objects, floors, or. , A reaction that can cause damage to those standing around. In this regard, the safety module 151 may "filter", ie reject or correct, the robot movements planned by the navigation unit 140.

In order to achieve the above-mentioned functional independence of the control unit 150 from the navigation unit 140, the control unit 150 having the safety module 151 may have its own processor and memory module as described above. The memory module can store the danger detection software executed by the processor. However, it is also possible for the control unit 150 with the safety module 151 to share the processor and / or memory module with one or more other units of the robot 100. In one embodiment, one processor core of a multi-core processor may be assigned to a control unit 150 having a safety module 151, and the other processor core may be used by another unit of the robot 100 (eg, a navigation unit 140). Nevertheless, the software in safety module 151 may operate functionally independently of the software in the navigation unit 140 or other units . If the control unit 150 has its own processor and memory module (or exclusively uses the processor core of a multi-core processor), this reduces interference and the safety module 151 for the safety of the control unit 150 is highly reliable. It is easier and more reliable to be able to respond in a timely manner by sex. Unlike the navigation unit 140, which does not necessarily receive the information from the control sensor 120 in real time, the control unit 150 and thus the safety module 151 makes the sensor information from the control sensor 120 available in real time and is therefore dangerous. The situation can be detected and responded to quickly and reliably.

The hazard detection software for the safety module 151 may be configured as simply as possible to ensure traceable, and thus provable, reliable detection of dangerous situations and reactions in dangerous situations. According to one embodiment, the control unit 150 of the autonomous mobile robot 100 has a plurality of safety modules 151, and each of the safety modules 151 has danger detection software configured to correspond to a specific dangerous situation. However, it is also possible to specialize in a particular dangerous situation (eg, the imminent danger of falling off a staircase).

For example, one way to achieve the goal of simplifying the safety module 151 and the hazard detection software (and thus allowing a simple verification of the function of the safety module) is responsive and / or behavioral to the safety module 151. Applying various concepts of robotics. In such a concept, for example, how the robot 100 behaves is determined based solely on the current sensor data of the sensor module 120. In such a concept, for example, how the robot 100 behaves is determined based solely on current sensor data. However, unlike such a concept, if an exceptional situation, such as an immediate danger, is detected and the navigation module 140 does not respond appropriately, the safety module 151 intervenes in the planned action of the robot 100. It is configured as follows. For this purpose, the safety module 151 can receive movement and work information as well as predictions of future movements of the prediction module 153 from the navigation unit 140. If the motion information indicates safe operation, it is passed to the motor controller 152. In the case of unsafe operation, the operation information may be modified or destroyed by the safety module 151 before being passed to the motor controller 152. Additional or alternative, the safety module 151 can send a command for "emergency stop" to the motor controller 152. As a result, all the control signals stored in the buffer are discarded, and a new control signal for activating the brake (and possibly moving backward) of the robot 100 is generated. For this purpose, the safety module 151 is prohibited or potentially dangerous operating information based on the current information (received from the navigation unit 140) supplied by the control sensor 120 and is a safety module. It may be configured to recognize motion information that may lead to an accident without the intervention of 151. Alternatively, the safety module 151 may bypass the motor controller 152 and directly control the drive unit to brake the movement of the robot. Further, the safety module 151 may cut off the current to the drive unit or the motor in the drive unit.

For example, the safety module 151 may be coupled to one or more floor distance sensors as a safety sensor 122. If the floor distance sensor indicates that the distance to the floor is unusually high (eg, because the robot is trying to travel across the edge, or because the robot is lifted high), the safety module 151 will be in this situation. Can be judged to be a dangerous situation. If the sensor involved is in front of the robot (in the direction of travel), the safety module 151 classifies the current movement as potentially dangerous and stops or changes the current movement (eg, retreat). Can be done. In this case, the criteria used by the safety module 151 to detect a dangerous situation and the criteria used by the safety module 151 to evaluate the current movement (not dangerous or dangerous) are substantially the same. If the drop sensor in front of the direction of travel indicates an increase in distance, a dangerous situation is detected and the current movement is evaluated as dangerous. The safety module discards the forward movement planned by the navigation unit 140 and stops the current movement. When a particular dangerous situation is detected (for example, when an imminent fall from the edge is detected), the safety module can immediately stop the robot's current movement (substantially the current movement). Any continuation is considered inappropriate / dangerous).

The information output by the control sensor 120 may be evaluated in order to evaluate the movement information transmitted by the navigation unit 140. For example, the information in the control sensor 120 may be related to the internal state of the robot 100 (status sensor 124) and / or the environment (safety sensor 122). Thus, this information may include, for example, information related to the environment of the robot 100, such as falling edges, thresholds, the location of obstacles, or the movement of obstacles (eg, people). The information received about the environment of the robot 100 can be combined by the safety module 151 with the information about the current movement (motion sensor 123) or the planned movement (prediction module 153) of the robot 100. The information may be processed within the safety module 151 immediately after it is received and / or before it is processed and / or considered, first for a predetermined period or a predetermined distance (robot 100). It may be stored in the safety module 151 during the distance traveled by.

In addition, the received information may also relate to, for example, map data of the environment of the robot 100 created and used by the navigation unit 140. For example, map data may contain information about falling edges or other obstacles. In normal operation, the robot 100 "knows" its current position on the map.

Based on the information received, the safety module 151 may check if a dangerous situation exists. Dangerous situations are, for example, falling edges, disadvantaged locations of Robot 100 (eg, damp, smooth, steep or uneven surfaces), or obstacles to the environment in the immediate vicinity of Robot 100. There are, or there are obstacles (eg, people) towards them. If no dangerous situation is detected, nothing is done and the safety module 151 passes the movement information unchanged to the motor controller 152.

When the safety module 151 detects a dangerous situation, the safety module 151 can first notify the navigation unit 140 that the dangerous situation has been detected. For example, information about detected falling edges or imminent collisions may be transmitted to the navigation unit 140. However, it is not always necessary to notify the navigation unit 140 of the detected danger situation. The safety module 151 also functions as a "silent observer" and can inspect the danger situation without notifying the navigation unit 140. In this case, as described above, only the sensor information (for example, the odometry information with a time stamp) will be transmitted. In addition, the safety module 151 may inspect whether the navigation unit 140 is responding appropriately to the detected hazard situation. That is, in the safety module 151, the movement information of the navigation unit 140 directs the robot 100 to an obstacle (or a falling edge, etc.) (thus exacerbating the dangerous situation), or makes the robot 100 a dangerous situation. It can be inspected for steering, deceleration, or stopping to keep away from. For this purpose, the safety module 151 may first determine which movement, in principle, could lead to an accident on the robot 100, depending on the identified hazard situation. For example, movements that may lead to an accident may be classified as "dangerous movements" and movements that are unlikely to lead to an accident may be classified as "safe movements". A dangerous movement is, for example, a movement in which the robot 100 moves (or does not leave) directly toward (or stays at) a falling edge or obstacle. Also, movements in which the robot 100 hits an obstacle and thereby staggers, falls, falls, or may damage the obstacle by contact can be classified as dangerous.

After classifying the movement as safe or dangerous, the safety module 151 may inspect whether the current movement of the robot 100 is a dangerous or safe movement. The safety module 151 can, for example, inspect whether the robot 100 is still moving towards a dangerous situation, or is likely to pass through an obstacle, or turn around to leave the dangerous situation. For this purpose, the safety module 151 may be analyzed using, for example, the prediction, odometry information (motion sensor 123) of the prediction module 153 and / or the movement information transmitted from the navigation unit 140. When the safety module recognizes that the robot 100 is making dangerous movements, it secures the safety of the robot 100 and surrounding objects, and starts measures (safety measures) for avoiding or at least mitigating accidents. As a countermeasure, for example, the movement information of the navigation unit 140 may be discarded or changed. The control signal of the safety module 151 may also include, for example, a direction and / or speed command that changes its direction and / or its speed with respect to the robot 100. For example, accidents can be avoided by slowing down when a moving object crosses the robot's planned path. In many cases, for example, it may be sufficient for the robot 100 to change direction slightly or more without changing speed. Similarly, it is conceivable that the robot 100 will move in the completely opposite direction, i.e., for example, rotate 180 ° or run backwards. Normally, an accident can be reliably prevented by stopping the robot 100 (emergency stop).

As described above, when the safety module 151 discards or modifies the movement information from the navigation unit, the safety module 151 can (arbitrarily) notify the navigation unit 140 of the countermeasure. The navigation unit 140 may confirm receipt of this information. This confirmation may be made, for example, by the navigation unit 140 transmitting modified travel information adapted to the dangerous situation detected. However, the navigation unit 140 may send the acknowledgment directly to the safety module 151.

For example, if there is no response or valid response from the navigation unit 140 after a predetermined time (eg, 1 second), the safety module 151 can assume that the safe operation of the robot 100 is no longer guaranteed. In this case, the robot 100 may optionally be permanently stopped. For example, restart may be possible after the user has actively authorized or the robot 100 has been repaired by the user or technician (eg, cleaning the sensor).

According to an embodiment of the invention, the navigation unit 140 makes a request to the safety module 151 to nevertheless perform a movement classified as dangerous by the safety module 151 in order to allow further movement of the robot 100. Can be sent. This request may be made after the navigation unit 140 has been notified by the safety module 151 of countermeasures against dangerous movements. Alternatively or additionally, the request can be made as a precautionary measure, whereby the safety module 151 may be notified in advance of the planned movement. As a result, for example, interruptions in planned movements can be avoided. The safety module 151 may inspect this request and notify the navigation unit 140 whether the requested movement is permitted.

The robot's sensors (particularly the sensor module 122) are configured in many robots to measure only the forward movement of the robot 100, i.e., the normal direction of travel, i.e. the direction of the region in front of the robot 100. .. That is, it may provide no information about the area behind the robot 100 or only very limited information. For example, the reverse travel of the robot 100 may only be considered safe for very short distances of less than 5 cm or less than 10 cm, for example. Therefore, traveling in the opposite direction longer than this may be disallowed, for example, by the safety module 151. However, when the robot 100 arrives at or leaves a base station capable of recharging its power supply means, it may require, for example, a longer reverse travel. In principle, the safety module 150 can be assumed in this case to have the base station properly arranged by the user so that it can safely arrive at and leave the base station. If the robot 100 has to arrive at or leave the base station and thus requires longer reverse travel, the navigation unit 140 can send a request corresponding to the safety module 151. .. Next, the safety module 151 can inspect, for example, whether the robot 100 is actually at the base station. For example, for this purpose, it is possible to confirm whether or not a voltage is applied to the corresponding charging contact of the robot 100. In this case, the charging contacts form a kind of status sensor 124 that can detect whether the robot has docked to the charging station. Alternatively, for example, the contact switch can be configured to close when docked to a base station. Therefore, the safety module 151 can inspect whether the contact switch is closed. These are just examples. Whether or not the robot 100 is at the base station can be confirmed by yet another appropriate method. When the safety module 151 detects that the robot 100 is at the base station, it may allow it even if the reverse travel distance required to leave the base station exceeds the normal permissible distance. However, if the safety module 151 detects that the robot 100 is not at the base station, only normally permitted distances for traveling in the opposite direction may be permitted. This is just an example. There are various other situations in which the safety module 151 considers movements classified as dangerous to be exceptionally safe and allows them.

According to a further embodiment of the invention, the safety unit 150, in particular the safety module 151, is configured to perform a self-test. In this case, the self-test can have, for example, a read test and a write test of the memory module belonging to the safety module 150. If such a self-test fails, the robot 100 may be permanently stopped and powered off until the operation of the robot 100 is permitted by the user. After the self-test fails, the safe operation of the robot 100 is not guaranteed in principle. Self-testing can also be achieved, for example, by redundant configurations of various components. Thus, for example, the processor and / or memory module of the safety module 150 can be duplicated and the hazard detection software can be run on both processors. As long as the results of both processors are the same or have a small acceptable deviation, it can be assumed that the safety module 151 is functioning properly.

According to another embodiment of the invention, the safety module 151 may be configured to monitor the reliable operation of the control sensor 120. At this time, it may be sufficient to monitor only the sensors that provide safety-related information. Monitoring of this sensor can detect whether the sensor is supplying erroneous or unreliable data, for example due to defects or stains. In this case, the monitored sensors may be configured to individually detect the malfunctions and report them to the safety module 151. Alternatively or additionally, the sensor may be configured to supply meaningful measurement data only while the sensor is fully functional. For example, if the distance to the floor is zero (or infinite) rather than the general value of the distance to the floor, the floor distance sensor is detected to be non-functional. Alternatively or additionally, the safety module 151 may check the consistency of the data received from the sensor. For example, in the safety module 151, the sensor data (motion sensor 123, particularly the wheel encoder) used to determine the movement of the robot 100 is the measured power consumption of the drive unit (status sensor 124, ammeter, voltmeter). ) May be checked. If one or more faulty sensor signals are detected, the safe operation of the robot 100 cannot be guaranteed, so the robot can be permanently stopped and turned off until the user permits the operation again.

In principle, known dangerous situations can be detected by the methods described. The known dangerous situations can be adjusted to suit the purpose in the test situation to confirm the safety of the robot 100. For example, in such a test, the robot 100 can be deliberately brought into a potentially dangerous situation (eg, place the robot near the falling edge). Next, it is possible to simulate the case where the navigation unit 140 transmits erroneous and / or random movement information to the control unit 150. After that, it is possible to observe whether the safety module 151 can surely prevent the accident. To this end, the navigation unit 140 may allow a special test operation, in which a predefined movement pattern is generated and / or movement information is transmitted via the communication unit 130 (eg,). Can be given in advance (by remote control).

FIG. 4 schematically shows a plan view of the lower side of the autonomous mobile robot 100. FIG. 4 shows an example of a cleaning robot, the cleaning module of the robot is not shown for clarity. The illustrated robot 100 has two drive wheels 171 (differential drive) belonging to the drive module 170 and front wheels 172. The front wheel 172 may be, for example, a driven wheel, which itself has no driving force and only moves with the movement of the robot 100 on the floor surface. The front wheel 172 may be rotatable 360 ° about an axis substantially perpendicular to the floor (direction of rotation is indicated by the dashed arrow in FIG. 4). Each drive wheel 171 may be connected to an electric drive (eg, an electric motor). The rotation of the drive wheels 171 causes the robot 100 to move forward. The robot 100 further has a floor distance sensor 121 (as part of the safety sensor 122). In the example shown in FIG. 4, the robot 100 has three floor distance sensors 121R, 121M, and 121L. The first floor distance sensor 121R is arranged, for example, on the right side (viewed in the traveling direction) of the robot 100. At this time, the first floor distance sensor 121R does not need to arrange the robot 100 on the central axis x that equally divides the front part and the rear part. For example, the first floor distance sensor 121R may be located slightly anterior to the central axis x. For example, the second floor distance sensor 121L is arranged on the left side (viewed in the moving direction) of the robot 100. In this case, it is not necessary to arrange the second floor distance sensor 121L on the central axis x as well. Similarly, the second floor distance sensor 12IL may be located slightly anterior to the central axis x. For example, the third floor distance sensor 121M may be located in the center of the front of the robot 100. For example, at least one floor distance sensor 121 is arranged in front of each wheel so that the falling edge is detected before the wheel passes the falling edge when traveling forward.

The floor distance sensor 121 is configured to detect the distance of the robot 100 to the floor surface, or to detect whether or not the floor surface is present at least within a certain interval. Since the distance of the floor distance sensor 121, that is, the distance to the floor of the robot 100, changes only slightly during the normal operation of the robot 100, the floor distance sensor 121 usually supplies a relatively uniform value. Especially on smooth floors, the distance to the floor usually remains about the same over a wide area. For example, on carpets where the drive wheels 171 and front wheels 172 can sink, slight deviations in values can occur. As a result, the distance to the floor surface of the robot body provided with the floor surface distance sensor 121 can be reduced. Falling edges such as stairs can be detected, for example, when the value supplied by at least one of the floor distance sensors 121 increases sharply. For example, a falling edge can be detected when the value measured by at least one floor distance sensor 121 increases beyond a predetermined threshold. The floor distance sensor 121 may include, for example, a transmitter for optical or acoustic signals and a receiver configured to detect reflections of the transmitted signal. Possible measurement methods include measuring the intensity of the signal reflected from the floor, triangulation, or measuring the transmitted signal and the transit time of the reflection. For example, according to one embodiment of the invention, the floor distance sensor 121 does not determine the exact distance of the sensor to the floor, but a Boolean signal indicating whether the floor is detected within a predetermined distance. It only provides (eg, a floor surface detected at a distance of up to 5 cm to the floor surface distance sensor 121). The actual evaluation and interpretation of the sensor signal may be performed in the control unit 150.

Common movements performed by autonomous mobile robots (or movements planned by the navigation unit 140 and sent to the control unit 140 in the form of movement information) include forward movements, right or left rotations, and these. Includes a combination of movements. When the robot 100 makes such a movement, it moves toward the falling edge, and the movement is detected by at least one floor distance sensor 121. With simple geometric considerations, it is possible to determine movements that could lead to an accident (in this case a collision) of the robot 100. For example, when the first or second floor distance sensors 121R, 121L arranged on the side of the robot 100 are triggered, the robot 100 has the maximum drive wheel 171 (wheel support point) and the floor distance sensor 121R. You may move forward by the first distance L1 corresponding to the distance between 121L. For example, when the third floor distance sensor 121M on the front surface of the robot 100 is triggered, the robot 100 has a maximum of a second wheel corresponding to the front wheel 172 (wheel support point) and the third floor distance sensor 121M. You may move forward by the distance L2. Therefore, the robot 100 detects the falling edge while traveling at full speed, generates a control signal for deceleration, and is in front of the falling edge (that is, within the first or second distances L1 and L2). You must be able to stop. In particular, the reaction times of the required individual parts, ie the safety sensors 122 involved, the navigation unit 140, the safety and drive units 170 with the safety module 151, and the speed of the robot 100, the (negative) acceleration that slows down the robot 100. And the associated braking distance are taken into account. For example, the safety module 151 may be configured to only allow the robot 100 to retreat as long as at least one of the floor distance sensors 121 is triggered. When it is detected that the floor distance exceeds the maximum allowable value, the floor distance sensor is triggered.

In the example shown in FIG. 4, the second distance L2 is shorter than the first distance L1. In order to ensure that the robot 100 stops in a timely manner in front of the falling edge after the third floor distance sensor 121M is triggered, the safety module 151 may, for example, provide a third floor distance. As soon as the sensor 121M is triggered, all movement information from the navigation unit 140 may be discarded and a control signal for stopping the robot 100 may be output to the motor controller. For example, the safety module 151 may not first check the correct behavior of the navigation unit 140 because it may take too long. Only after the robot 100 is stopped can the safety module 151, for example, inspect whether the navigation unit 140 also transmits movement information suitable for the perceived situation. Mobility information suitable for such situations includes, for example, commands to stop, retract, or turn the robot away from the falling edge. Such movement information will be passed as is (without objection) to the motor controller by the safety module 151. However, if the safety module 151 detects that the navigation unit 140 has generated movement information for performing dangerous movements (eg, forward movements), it retains control of the robot by discarding this movement information. Or it can be taken over.

When the first or second floor distance sensors 121R, 121L are triggered, for example, a navigation unit for dangerous situations because more time is available until the robot 100 stops to avoid danger. Waiting for 140 reactions may be sufficient. For example, in such a case, the safety module 151 can wait for the robot 100 to travel a third distance L3 (eg, L3 = L1-L2). At this time, the robot 100 has only the time required for the second distance L2 available to avoid the accident. Therefore, during the time required for the third distance L3, the safety module 151 can free the navigation unit 140 without discarding its movement information or stopping the robot 100. If the navigation unit 140 responds appropriately during this time (in the case of movement information moving away from the detected falling edge of the robot 100), no intervention by the safety module 151 is required and the safety module 151 remains passive. (Pass the movement information unchanged). Whether or not the third distance L3 has already been traveled can be determined based on the maximum possible speed of the robot 100, for example, by means of elapsed time and / or mileage meter. For example, the safety module 151 travels in a direction in which the navigation unit 140 stops and / or moves away from the falling edge of the robot 100 within 10 ms after the detection of the falling edge by the first or second floor distance sensors 121R, 121L. If not allowed, the robot 100 may be stopped. The movement prediction of the prediction module 153 can be used in determining the distance L3 and determining when the distance is traveled.

For cost reasons, as shown in FIG. 4, the robot 100 often has only the floor distance sensor 121 in front of the robot 100, in which case the falling edge is when the robot 100 moves forward. Can only be detected. This is usually sufficient to ensure safe movement of the robot 100 with respect to the falling edge, as the robot 100 moves primarily in the forward direction. In some situations, obstacles and falling edges may block forward movement. In such a situation, in order to get out of this situation, the robot 100 may inevitably move backwards as a whole or by at least one of its drive wheels 171. However, if the robot 100 knows the path behind itself, the robot 100 can certainly travel backward. If the robot 100 does not know the route, for example, the falling edge behind the robot 100 cannot be recognized because there is no floor distance sensor at the rear of the robot 100, and there is a risk of an accident. The distance that the robot 100 last traveled can be approximated as, for example, a straight line. The reverse can be perceived as safe, for example, for a fourth distance D. Here, the distance D is the distance between the drive wheel 171 and the circumference S in which the floor surface distance sensor 121 is arranged in the front region of the robot 100. If the robot finally moves forward by a distance shorter than the fourth distance D, it may retreat by a distance not greater than the last distance moved forward. When forward and backward are combined, the actual distance traveled (eg, with the motion sensor 123) can be determined and the required backward movement can be considered.

For example, the safety module 151 does not have information about its environment and may not know if there is a falling edge behind it, so it should not allow backward movement immediately after the robot 100 is powered on. Can be configured. For example, the robot 100 may have been placed by the user on a table near the edge of the table, or on stairs or landings. At this time, for example, when the forward direction is blocked by an obstacle or a falling edge, the safety module 150 can also block the backward movement of the robot 100. For example, as described above, when the navigation unit 140 intends to drive the robot 100 away from the base station, the navigation unit 140 can transmit the corresponding request to the safety module 151. If the safety module 151 confirms that the robot 100 is actually at the base station following such a request, then the safety module 151 is the distance required to move away from the base station. Allow backward movement.

The movement of the robot 100 can be determined by various sensors such as, for example, a mileage meter (eg, a wheel encoder) and / or calculated based on the control signal of the prediction module 153. In this case, for example, the distance traveled by the robot 100 at predetermined time intervals and / or movement intervals may be stored. Further, for example, the position or path of the floor distance sensor 121 can be stored in order to better estimate the safe floor surface.

According to one embodiment of the present invention, if the robot 100 has previously moved forward by at least a distance greater than the radius of the circumference S, the circumference S on which the floor distance sensor 121 is located will be: It can be regarded as a safe driving area. In this case, the safety module 151 causes the robot 100 to move away from the circumference S due to backward movement (eg, control command and / or mileage) during reverse drive (and short forward movement combined with reverse drive). Upon detection (based on meter readings), the robot 100 may be configured to stop.

Obstacles can be detected by sharing several sensors to avoid collisions. For example, the safety sensor 122 includes an optical sensor configured to non-contactly detect an obstacle in the proximity region of the robot (eg, an infrared sensor with a measurement principle different from the floor distance sensor). The safety sensor 122 may include, for example, a tactile sensor configured to detect an obstacle (eg, a glass door) that is visually difficult to detect when in contact. For example, a tactile sensor may include a contact switch configured to close when touching an obstacle. For example, the tactile sensor may further include a spring displacement means that allows the robot 100 to decelerate before the body of the robot 100 collides with an obstacle. In such a case, the safety module 151 behaves in the same manner as when the floor distance sensor 121 is triggered when the falling edge is detected.

For example, the safety module 151 may be configured to monitor obstacles near the robot. For example, if an obstacle is detected within a predetermined distance from the robot 100, the safety module 151 may prevent the robot from moving at a speed exceeding the speed limit. The predetermined distance may depend on the direction in which the obstacle is detected. For example, normally, an obstacle detected behind the robot 100 does not limit the forward movement of the robot 100. The speed limit may depend on the distance to the obstacle and / or the direction in which the obstacle is detected.

The safety module 151 is predetermined regardless of the speed and direction in which the organism moves when the organism (human, pet) is detected by an appropriate safety sensor 122 (eg, temperature image) in the robot environment. It can also be configured to prevent speeds and / or accelerations greater than the limit of. For example, limiting the maximum speed increases the time available to the robot 100 to respond to unexpected movements of the object. At the same time, if the maximum speed is limited, the kinetic energy of the robot 100 is reduced due to the decrease in speed, so that the risk of injury to humans and animals and damage to the robot and objects is reduced. By limiting the acceleration of the robot 100, people in the environment can better judge the behavior of the robot 100 and respond better to the movement of the robot, thereby reducing the risk of accidents.

For example, the status sensor 124 of an autonomous mobile robot 100, such as a transport robot, is a sensor configured to detect whether the robot 100 is carrying an object and what object (eg, glass or dish) is being carried. Can include. Based on this information, the movement of the robot can be adapted and restricted. For example, the robot 100 can accelerate faster and move at a faster speed if it does not carry anything. For example, carrying a flat object such as a plate can accelerate faster than carrying a glass or bottle.

The safety module 151 may be further configured to monitor the function of the work unit 160. This can be particularly advantageous if the activity of the work unit 160 is related to the larger movement of the work unit 160 itself and / or the movement of the robot 100 by the drive unit 170.

For example, the working unit 160 may include a brush for collecting debris. Rotating brushes are at risk of being blocked by, for example, entwining the laces of scattered shoes, the edges of carpet, or the cables of appliances. The rotation of the brush can be measured, for example, by a rotation speed encoder. It can be detected that the brush is blocked by not detecting the rotation of the brush. It is also possible, for example, to identify the power consumption of the brush motor and thereby detect that the brush has been blocked.

Various methods are known for releasing blocked brushes. For example, the brush switches to idling, the robot 100 runs in the reverse direction, and at that time, the cable or the like is rewound again. However, this method is dangerous. Running the robot 100 with the brush blocked may basically lead to an accident. If the cable wrapped around the brush is, for example, an electrical device cable, there is basically a risk that the robot will pull the electrical device with the robot when it runs backwards. If such electrical equipment is placed in a high position, eg on a shelf, it can fall to the floor and be damaged. Thus, the safety module 151 may be configured, for example, to detect if the brush is still blocked when the procedure for releasing the brush is performed. In such a case, the movement of the robot 100 may be stopped because neither forward nor backward can be performed without damaging the object. Another possibility is for the robot 100 to rotate the brush in a direction opposite to the normal direction of movement in order to release the cable or the like from the brush without changing its position.

Next, a configuration example of the present invention will be described.

Configuration example 1:
An autonomous mobile robot
A drive unit (170) configured to receive a control signal and move the autonomous mobile robot according to the control signal, and a drive unit (170).
A navigation sensor (125) for detecting navigation features and
A navigation unit (140) coupled to the navigation sensor (125), receiving information from the navigation sensor (125), and configured to plan the movement of the autonomous mobile robot.
A control unit (150) configured to receive motion information representing a motion planned by the navigation unit (140) and generate the control signal based on the motion information.
With a further sensor (120) coupled to the control unit (150),
Have,
The control unit (150) receives further sensor information from the further sensor (120), preprocesses the further sensor information, and preprocesses the preprocessed sensor information in a predefined format. Provided to the unit (140)
The planning of the movement of the autonomous mobile robot by the navigation unit (140) is performed based on the information from the navigation sensor (125) and the preprocessed sensor information provided by the control unit (150).
Autonomous mobile robot.

Configuration example 2:
The autonomous mobile robot according to the configuration example 1.
The navigation unit (140) and the control unit (150) are functionally independent, and the predefined format for the preprocessed sensor information is with the implementation of the further sensor (120). Is independent
Autonomous mobile robot.

Configuration example 3:
The autonomous mobile robot according to the configuration example 1 or the configuration example 2.
Both the control unit (150) and the navigation unit (140) each have a synchronized clock generator.
The predefined format for the preprocessed sensor information has a time stamp associated with the preprocessed sensor information and / or the said provided by the navigation unit (140). The movement information has a time stamp associated with the planned movement.
Autonomous mobile robot.

Configuration example 4:
The autonomous mobile robot according to any one of the first to third configurations.
Both the control unit (150) and the navigation unit (140) are at least partially implemented by software running on different processors or processor cores.
Autonomous mobile robot.

Configuration example 5:
The autonomous mobile robot according to any one of the first to third configurations.
The navigation unit (140) has a first memory or a first calculation unit to which a memory area is allocated, and the control unit (150) has a second memory or a second memory area to which the memory area is allocated. Has a calculation unit,
The first computing unit is configured to run navigation software that uses a map of the environment of the autonomous mobile robot.
Autonomous mobile robot.

Configuration example 6:
The autonomous mobile robot according to the configuration example 5.
When the navigation software is executed on the first calculation unit, the navigation unit (140) creates a map of the environment of the autonomous mobile robot based on the information received from the navigation sensor (125). , Determines the position and orientation of the autonomous mobile robot on the map.
Autonomous mobile robot.

Configuration example 7:
The autonomous mobile robot according to any one of the first to sixth configurations.
The navigation unit (140) has an interface of a communication unit (130) that enables communication with an external device, particularly for providing map information and status information of the autonomous mobile robot.
Autonomous mobile robot.

Configuration example 8:
The autonomous mobile robot according to the configuration example 7.
The navigation unit (140) is an autonomous mobile robot configured to execute a movement plan of the autonomous mobile robot in response to a command received via the communication unit (130).

Configuration example 9:
The autonomous mobile robot according to any one of Configuration Example 1 to Configuration Example 8.
The additional sensor (120) includes a safety sensor (122) that detects information about the environment in close proximity to the autonomous mobile robot and / or.
The additional sensor (120) includes a motion sensor (123) that detects information about the current movement of the autonomous mobile robot and / or.
The additional sensor (120) includes a status sensor (124) that detects information about the state of the autonomous mobile robot.
Autonomous mobile robot.

Configuration example 10:
The autonomous mobile robot according to the configuration example 9.
The motion sensor (123) is a distance sensor, and the preprocessed sensor information includes information depending on a sensor signal provided by the distance sensor.
Autonomous mobile robot.

Configuration example 11:
The autonomous mobile robot according to any one of the first to tenth configurations.
The control unit (150) checks the motion information received from the navigation unit (140) to see if the planned motion causes or may cause a dangerous situation. Includes a safety module (151) configured to take into account the additional sensor information.
Autonomous mobile robot.

Configuration example 12:
A method for autonomous mobile robots
A step of planning the movement of the autonomous mobile robot in the navigation unit (140) of the autonomous mobile robot based on the information provided by the navigation sensor that detects the navigation feature.
A step of transmitting motion information representing a motion planned by the navigation unit (140) to the control unit (150) of the autonomous mobile robot, and
A step of generating a control signal of the drive unit (170) of the autonomous mobile robot based on the transmitted motion information in the control unit (150).
A step of receiving further sensor information from a further sensor (120), preprocessing the further sensor information by the control unit (150), and preparing the preprocessed sensor information in a predefined format. ,
A step of transmitting the preprocessed sensor information to the navigation unit (150) in the predefined format.
Have,
The planning of the movement of the autonomous mobile robot by the navigation unit (140) is performed based on the information from the navigation sensor (125) and the preprocessed sensor information provided by the control unit (150).
Method.

100 ... Autonomous mobile robot 120 ... Sensor 122 ... Safety sensor 123 ... Motion sensor 124 ... Status sensor 125 ... Navigation sensor 130 ... Communication unit 140 ... Navigation unit 145 ... Clock generator 150 ... Control unit 151 ... Safety module 170 ... Drive unit 300 ... External device

Claims (12)

An autonomous mobile robot
A drive unit (170) configured to receive a control signal and move the autonomous mobile robot according to the control signal, and a drive unit (170).
A navigation sensor (125) for detecting navigation features and
A navigation unit (140) coupled to the navigation sensor (125), receiving information from the navigation sensor (125), and configured to plan the movement of the autonomous mobile robot.
A control unit (150) configured to receive motion information representing a motion planned by the navigation unit (140) and generate the control signal based on the motion information.
With a further sensor (120) coupled to the control unit (150),
Have,
The control unit (150) receives further sensor information from the further sensor (120), preprocesses the further sensor information, and preprocesses the preprocessed sensor information in a predefined format. Provided to the unit (140)
The planning of the movement of the autonomous mobile robot by the navigation unit (140) is performed autonomously based on the information from the navigation sensor (125) and the preprocessed sensor information provided by the control unit (150). Mobile robot. The autonomous mobile robot according to claim 1.
The navigation unit (140) and the control unit (150) are functionally independent, and the predefined format for the preprocessed sensor information is with the implementation of the further sensor (120). Is an independent autonomous mobile robot. The autonomous mobile robot according to claim 1 or 2.
Both the control unit (150) and the navigation unit (140) each have a synchronized clock generator.
The predefined format for the preprocessed sensor information has a time stamp associated with the preprocessed sensor information and / or the said provided by the navigation unit (140). Motion information is an autonomous mobile robot with a time stamp associated with a planned motion. The autonomous mobile robot according to any one of claims 1 to 3.
Both the control unit (150) and the navigation unit (140) are autonomous mobile robots that are at least partially implemented by software running on different processors or processor cores. The autonomous mobile robot according to any one of claims 1 to 3.
The navigation unit (140) has a first memory or a first calculation unit to which a memory area is allocated, and the control unit (150) has a second memory or a second memory area to which the memory area is allocated. Has a calculation unit,
The first calculation unit is an autonomous mobile robot configured to execute navigation software that uses a map of the environment of the autonomous mobile robot. The autonomous mobile robot according to claim 5.
When the navigation software is executed on the first calculation unit, the navigation unit (140) creates a map of the environment of the autonomous mobile robot based on the information received from the navigation sensor (125). , An autonomous mobile robot that determines the position and orientation of the autonomous mobile robot on the map. The autonomous mobile robot according to any one of claims 1 to 6.
The navigation unit (140) is an autonomous mobile robot having an interface of a communication unit (130) that enables communication with an external device, particularly for providing map information and status information of the autonomous mobile robot. The autonomous mobile robot according to claim 7.
The navigation unit (140) is an autonomous mobile robot configured to execute a movement plan of the autonomous mobile robot in response to a command received via the communication unit (130). The autonomous mobile robot according to any one of claims 1 to 8.
The additional sensor (120) includes a safety sensor (122) that detects information about the environment in close proximity to the autonomous mobile robot and / or.
The additional sensor (120) includes a motion sensor (123) that detects information about the current movement of the autonomous mobile robot and / or.
The further sensor (120) is an autonomous mobile robot including a status sensor (124) that detects information about the state of the autonomous mobile robot. The autonomous mobile robot according to claim 9 .
An autonomous mobile robot in which the motion sensor (123) is a distance sensor, and the preprocessed sensor information includes information depending on a sensor signal provided by the distance sensor. The autonomous mobile robot according to any one of claims 1 to 10.
The control unit (150) checks the motion information received from the navigation unit (140) to see if the planned motion causes or may cause a dangerous situation. An autonomous mobile robot comprising a safety module (151) configured to take into account the further sensor information. A method for autonomous mobile robots
A step of planning the movement of the autonomous mobile robot in the navigation unit (140) of the autonomous mobile robot based on the information provided by the navigation sensor that detects the navigation feature.
A step of transmitting motion information representing a motion planned by the navigation unit (140) to the control unit (150) of the autonomous mobile robot, and
A step of generating a control signal of the drive unit (170) of the autonomous mobile robot based on the transmitted motion information in the control unit (150).
A step of receiving further sensor information from a further sensor (120), preprocessing the further sensor information by the control unit (150), and preparing the preprocessed sensor information in a predefined format. ,
A step of transmitting the preprocessed sensor information to the navigation unit (150) in the predefined format.
Have,
The planning of the movement of the autonomous mobile robot by the navigation unit (140) is performed based on the information from the navigation sensor (125) and the preprocessed sensor information provided by the control unit (150). ..