KR20080113685A - Modularized mobile robot systemn - Google Patents

Abstract

A mobile robot system is provided to modularize the functions of a personal robot and establish organic connection environment and expandability between the modules through standardized H/W and S/W interface. A mobile robot system comprises a vision module which processes image data from a camera in order to extract the feature of an object, a sensor module which processes the signal from a sensor mounted on a robot, a mobile module which provides the robot with portability, and an interface module which performs determination based on the results from the vision module, the sensor module, and the mobile module and operates itself.

Description

Modularized Mobile Robot SystemN

1 is a block diagram showing the structure of a middleware for a conventional module-based personal robot,

2 is combined as parts of a robot under the control of a high level of intelligence with integrated modules, the capability of which is characterized by an adaptive configuration,

3 is a diagram illustrating a structure of a VM-D;

4 shows that it is compiled by the RPL-compiler,

5 is a diagram illustrating a configuration of a module interface and a port;

6 is a diagram showing the structure of software of a module;

7 is a software layout according to the API,

8 shows a standard hardware interface of a module according to the invention,

9 is a view showing an assembly process of a module according to the present invention;

10 is a view showing a connector structure of a unit according to the present invention;

11 is a view showing a connection structure of a module via IEEE1394;

12 is a diagram illustrating an IEEE1394 thread,

FIG. 13 shows a DRP I composed of a vision module-D, a sensor module-D, an arbiter module-D, and a mobile module-D; FIG.

14 shows a common component of a module according to the invention,

15 is a view showing the assembled state of the module according to the present invention;

16 is a view showing a mobile module according to the present invention;

17 is a view showing a sensor module according to the present invention;

18 is a block diagram of the sensor module shown in FIG. 17;

19 is a view showing a vision module according to the present invention,

20 illustrates an arbiter module according to the present invention;

21 is a view showing the configuration of the arbiter module shown in FIG.

22 is a diagram illustrating integration of a module according to standardization;

23 shows various modules integrated into various assemblies by different connections;

24 is a diagram illustrating valid movement between modules;

25, 26 and 27 illustrate a reconfigurable configuration of DRP I.

The present invention relates to a modular and movable robotic system, and more particularly to a modular mobile robotic system that can extend the functionality of a robot having a structure and value as an independent system or be applied to other robots.

In general, a robot (Robot) is a machine that operates like human hands and feet, the manufacturing robots in the early days made a large number. Recently, however, personal robots have become more closely related to human life by the development of various technologies and the demands of users. Personal Robot is a personal support robot that has intelligence to give convenience to human life. To provide a convenient service, a personal robot must interact with humans, and for this purpose, it must be equipped with functions such as free movement, situation awareness, and communication. Personal robots are being developed in various forms, such as cleaning, pets, education, or handicapped guide.

In recent years, people's daily life experiences have changed greatly due to technological advances, which have improved the quality of life at home. For example, in the fields of housekeeping, security, education and cleaning, people are already familiar with the environment, including digital home appliances, home networks, mobile devices and the like. Home automation is an unnecessary idea, as previously implied, but the techniques mentioned above are being redefined to be state-of-the-art. Home automation has become a very promising field, and commercialization has already taken place in many related fields. Most people believe that in the future, robots will be used primarily for personal use, not for industrial use. They argue that robots with mobility and maneuverability are necessary in a fixedly configured home environment. Personal robots are being studied and attracted worldwide, but many problems must be solved before they can become truly promising businesses. For example, personal robots are developed in many places, so there are not many aspects shared among them. Each robot is manufactured according to individual designs from scratch.

As such, an example of a personal robot technology is disclosed in Korean Patent Laid-Open Publication No. 2000-0067377 (Personal Robot and Control Method thereof).

The technique disclosed in the above publication adds a robot configuration to a personal computer so that the personal robot can perform a movement or the like, or a user can directly control the movement using a wireless controller and an internet network at a local or remote location. Disclosed are a structure of a personal robot including a movable device and a device capable of recognizing an external environment, a method of controlling the movement of the personal robot through a wireless controller, and a remote control method through the Internet. That is, the publication includes a conventional personal computer unit, a battery unit which supplies power to itself to secure freedom of movement of the personal robot, a communication unit for connecting wireless communication between short distances and remote locations, and a sensor unit capable of recognizing the external environment. A personal robot and a control method thereof are disclosed that include a structure of a personal robot including a driving unit capable of moving by itself or by a user's movement control command.

In addition, the personal robot must be guaranteed mobility to perform various functions. For this purpose, several types of networks are used between the inside and outside of the robot. These different network interfaces have different characteristics such as transmission speed and bandwidth. Accordingly, there is a need for protocol conversion and packet transfer means between various networks. To this end, a technology for developing an internal structure of a personal robot into a module-based structure and providing an interface for supporting compatibility and wide usability between modules is known. If a specific application is developed for each type of network interface, it causes a waste of development cost and time. Therefore, an effective middleware (MW) structure for supporting one or more open interfaces is used. This structure is called middleware for module-based personal robots (MMPRs).

Next, the MMPR will be described with reference to FIG. 1.

1 is a block diagram illustrating a structure of middleware for a conventional module-based personal robot.

As shown in FIG. 1A, the MMPR 10 includes a streaming layer (SL) 100 that provides a service of the middleware 10 to an application layer, and a network adaptation layer that accommodates multiple networks of different types. Layer, NAL (200), and a network interface layer (Network Interface Layer (NIL) 300) that is responsible for network-dependent functions are composed of three layers.

First, the streaming layer (SL) 100 is composed of elements related to an application using a service of the middleware 10. The main function is to provide a mechanism for the application to access the application existing in the remote module regardless of the type of network using the network adaptation layer (NAL) (200). That is, the streaming layer (SL) 100 provides a service such as reading a variable, a remote module, or calling a remote function that exists in the remote module, and executes application management and transaction management in parallel.

Next, the network adaptation layer (NAL) 200 is a layer that integrates various kinds of network components 310 to 350 added to the network interface layer (NIL) 300, and is substantially middleware. 10 is the layer responsible for the core functions. This layer performs functions such as message routing, heterogeneous network module addressing, naming service, and the like, and performs various network components 310 ~ of the network interface layer (NIL) 300. 350).

Finally, the network interface layer (NIL) 300 is a layer for accommodating network devices, and there are various kinds of network components 310 to 350. That is, the layer supports the types of modules that can be managed by the network adaptation layer (NAL) 200. In addition, it is composed of components 310 to 350 that perform hardware or software dependent parts depending on the network type. The network interface layer (NIL) 300 is to prevent the middleware 10 from being modified whenever a new network is added or deleted in the middleware 10.

In addition, the network connection management unit (NCM) 240 shown in FIG. 1B includes error detection means 241 for detecting a connection error occurring in a network device, and components 310 to 350 of the network interface layer (NIL) 300. Response time 242 responding to the message received from the connection module included in the), the time limit until receiving the connection confirmation response message (Ack_Msg) after sending the connection confirmation request message (Req_Msg) to the connection module (Count) connection check timing means (Module_Katimer) (243), the broadcast time to send a broadcast request message (BroadReq_Msg) to the connection modules after receiving a broadcast response message (BroadAck_Msg) to count the time limit Cast timing means (Module_Katimer) 244 is provided.

However, in the conventional module-based personal robot, including the techniques disclosed in the above publication, even if the robot has a structure and a value as an independent system, there is a problem that it is difficult to be extended or applied to other robots. In addition, robots cannot meet the various requirements of users, and thus cannot be perfect in cost and manufacturing speed. To cope with this, there was a problem that cost efficiency, maintainability, safety and performance had to be improved as much as current consumer products.

In addition, there are obvious differences between robots and personal computers such as various requirements, mobility, manipulation, etc., and there is a problem that technical means such as standardization and modularization are not provided.

In general, Sony's AIBO is referred to as a flexible and adaptable platform based on modularity. AIBO uses OPEN-R as a system architecture and module components as mechanical hardware. However, as can be seen in the case of AIBO, there was a problem that adaptation between different systems, which may be characteristic of the robot industry, is not easy.

An object of the present invention is to solve the problems as described above, to provide a modular mobile robot system that can be easily connected and disconnected to the system for replacement, expansion and maintenance of each module of the modular robot. will be.

Another object of the present invention is to provide a modular mobile robot system, which is based on distributed processing with adaptability of modules in consideration of the characteristics of each network device, and is shared and connected by IEEE1394 to ensure a high speed response network and real time control. It is.

It is yet another object of the present invention to modularize the functions of a personal robot, provide an organic coupling environment and scalability between these modules via standardized H / W and S / W interfaces, and perform tasks on a real-time basis. In the process, it provides a modular mobile robot system that can be flexibly adapted to a new combination of systems and dynamically reconfigured.

In order to achieve the above object, the modular mobile robot system according to the present invention is a vision module for processing image data from a camera for transmitting a video image or extracting a feature of an object from the image, a signal from a sensor mounted on the robot. A sensor module for processing, a mobile module for providing mobility of the robot, and an arbiter module for making a decision based on the results from the vision module, the sensor module, and the mobile modules.

In the modular mobile robot system according to the present invention, each of the vision module, the sensor module, the arbiter module and the mobile module includes a module control unit and a test unit.

In the modular mobile robot system according to the present invention, the module control unit and the test unit are characterized by having an open or slide door-type case.

In the modular mobile robot system according to the present invention, the arbiter module is characterized by consisting of a battery unit and a power control unit.

In the modular mobile robot system according to the present invention, the arbiter module is characterized by monitoring the current, voltage, temperature, battery discharge, the driving time of the robot supplied to each module of the robot.

The above and other objects and novel features of the present invention will become more apparent from the description of the specification and the accompanying drawings.

First, the concept of the present invention will be described.

As a premise for achieving the above object, modularity and standardization based on compatibility are fundamental. In the present invention, a modular robotic structure or structure including software and hardware is introduced. Each hardware module of the robot, called Module-D (the module of DRP I), can be easily attached and detached from the entire system. Each software of the module can be functionally distributed and reconfigured. Specifically, they provide a method for connection between a parent task and a child task. Based on this environment, software development is categorized into levels so that low-level task developers can provide lower-level device drivers to low-level task developers. This is because a virtual machine called Virtual Machine of DRPI (VM-D) supports independence, compatibility, and portability. The proposed idea is implemented on a modular robot called DRP I (Dynamically Reconfigurable Personal robot), which consists of four general modules such as vision module, sensor, mediator module and mobile module. High speed IEEE1394 is used as a communication method between them.

The following description describes modules, virtual machines, and their programming languages, how to interface or connect the hardware and software of each Module-D, features and configurations of Module-Ds, and dynamically reconfigurable features.

The network interface used in the present invention is IEEE1394 (Institute of Electrical and Electronics Engineers 1394, 1394), USB (Universal Serial Bus, Universal Serial Bus), CAN (Controller Area Network, Control Instrument Communication Network) ), Ethernet, RS-232C (Recommended Standard-232C, data communication standard 202C) and the like can be used.

Important elements of the proposed structure in the present invention, namely module-D, VM-D, and RPL, are presented. Module-Ds are functionally characterized. Module-Ds are based on distributed processing with adaptability. Module-Ds are shared and connected by a high speed response network, such as IEEE1394, which ensures real time control. In addition, Module-Ds are easily connected and disconnected from the system for replacement, expansion and maintenance when there is a problem. VM-D and RPL support the compatibility of each module-D.

The definition of module-D according to the invention is as follows.

Modules are defined as units of independent software and hardware that perform particular functions. The concept of module-D presented in the present invention has a dynamic configuration. In other words, Module-D supports adaptive and flexible configurations, such as real-time based reconfiguration, so that Module-D can support an easy combination of Module-D if it has a distributed process and its own functionality. The proposed module-D can be installed, relocated and used independently according to standard interfaces. Each Module-D may consist of components (often referred to as devices or units) with similar characteristics, or may be grouped according to specific requirements. A module-D, independent of other module-Ds, is not only a 'part' of the whole system, but also a 'sub-system' or 'assembly' incorporating various components. In order to execute certain tasks or scenarios, as shown in FIG. 2, Module-Ds are combined as parts of a robot under the control of integrated high-level intelligence, which capability illustrates the features of the adaptive configuration. On the other hand, each module can act directly as an independent module in an emergency, because each module is an assembly that combines its internal components under the control of its own low-level intelligence. For example, when the robot is commanded to “go to the living room and turn on the TV,” the robot interprets the assigned task and performs the task using the combined Module-Ds, whereas the current task is “room cleaning” If the robot detects a baby on the path of movement, the mobile module-D avoids the baby and ignores the state or task of the other module-Ds.

In order to convey low level data or commands, high speed communication, such as IEEE1394, is used as a communication tool between module-Ds. To enable these controls, Module-D has a controller for interfacing internal components. Module-Ds interact with each other via virtual ports, and ports are communication channels of point-to-point connections. The actual port mapped for physical communication is IEEE1394, which guarantees real-time communication, but the port can be applied to USB, RS-232C, and TCP / IP as well. Because of IEEE1394, Module-Ds are easily connected or disconnected from the system for replacement, expansion, and maintenance when there is a problem.

Applications can be assembled with various sources from module-Ds. In other words, Module-Ds themselves can be written in several different programming languages and run on several different platforms. Nevertheless, Module-Ds can be reconfigured, rearranged or reprogrammed as long as they continue to supply the same interface and the same quality level. This feature provides considerable flexibility for the entire system. Thus, Module-D supports an integrated environment and platform, allowing companies to develop their own low-level components. This can be realized and achieved since Module-Ds are mediated by VM-D. VM-D applies to Module-D with operating systems such as Windows and Linux. VM-D is also based on components or sub-modules with controllers belonging to Module-D.

Virtual machines are also a common technique for bringing portability to embedded systems with compilers or interpreters. In 1995, Sun Microsystems released Java technology, the Java language, and the Java virtual machine. By doing so, software in the Java environment runs on different kinds of operating systems and hardware with Java virtual machines installed. The technology has greatly influenced the paradigm of product development. The Java virtual machine provides a high level of intelligent portability to the system at installation, but has a disadvantage in development time and execution performance when used to develop distributed robot modules on a network. Java cannot have low-level instructions for hardware control, nor can it execute bytecode on the interpreter at high speed, making it unsuitable for time-critical control systems such as robots that need to be controlled in real time. Therefore, the present invention proposes a new virtual machine called VM-D. As shown in Table I, this virtual machine has the same advantages as the Java virtual machine, such as system-independence and portability, its execution speed has been improved rapidly, and provides functions and algorithms that are frequently used as inherent features. do. Table 1 shows a comparison between VM-D and Java.

RPL / WM_D  Java Language / Java VM Language configuration Similar to C language Structured programming Subset of the C ++ language object-oriented programming Communication RPC (Remote procedure call) Module interface programTCP / IP, USB, IEEE1394 protocol Remote Method Invocation (RMI) Program Interface ClassTCP / IP Protocol Interpreter (Virtual Machine) Simple structure and easy implementation Porting to Windows, Linux O / S and embedded system Essential libraries related to the target system (IAPI) Free source code based on the Java VMMany resources on the target board for porting the Java VMLarge library for support

VM-D can be ported to different kinds of hardware platforms and operating systems such as Microsoft's Windows, Linux and RTLinux. VM-D is used to drive the byte code of the control program on module-D.

VM-D is stack oriented. VM-D takes one or more operands into the operand stack of the current frame and pushes the results back to the operand stack. Each time a method is called, a new frame is created, with a new operand stack and set of delay variables for use in the method. VM-D consists of registers, memory, and executor, and defines various runtime memory areas used during execution of the application program: byte code area, global variable area, function pointer area, stack area, and heap area. do. The structure of the VM-D is shown in Figure 3, the components of which are as follows:

·register

VM-D has three 32-bit registers (SP, BP, and PC). These registers are used to access the stack, or contain the address of the VM-D instruction currently being executed. The Stack Pointer (SP) contains the address of the top element of the stack in memory. Base Pointer (BP) contains the address of the base point of the stack in memory. The program counter (PC) contains the address of the next byte code to be executed.

Stack

Each job in VM-D has a private stack created at the same time as the job. The stack is similar to that of a conventional language such as C. That is, the stack has delay variables and partial results, passes parameters to the methods and receives the method results. Every instruction in VM-D takes an operand from the operand stack, computes the operand, and sends the results back to the stack.

Heap

The heap is a runtime data area, from which all memory for strings and arrays is allocated. The heap is created at the start of VM-D.

Byte code area

The byte code area is similar to the storage area for code compiled in a conventional language or text segment. This area stores bytecodes and symbol tables.

Global variable table

The global variable table is shared by all tasks in VM-D.

Function pointer table

The function pointer table contains the address of the function body.

Instruction set

An instruction called a byte code consists of a one byte OP code and operands. The former specifies the operation to be performed. The latter supply the parameters or data used by the operation. Instructions do not have operands and have one or two OP codes. The bytecode instruction stream is only byte-aligned. These judgments keep the VM-D code compact for compiled programs.

In addition, the present invention proposes a Robot Programming Language (RPL) to create an application program of a modular robot. In other words, VM-D is developed to control and mediate each heterogeneous OS or Mini-OS, but RPL supports developers of robotic application programs based on the integration of various OSs and VM-D. RPL is a programming language such as C ++, FORTRAN and Pascal. A program written in RPL is compiled by the RPL-compiler and converted into byte code as shown in FIG.

Bytecodes are downloaded to the module-D via the port, interpreted, and executed on the module-D's VM-D. Variables in RPL have data types. The data type of a variable determines what values it can contain and the operations that can be performed on it. Primitive data types that are integers, floating point numbers, and strings are all supported by RPL.

During compilation, the characters of the RPL source code are represented by consecutive tokens. The RPL compiler recognizes five types of tokens: identifiers, keywords, characters, operators, and various miscellaneous separators. White space (tabs, carriage return and line feed) and comments can serve as separate tokens. As shown in Figure 4, the linear processor and compiler go through four steps and the source code is compiled into byte code, i.e. linear processing, preliminary analysis, and grammar analysis and linking.

In addition, in the present invention, since each module-D plays a specific role and is independent of other module-Ds, a standard interface for effective integration of the module-Ds is required. The interfacing technique will be described below.

A. Software Module Interface

Although each module-D can be operated with different OSs, the internal state and objects of one module-D can be accessed by other module-Ds because of their own properties and methods. This is because module-D has a common software interface controlled by VM-D as shown in FIG. Properties that are specific values defined in Module-D determine the properties of Module-D and are used to assign a constant value to Module-D or to have a constant value assigned from Module-D. The method refers to a procedure for adjusting some operations of each module-D. For example, when the robot receives a movement command, the verb 'move' is one of the methods belonging to the mobile module-D. By the above properties and methods, the internal state and object of one module-D can be accessed by other module-Ds. In order to control module-D, VM-D calls functions of module-D such as mobile.goto (x, y), or functions of components that make up module-D such as mobile.readEncorder (motor1). Call This function is called an application programming interface (API). In other words, an API means a set of low-level functions called EAPI (Extended API) or a low-level function itself called IAPI (Internal API). As shown in Figure 6, the API and VM-D layers separate or isolate application software from hardware dependencies. VM-D is the base of module-D and is ported to various hardware. An API is a set of existing software functions that provide many useful functions. Module-D programs such as navigation and image processing run on that VM-D. In addition, one module-D may execute APIs of other module-Ds. The entire software consists of a combination of various APIs as shown in FIG. 7, and the various APIs of the third party can be easily inserted into the robot software since the robot's software is modularized to a standard.

B. Hardware Module Interface

To integrate the modules efficiently, hardware standard interfaces for mechanical and electrical connections must be prepared, and the power supply must be simplified for easy processing. As shown in Fig. 8A, a mechanically standardized connector is provided for the connection between the module-Ds, which connects the module-D to the IEEE1394 network to supply power to the module-D. As shown in Fig. 8B, the male connector of the standard interface is disposed at the bottom of each module-D and the female connector is disposed at the top of each module-D. Electrical and mechanical connectors are described with reference to FIG. 8 (c). Mechanical connectors prevent module-Ds from moving horizontally and vertically (forward stable connection). When module-D is assembled, the electrical connectors are connected after the mechanical connectors are joined. Although easy to attach and detach, the proposed hardware interface ensures the stability and safety of the entire system. 9 illustrates a connection procedure between the vision module-D and the sensor module-D.

Using a hardware module interface, the components or units inside each module-D are assembled by a mechanical standard interface called a unit connector, as shown in FIG. This connector supports port configuration access.

C. Communication Interfacing Between Modules-D

In designing a modular robot, the communication method between modules is one of the most important problems. In order to ensure that each Module-D can exchange messages and data bursts smoothly, does the communication method provide sufficient bandwidth, i.e., asynchronous transmission for transmitting vision streaming and audio data, and hot-plugging? You should check if it provides. After evaluating existing methods, the inventors concluded that IEEE 1394 (FireWire) is the most appropriate way to meet the above requirements. IEEE 1394 supports sufficient bandwidth of 400 Mbps (maximum) for transmitting large amounts of vision streaming data. As is well known, IEEE 1394 is currently one of the most used connections in home A / V and PC systems. Peer-to-peer (P2P) of the IEEE 1394 topology allows each module-D of the system to maintain its characteristics and to separate the module-D from the system without disrupting system operation. Thus, the module-D can be modularized by itself and the integrated system is stable. IEEE1394 interfacing routines are programmed into the Linux 1394 library ([24]). This routine provides the user interface with direct access to the IEEE1394 connected as the only interface currently supported. By using this library, a program that encapsulates a connection to the 1394 bus shown in FIG. 12, also referred to as a 1394 thread, is recorded. This consists of a FIFO for other processes intended to access the IEEE 1394 bus. As shown in FIG. 11, FIFOs allow modules to communicate for a process. The bus connection is maintained by mechanically standardized hardware connectors, allowing simple removal and addition of new modules while the system is turned on. In DRP I, the system remains in operation even if the sensor module is removed, or the vision module can replace the sensor module.

EMBODIMENT OF THE INVENTION Hereinafter, the structure of this invention is demonstrated according to drawing.

The DRP I shown in FIG. 13 consists of four internally assembled modules-D, vision module-D, sensor module-D, arbiter module-D and mobile module-D.

The common units of these module-Ds and combinations thereof will be described.

The four module-Ds are independently configured with a dedicated SBC, but are common in most aspects, such as hardware and software interfaces. Using a single connection, the Module-Ds can connect the system with a power supply of 12 and 5 volts and communicate with IEEE1394. The components are carefully designed for effective processing and safety of the entire system based on the concept of modularity.

The configurations are as follows.

As shown in Fig. 14A, the module control unit is composed of three switches such as a power switch, a reset switch, and an OS disconnect switch and a monitoring LCD. Power switches connected to solid state relay (SSR) switches open or break the electrical circuitry of the SBC within the module, and each SSR controls 12V, 5V, and ground. Module control circuits using SSRs are designed by remotely controlling power and communication. The reset switch is used to reboot the SBC when the module-D system is stopped. The OS shutdown switch is for the physical termination of the OS operation, not the physical termination of the power supply. This prevents damage to the OS when any module-D needs to be blocked. For LCDs and LEDs, these indicate the status of the SBC. When the system is stopped and the robot cannot be controlled by the user interface module, the operator checks whether the hardware SBC, software Linux, etc. in the specific module-D function normally.

As shown in Fig. 14B, the test unit is used for independent testing of each module-D, and has a module power terminal with an overcurrent protector. Also on the panel are connectors for VGA, LAN, mouse and keyboard.

In order to assemble these units efficiently, open or slide door-type casings are used as shown in Fig. 15, so that the units can be wired, modified, reassembled and tested without having to completely disassemble the entire system.

In addition, the mobile module-D according to the present invention provides the mobility of the robot. As shown in Figure 16, a differential drive mechanism is used. This mechanism has two wheels mounted on a common shaft controlled by separate motors and uses two casters for balance. Because mobile module-D is simple and inexpensive, it is generally used in many robots for indoor navigation.

New suspension mechanisms, also called multi-layer suspensions, are designed to protect against physical disturbances and to maintain a stable system as the robot moves. All signal processing related to movement is performed internally in this module-D, and only state is transmitted to the arbiter module-D.

Mobile Module-D consists of the following components:

a) Mobile Module-D controller with SBC serves as trajectory generation and navigation.

b) The drive mechanism consists of a DC gear motor with an encoder 75W, a motion controller and a urethane wheel.

c) Two casters with multi-tiered suspension are fixed to the bottom of the mobile module.

d) The emergency stop infrared sensor is fixed to the case of the module.

Sensor module-D according to the present invention serves to process a signal from the sensor as shown in FIG. Since various sensors such as ultrasonic waves, human detection and sound localization sensors are included in the sensor module-D, considerable processing of analog and digital signals is required. As shown in FIG. 18, the sensor module-D includes: a) a sensor module-D controller comprising an algorithm for calculating distance and communicating with other module-Ds via IEEE1394, b) an ultrasonic sensor unit (Max 32EA). ) Master manager with algorithms to manage distance, collect distance data, analyze each sensor status, and communicate with SBC, c) receive commands from master manager, detect obstacle distances, and use IEEE485 serial interface It consists of a sensor unit used to communicate with the master manager via. Each unit has a bidirectional communication channel and supports hot plugging.

Also, the vision module-D as shown in FIG. 19 is a vision dedicated module. Vision, a kind of sensor module, is designed as a stand-alone because it requires complex signal processing. The vision system processes the image data from the camera to send a video image or to extract features of the object from the image. Images acquired and processed by the Vision Module-D controller with SBC are transmitted to other Modules-D, mainly Intermediate Module-D, via the IEEE1394 network. Recently, for effective recognition, this module-D has been updated with a recognition module-D including an RFID system called a 3D RFID system.

The arbiter module-D shown in FIG. 20 is slightly different from the main controller of the other module-D. The arbiter module-D includes other module-Ds and makes a decision based on the results from the other module-Ds. The arbiter module-D is a base module that operates on its own (ie, without some module-Ds). By adding other module-Ds, the arbiter module-D achieves the necessary functions. As shown in Fig. 21A, the arbiter module-D communicates with IEEE1394 and a wireless LAN, and analyzes and processes data collected from other module-Ds. This information is referenced by the operator and is not needed for calculations or processes that directly affect the movement of the robot. For example, when the robot moves toward the target and encounters an obstacle, a series of processes for obstacle avoidance are executed by the mobile module-D and the sensor module-D. On the other hand, the vision module-D simply obtains information about the change of the moving trajectory and conveys the information to the operator. Thus, the arbiter module-D can be considered an arbiter, while for example mobile, sensor, and vision modules are defined as functional modules. These program flowcharts are illustrated in Fig. 21B.

As shown in FIG. 22, the arbiter module-D is composed of a battery unit and a power control units. Two types of battery packages (Ni-MH and Li-ion) supply 24 volts to the actuators and 12 volts to the control circuit. In order to protect the control circuit from electrical noise produced by the actuators, the power supplies are isolated from each other. The packages consist of cells (Ni-Mh: 1.5 volt cells, Li-ion: 3 volt cells). The battery cell manager monitors and automatically manages the state of cells for efficient and safe charging of packages. As shown in Figs. 22 (b) and 22 (c), the power control unit has three multi-function switches used to switch between the battery mode, the charging mode, and the external power mode. The power control unit also has an LED indicating a power supply state and a connector for connection to a charger.

To manage safe power control and keep configuration or reconfiguration assemblies safe, the module monitors current, voltage, temperature, battery discharge, and robot run time. The power supply is digitally and software switched to prevent overvoltage, overcurrent, voltage drop, and noise caused by plugging and unplugging processes or unexpected shocks. In addition, even during the charging of the wastewater treatment, an autonomous recovery process of maintaining the power supply without stopping the robot operation is achieved.

Next, an implementation of each module configured as described above will be described.

23 shows various modules-D integrated into various assemblies by different connections. Module-D as well as sub-modules or components such as sensors, motors, and circuits are easily replaced by new ones, since the robot is designed to support reconfigurable structures. Dynamic reconfigurability helps the flexibility of the control algorithm. Since Module-Ds are physically distributed, their low-level work is dependent on hardware and OS, and the process or information that certain actions require is present in other Module-Ds. However, VM-D, independent of hardware and OS, provides high-level intelligence compatibility, while IEEE1394 as a central nervous system sends distributed data to each module-D in real time. As illustrated in FIG. 24, for example, an action such as obstacle avoidance easily moves between module-Ds because the action consists of APIs, or a combination of APIs written in RPL. This means that developers of each module-D can easily test and debug their programs only if they can reference the APIs of the other module-Ds.

25, 26 and 27 illustrate the reconfigurable configuration of DRP I. 25 shows hot plugging with module-Ds. Two ways of detecting hot plugging events are used. One is to check the bus rest. When one module-D is added or removed, a bus reset occurs by node detection of IEEE1394 communication. The other is to periodically send small data of module-D information, called a heat bit, to another module-D. By monitoring these data, the system can know whether module-D has been added. IEEE1394 provides peer-to-peer network-based topology to Module-Ds with real-time processing requirements. The central server is not defined in the network, and each IEEE1394 node in the network can support itself and maintain the network. Thus, each module-D maintains its own characteristics and allows for module-D separation from the system without affecting the overall system or other module-D operation.

During hot plugging, the navigation algorithm of DRP I is autonomously reconfigured as shown in FIG. In the case of vision based navigation without sensor module-D, the camera position is reconfigured and new parameters are applied to the navigation. The robot navigates using only vision data, because the robot does not recognize other sensors. Similarly, when the robot does not recognize the vision module-D, the robot navigates using only the sensor data of the sensor module-D. As shown in FIG. 27, the range of each sensor of the sensor module-D is newly reflected in the navigation depending on the arrangement state of the module-Ds called 'module-swapping'. The dynamically reconfigurable configurations mentioned above demonstrate that Module-D's APIs are standardized and that robots assemble the APIs properly.

As mentioned above, although the invention made by this inventor was demonstrated concretely according to the said Example, this invention is not limited to the said Example and can be variously changed in the range which does not deviate from the summary.

As described above, according to the modular mobile robot system according to the present invention, it is possible to shorten the development time of related products by using modularization through standardization / standardization, strengthen international competitiveness and expand the market through securing reliability, and Economic effects can be expected.

In addition, according to the modular mobile robot system according to the present invention, by using the expandability of the modular robot, it is also possible to expect the added value increase through linkage with other industries using the same.

Claims (5)

A vision module for processing image data from a camera to transmit a video image or extract features of an object from the image, A sensor module for processing signals from sensors mounted on robots, A mobile module that provides the mobility of the robot and And a self-operating arbiter module for making judgments based on the results from the vision module, sensor module, and mobile modules. The method of claim 1, And each of the vision module, sensor module, arbiter module and mobile module have a module control unit and a test unit. The method of claim 2, And the module control unit and the test unit have an open or slide door-type case. The method of claim 1, And said arbiter module is comprised of a battery unit and a power control unit. The method of claim 4, wherein The arbiter module monitors current, voltage, temperature, battery discharge, and driving time of the robot supplied to each module of the robot.

Images