KR20070050285A - Method to communicate camera image in robot common framework - Google Patents

Abstract

The present invention relates to a method for transmitting and receiving camera images in a robot common framework, and more particularly, to a method for transmitting and receiving camera images by a robot application program and a robot abstraction layer in a robot common framework. A method of transmitting and receiving a camera image on a robot common framework of the present invention may include: requesting, by a robot application program, to transmit image data to a robot abstraction layer; Obtaining external image data by the robot abstraction layer requested to transmit the image data; And transmitting the externally acquired image data to the robot application program until the robot application program requests to stop transmitting the external image data. According to the present invention, since the robot abstraction layer continuously transmits the image data, it is possible to reduce time delay due to image transmission and reception and to reduce the response time of the robot.

Abstraction layer, robot, standard, image, interface

Description

Method to communicate camera image in Robot Common Framework}

1 is an abstraction method of robot hardware.

2 illustrates a robot virtual model and a virtual model approach in a client-server environment.

3A illustrates a global and local coordinate system.

3b is a local coordinate system for sensor location.

4A structure of the CRIF-Framework.

4b is a process flow of CRIF-Framework.

5 is a video transmission and reception process according to an embodiment of the present invention.

6 is a conceptual diagram of a continuous video transmission and reception process according to an embodiment of the present invention.

7 is a data structure of an image transmission request command according to an embodiment of the present invention.

8 is a data structure of an image transmission stop command according to an embodiment of the present invention.

9 is a block diagram of a continuous video transmission and reception process according to an embodiment of the present invention.

{Description of Signs of Major Parts of Drawings}

501: Robot Application 502: Robot Abstraction Layer

503: camera

The present invention relates to a method for transmitting and receiving camera images in a robot common framework, and more particularly, to a method for transmitting and receiving camera images by a robot application program and a robot abstraction layer in a robot common framework.

The industrial robot market, which began in the 1980s, grew rapidly based on the development of labor-intensive industries such as the automobile and electronic industries, and the industrial robot market has expanded in earnest as robots are put into production. However, as the industrial robot market entered into maturity in the 1990s, the stagnation of the market acted as an opportunity to seek industrial formation and technological development in new fields. Robots in this new field are changing from the industrial robots that focus on simple repetitive work in the fixed environment with the recent increase in social demand for domestic labor and other living support and the progress of the aging society. It is being developed in the form of a service robot that actively responds to the environment and provides services closely related to human beings. In particular, with the breakthrough of semiconductor, computer and communication technology, the robot field is forming a new robot market called intelligent service robot based on information and communication technology. For example, the commercialization of intelligent service robots, originated from S's pet robot A, has moved away from the notion that robots are used only in the field of replacing human labor, which has led to an increased awareness of entertainment and role as human companions.

The domestic intelligent service robot industry is launching rudimentary intelligent robot products such as entertainment robots and home robots around 20 venture companies, and large companies are trying to develop their own intelligent robot technologies in conjunction with intelligent home appliance technology development. S company is developing toy robot Anto, home robot child kid and its successor model, imaro, and are preparing to commercialize within one to two years. L company has released roboting robot, a cleaning robot.

In particular, large corporations are expected to lead the field by quickly overcoming the differences in technology level with existing small start-ups, with their skills in a variety of business areas, abundant research personnel and capital.

Domestic industrial robots rank fourth in the world in terms of production scale, contributing to strengthening the competitiveness of manufacturing industries such as semiconductors and automobiles, but domestic industrial robots are less competitive than developed countries due to their high dependence on technology and core parts of robots. Due to the recent industry downturn, the existing industry is losing vitality. Since 2000, many small and medium venture companies have developed and commercialized home, entertainment, educational, and service robots according to the global trend of the robot industry.In addition, the world's intelligent robot competitions and international intelligent robot exhibitions have been held in Korea. The possibility of industrialization is increasing. D company has launched a 16-joint human robot, Lucy, and a number of educational and research robots using low-cost RC servo motors. R has also grown mouse toy robots like Ditty and Titi and combat Gladiator robots. It was released. Microrobot is commercializing educational robot kits and competition robots, and is developing modular robots as a next-generation robot technology development task. Our technology, in collaboration with KIST, developed and displayed the home guide and cleaning robot Isaac, launched the cleaning robot, and is developing a public exhibition robot as the next task. Y has commercialized soccer robot Victor and is preparing to commercialize home educational robots Pegasus and Irobi. H has commercialized research robots and soccer robots, developed defense robots and cleaning robots Autoro, and many other companies are contributing to the industrialization of educational and toy robots.

According to the IT New Growth Engine Planning Report, intelligent service robots will be named Ubiquitous Robotic Companion (URC) and will promote industry activation and technology development based on business models. Here, URC is defined as “a robot that is with me anywhere and at any time and provides the services I need.” By introducing the URC concept that adds a network to the existing robot concept, various advanced functions or services can be provided. The human interface is greatly improved, and the possibility of providing various services and enjoyment at a lower price on the user side is expected to be greatly expanded. The scope of the URC considers that it must be connected to the network infrastructure and have intelligence, but also include software mobility as well as hardware mobility in terms of mobility.

URC, which combines robots and networks, presents new possibilities for the growth of the robot industry by overcoming the limitations of each. Previously, all the necessary functions and technical burdens were solved by the robots themselves, which resulted in technical limitations and cost problems. However, by sharing functions externally through the network, it is possible to reduce costs and increase usability. In other words, by combining robots with the functional possibilities brought by the development of IT technology, it became possible to develop into a robot industry based on human-centered technology by having a more free form, wider mobility, and a human-friendly human interface.

In a situation where there is no standardized robot as in the present, almost all aspects related to the implementation of the robot, such as its function, its structure, control method, and control protocol, can vary greatly depending on the intention of the manufacturer or designer. none. Applications developed for specific robotic platforms are unlikely to work on other platforms. In addition, porting is also very difficult because hardware-dependent parts are scattered throughout the program. As a result, the development of robot functions and applications is inevitable, which is considered to be one of the important factors that hinders the development of robot technology.

The most typical solution to this problem is to abstract the hardware-dependent part of the robot platform. That is, as shown in FIG. 1, the application program may reduce the dependency on the hardware of a specific robot by using only the hardware functions and services of the robot provided through the abstracted hardware layer.

Meanwhile, as the performance of various sensors, actuators, and control boards constituting the robot device is improved and modularized, a number of control boards are mounted in recent robots and the robots are generally controlled through communication between the boards. The platform of the form is spreading. In addition to the trend of modularization and decentralization inside the robot, decentralization in the form of controlling and providing services to the robot remotely through a network is also progressing.

An object of the present invention is to provide a method for transmitting and receiving camera images obtained from a robot on a framework that enables a common interface to a robot device for URC and an interface on a client-server structure.

Another object of the present invention is to provide a method for transmitting and receiving a camera image that simplifies the process of transmitting and receiving a camera image by simplifying the image transmission and reception method.

In order to achieve the above object, a method of transmitting and receiving a camera image on a robot common framework according to the present invention includes: requesting, by a robot application program, to transmit image data to a robot abstraction layer; Obtaining external image data by the robot abstraction layer requested to transmit the image data; And transmitting the externally acquired image data to the robot application program until the robot application program requests to stop transmitting the external image data.

In the present invention, the robot abstraction layer preferably obtains image data using at least one camera.

In the present invention, when the robot abstraction layer transmits the externally acquired image data to the robot application program, the robot abstraction layer preferably transmits the image data in a compressed data format.

In the present invention, the command transmitted by the robot application program to request image data transmission to the robot abstraction layer preferably includes an image transmission request command frame, a camera ID frame, a transmission period frame, and a callback function ID or port number frame. Do.

In the present invention, the command data transmitted by the robot application program to request to stop transmitting image data to the robot abstraction layer preferably includes an image transmission stop command frame and a camera ID frame.

In the present invention, the process of acquiring the external image data by the robot abstraction layer requested to transmit the image data and transmitting the external image data to the robot application program may be repeated continuously until the robot application program requests to stop transmitting the external image data. .

In the present invention, the externally obtained image data is preferably transmitted to the robot application program at a certain period.

In the present invention, it is preferable that the image data acquired from the outside transmitted from the robot abstraction layer is temporarily stored in the image buffer.

Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings. In adding reference numerals to components of the following drawings, it is determined that the same components have the same reference numerals as much as possible even if displayed on different drawings, and it is determined that they may unnecessarily obscure the subject matter of the present invention. Detailed descriptions of well-known functions and configurations will be omitted.

In the present invention, a common robot interface framework (CRIF) is defined. CRIF is a common interface (CRIF Interface) using a kind of virtual robot for the purpose of hardware abstraction to reduce the hardware platform dependency of an application and improve portability, and a framework for supporting it in a client-server environment (CRIF-Framework). ) Is the standard for.

2 shows a robot virtual model and a virtual model approach in a client-server environment. The robot application program accesses the hardware resources of the robot or controls the robot using a common interface according to the standard defined by the present invention.

In the present invention, as shown in FIG. 2, a model for a kind of virtual robot is established and a common interface thereof is provided. The virtual robot is equipped with a differential wheel drive, a pan-tilt head with a camera, a distance sensor device that can measure the distance from an external object of the robot, a bumper sensor for collision detection, and a microphone device that receives sound. It is preferably defined as a robot having a speaker device for outputting sound, an imaging device for acquiring an external image of the robot, and a battery voltage sensing device.

The common interface defined in the present invention provides an interface for accessing the accessory of the robot as shown in FIG. 2, and does not define an interface for accessing other devices. The interface framework defined in the present invention is a structure that extends the common interface defined in this standard to be available in a client-server environment. In this case, the robot application program and the robot device forming a client-server structure mainly mean an environment in which the robot application program exists inside the robot but operates in a different computing node from the robot accessory device. However, the robot application can be applied to a remote environment in which a robot runs on a processor outside the robot device.

The common interface defined in the present invention is applicable to a robot having one or more of the robot accessories. In addition, the common interface framework defined in this standard is applicable to the case of supporting a remote function call method in communication between the robot and the robot device.

The objects directly affected by the common interface specification of the present invention are robot application program developers and robot developers. The robot application program developer develops the robot application program according to the common interface standard defined in this standard, and the robot developer takes charge of the actual robot hardware-dependent implementation to support the common interface standard defined in this standard.

The object directly affected by the interface framework specification of the present invention is a framework developer. The framework developer should develop the framework according to the standard defined in the present invention. Robot application developers or robot developers are not affected by the framework of this standard.

Since the framework is responsible for client-server communication between robot applications and robots, robot application developers or robot developers only need to observe common interfaces.

Since the device hardware constituting the robot varies depending on the platform or device, its characteristics and types vary, so in order to standardize the interface for accessing the robot device, it is desirable to first establish a kind of model for the robot platform and define a common interface based thereon. Do. In the present invention, in order to reduce dependency on a specific robot device, an abstract robot model is presented and an API, which is a standardized interface for accessing the functions and services of the robot, is defined.

The robot is an entity supporting the common interface standard defined in the present invention, and the implementation of the common interface implements the common interface standard according to the device characteristics of the robot. In the present invention, in order to provide a common interface to the robot application program, a model for a kind of virtual robot is established and a common interface thereof is provided.

In CRIF-Interface, every application commands an action on a virtual robot. When controlling a specific robot through such a virtual robot model, the application program has an advantage of resolving the dependency on the hardware of the specific robot.

However, if a specific robot platform has a special function or mechanism that is not defined in the virtual robot model, it is impossible to use the special function or instrument through the CRIF-Interface, so it is flexible to include as many functions as possible. We need to define a set of interfaces.

However, on the other hand, if it includes functionality that is rarely used, the CRIF-Interface becomes more complex than necessary, and of course, the implementation according to the hardware specification is complicated.

Therefore, the virtual robot model defined in the present invention is a wheel drive device of the differential type, a pan-tilt capable of attaching a camera, a distance sensor device capable of measuring a distance between an external object of the robot, and a collision as described above. It consists of a bumper sensor for sensing, a microphone device for receiving sound, a speaker device for outputting sound, an imaging device for acquiring an image from outside the robot, and a battery voltage sensing device.

Table 1 shows the apparatus provided by the robot defined in the present invention.

Classification standard Mover Differential drive wheel with two main drive motors Head 1 pan-tiltable head control Distance sensor device N sonar or infrared distance sensor arrays Bumper sensor N bumper sensor array Sound input device N microphones Sound output device 1 speaker Video input device N cameras Battery monitor 1 battery voltage sensor

The parameter unit for the interface for the movement of the robot is shown in Table 2.

parameter unit Street M time wife Angle Radian Linear velocity m / s Angular velocity Rad / s Line acceleration m / s ² Angular acceleration Rad / s ²

The coordinate system uses a three-dimensional rectangular coordinate system composed of x, y, and z, as shown in FIG. 3a. In the local coordinate system, the front of the robot is x, the left side is y, and the vertical direction is the z axis. θ is an angle formed by the x-axis and the y-axis, and the front side of the robot is 0 degrees and the left side of the robot is 90 degrees. γ is an angle formed by the xy plane and the z axis (see FIG. 3B).

Hereinafter, the interface for driving the robot is defined as follows.

The robot manager provides the initialization and termination of the entire robot and the device information of the robot platform.

The movement interface performs commands such as driving and stopping the wheels mounted on the robot, sets the maximum speed and acceleration of the robot, and knows the current speed and position. Internally, encoder and encoder are used to perform speed and position control.

The speed control command includes the SetWheelVel () function that directly controls the speed of both wheels, the SetVel () function that sets the linear and angular velocity of the robot. The position control command includes the Move () function that moves forward or backward, There is a Turn () function that rotates by a given relative angle and a Rotate () function that rotates with a given relative angle and radius.

In addition, there are functions to get the current speed and position, and functions to set the line acceleration, angular acceleration, maximum linear speed and maximum angular velocity. Finally, Stop () to stop the robot, and stop quickly in an emergency situation. There is an EmergencyStop ().

Position control in Wheel Implementation uses only the robot local coordinate system based on the robot's current position. That is, when Move () or Turn () function is called, it moves a certain distance or rotates by a certain angle based on the robot position at that time.

Head control includes information about the robot head, the current angle of the head, the command to set the saturation speed of the robot head pan and tilt and to command the head to rotate at a predetermined angle at a specified rotation speed.

Camera controls include camera resolution information, information about the zoom driver attached to the camera, a list of supported resolutions of the specified camera, camera ID, the current resolution of the specified camera, the resolution setting of the specified camera, the current frame rate of the specified camera, Set the frame rate, acquire and stop the specified image information, store or return the acquired image in the buffer, information about the zoom of the specified camera and the zoom factor, and information about performing the zoom operation.

Proximity sensor interface is an interface to the sensor array that can find out the distance to obstacles such as sonar sensor or infrared distance sensor mounted on the robot. A set of sensors with the same characteristics is called a sensor array. When multiple sonar sensors with the same characteristics are arranged, they form one sensor array. There can be several such sensor arrays, each identified by an ID.

The bumper sensor interface is an interface to bumper sensors that can notify the robot when it collides with an external obstacle, such as a bumper mounted on the robot or an array of infrared sensors that recognize a very short distance. Indicate if there is a collision with an obstacle. A set of sensors with the same characteristics is called a sensor array. If multiple sonar sensors with the same characteristics are arranged, they form one sensor array. There can be several such sensor arrays, each identified by an ID.

The battery monitor checks the battery voltage for the mains.

The speaker outputs the voice data through the speaker, and the microphone control obtains the voice data from the open microphone channel.

Hereinafter, a CRIF-Framework for communicating through the above interface is defined.

4 is a structure of a CRIF-Framework defined in the present invention.

CRIF-Framework defines a framework for extending CRIF-Interface into a client-server environment. The elements that make up the CRIF-Framework are the layer where the CRIF-Interface exists that the client-side application developers use to drive the robot, and the server-side robot platform developers implement the API defined in the CRIF-Interface for the actual robot operation. There is a layer, and a layer responsible for communicating these two layers.

CRIF-Framework, as mentioned, provides a common framework that application developers or robotic hardware developers can use to develop their respective systems. Application developers on the client side can control and access the robot hardware using the interface provided by CRIF-Framework. Robot hardware platform developers on the server side can control the robot according to the API definition defined in CRIF-Framework. In order to run the API, the contents of the API are implemented for each platform so that the client can control and access the actual hardware required.

As shown in Figure 4, the CRIF-Framework is located on the client side and server side at the same time, and consists of Robot API Layer (RAL), API Sync Layer (ASL), and Robot API Presentation Layer (RAPL). In addition, a part of RAL and ASL are located on the client side, and a part of ASL and RAPL are located on the server side. That is, the developer on the client side can access the RAL and use the interface supported by the CRIF-Framework. On the server side, the developer can access the RAPL and use the interface supported by the CRIF-Framework.

Robot API Layer (RAL) provides an interface that application developers can use. Access to each device of the robot is possible only by using the interface provided by the RAL. Access by other means is not possible. In other words, the RAL provides an access point for accessing and operating the abstracted robot model. The API defined in the CRIF-Interface is not implemented in the RAL. RAL is only responsible for passing CRIF-Interface function called from application to ASL. Actual implementation of CRIF-Interface is done by H / W Dependent API Implementation (HDAI) at server side.

The interface provided in API Sync Layer (ASL) is delivered to Robot API Presentation Layer prepared for real function on server side through ASL. In other words, ASL is responsible for connecting RAL and RAPL. The ASL consists of two sublayers, each consisting of a layer connected to the RAL on the client side and a layer connected to the RAPL on the server side. The roles of each sub-layer are the same, but the details are different.

API function called from client RAL is transmitted to API Decoder of server side through API Encoder, and return value after hardware operation by transmitted API function or data value indicating the state of robot hardware It is sent to Data Decoder of client by Data Encoder of. Eventually, the function of ASL performs Encode / Decode function of API function called in application program and Encode / Decode function of data transmitted from robot hardware.

Robot API Presentation Layer (RAPL) is in charge of the connection with hardware Dependent API Implementation (HDAI) which hardware developers write on server side for actual implementation of API defined in RAL. In practice, it acts as a counterpart of RAL, and the configuration is the same as that of RAL. The difference is that in case of RAL, the application calls RAL's API, but RAPL acts as a reference point that specifies the API to be implemented in HDAI. Coding for actual API operation is done in HDAI. That is, RAPL plays a role as an access point of HDAI. As a result, the CRIF-Interface can be accessed through RAL from the application development side, and the CRIF-Interface can be accessed through the RAPL from the hardware development side. ASL is the link between RAL and RAPL and is not directly accessible from the application / hardware development side.

In the CRIF-Framework, client and server connections are made through ASL. ASL is composed of two sub-layers of ASL Client consisting of API Encoder / Data Decoder and ASL Server composed of API Decoder / Data Encoder. The connection between client and server is made by corresponding elements such as API Encoder ↔ API Decoder, Data Encoder ↔ Data Decoder. When a specific API is called on the client side, it is sent to API Decoder on the server side through API Encoder, and the return value according to the result of the API operation is sent to the data decoder on the client side through Data Encoder on server side to the application. Delivered.

In practical implementations, the connection of the two sublayers can be accomplished in several ways. Connection of each Encoder / Decoder can use the same method as Socket, COM, CORBA, and the connection method can be selected as shown in the example of Table 3 according to the operating system of the client or server side. As you can see from the example in Table 3, the choice of connection method depends on the operating system on the client or server side, and it must support all possible connection methods that depend on the operating system.

operating system Connection method Client server socket COM COBRA MS Windows MS Windows O O O MS Windows Linux O X O Linux MS Windows O X O Linux Linux O X O

Referring to Figure 4b, look at the processing sequence between the robot and the application program on the client / server structure using the CRIF as follows.

First, in order to operate the robot in the application program, the API defined in the RAL is called (1). Pass information (function name, parameter, etc.) about the called API to API Encoder (2). The delivered API information is delivered to API Decoder according to the protocol according to the connection status of ASL. In case of TCP / IP connection, it is delivered in the form of predefined packet. In case of DCOM or CORBA, it is made according to the interface access (3). According to the information of the API passed to the API Decoder, the same API as the API called in (1) is called in RAPL (4). The API on the RAPL calls the API of the HDAI, which is actually implemented (5). The called HDAI API internally converts the robot device into a command that the robot device can understand and delivers it to the robot device (6). Pass the result as the return value of the called API. This is just a process of passing the result after the API called in (1) actually runs the hardware. As an example, after the API for reading the value of the ultrasonic sensor is called and actually operated, the distance value obtained from each sensor is transmitted to the application program by this process (7).

The CRIF-Interface and the CRIF-Framework of the present invention defined as described above obtain an image by controlling a camera as described above. The data structure and command for controlling the same are specifically defined as follows.

● data structure

struct CameraResolution {

int Hor; Shows horizontal resolution.

int Ver; Vertical resolution.

} About Camera Resolution

struct CameraResolutionArray {

int NumberOfMembers; Indicates the number of resolutions that can be supported.

CameraResolution * Members; Each resolution is shown.

} Camera Resolution Array List

struct ZOOM_INFO {

bool is_zoom;

int minZoom;

int maxZoom;

} Information on the zoom drive attached to the camera

● CameraResolutionArray * GetSupprotedResolutions (int nID)

(1) parameter

-[in] nID Specifies the camera ID.

(2) return value

Returns a list of supported resolutions for the specified camera. If the function fails, it returns null.

Int GetMaxFrameRate (int nID)

(1) parameter

nID [in] Specifies the camera ID.

(2) return value

Returns the maximum frame rate of the specified camera (frame / sec).

● CameraResolution * GetResolution (int nID)

(1) parameter

-[in] nID Specifies the camera ID.

(2) return value

Returns the current resolution of the specified camera. If the function fails, it returns null.

Bool SetResolution (int nID, CameraResolution Resolution)

Sets the resolution of the specified camera.

(1) parameter

-[in] nID Camera ID

[in] Resolution Camera resolution

(2) return value

Returns true if the function succeeds, false if it fails.

Int GetFrameRate (int nID)

Returns the current frame rate of the specified camera (frame / sec).

(1) parameter

-[in] nID Camera ID

(2) return value

The current frame rate of the specified camera, in frames / sec.

Bool SetFrameRate (int nID, int nRate)

Sets the frame rate of the specified camera (frame / sec).

(1) parameter

-[in] nID Camera ID

[in] nRate frame rate

(2) return value

Returns true if the function succeeds, false if it fails.

● Bool StartCapture (int nID)

Starts acquisition of the specified video information.

(1) Parameters: none

(2) return value

Returns true if the function succeeds, false if it fails.

● Bool StopCapture (int nID)

Stop acquiring the specified video information.

(1) Parameters: none

(2) return value

Returns true if the function succeeds, false if it fails.

Bool GetRawImage (int nID, char * buffer)

Stores the image acquired by the specified camera in the buffer and returns it. Image information is stored as 24bit RGB data.

(1) parameter

-[in] nID Camera ID

-[out] buffer Buffer to save image data

(2) return value

Returns true if the function succeeds, false if it fails.

Bool GetConpressedImage (int nID, char * buffer)

Stores the image acquired by the specified camera in the buffer and returns it. Image information is stored in JPEG format.

(1) parameter

-[in] nID Camera ID

-[out] buffer Buffer to save image data

(2) return value

Returns true if the function succeeds, false if it fails.

● ZOOM_INFO GetCameraZoomInfo (int nID)

Returns information about the zoom of the specified camera.

(1) parameter

-[in] nID Camera ID

(2) Return Value: ZOOM_INFO

Zoom information for the specified camera

Int GetCameraZoom (int nID)

Retrieves the current zoom factor for the specified camera.

(1) parameter

-[in] nID Specifies the camera ID.

(2) return value

Returns the current zoom factor of the specified camera.

Bool ZoomTo (int nID, int nFactor)

Zoom in on the specified camera.

(1) parameter

-[in] nID Specifies the camera ID.

-[in] nFactor Specifies Factor value to zoom.

(2) return value

Returns true if the function succeeds, false if it fails.

The camera control interface defined as described above proceeds as follows to acquire an image from the robot.

5 is a block diagram illustrating an image transmission and reception process according to an embodiment of the present invention.

Referring to FIG. 5, the robot common framework defined in the present invention includes a robot application program 501 and a robot abstraction layer 502, which exchange information with each other through a robot common interface. The robot application program 501 performs various image-based application operations, and requests the robot abstraction layer 502 to transmit an image (1). The robot abstraction layer 502 acquires an image using the camera 503 mounted on the robot (2), converts the obtained image into a form defined in the robot common framework (3), and the robot application program 501. (4). The robot application program 501 receiving the image transmitted by the robot abstraction layer 502 performs an application operation such as a person detection. The robot application program 501 and the image transmission / reception 502 of the robot abstraction layer are transmitted in a standardized form through a robot common interface, so that the robot application program 501 can be independently implemented in hardware. In this case, the robot common interface may be performed by a local call or by a remote call through a network.

6 is a flowchart illustrating a method of continuously acquiring an image in a robot according to another exemplary embodiment of the present invention.

Referring to FIG. 6, the robot application program 501 instructs the robot abstraction layer 502 to transmit an image data request in order to receive the image data (2). The robot abstraction layer 502 receiving the image data transmission request command obtains current image data from a predetermined camera 503 and compresses the current image data (3, 4). The compressed image data is transmitted to the robot application 501 (5). The compressed image data is continuously transmitted to the robot application program 501 at a predetermined period. When the robot application program 501 does not want to receive more image data, the robot image application command stops image data transmission. . The robot abstraction layer 502 having received the image data transmission stop command does not transmit any more image data.

7 and 8 illustrate data frames in an image transmission request command and an image transmission stop command according to an embodiment of the present invention.

Referring to FIG. 7, the image transmission request command includes image transmission request command information 701, camera ID information 702, a transmission period 703, and a callback function ID or port number information 704. The length of the frame for containing each piece of information is preferably at least 4 bytes. However, it is preferable that the length of the frame indicating the video request transmission command information 701 is variable. The image transmission request command information 701 indicates that the current command is image transmission request command information. The camera ID 702 is to determine which camera among the cameras provided with at least one of the robots to receive the image data, and the transmission period 703 is a time interval for the externally acquired image data. Determines whether to send to the robot application. When the image transmission request command is transmitted from the robot application program includes an ID of a call function to continuously execute a command performed before transmitting the command, and the port number is when the robot is controlled through a network. Contains information for determining the network address.

8 is a data structure of an image stop transmission command according to an embodiment of the present invention. Referring to FIG. 8, the image stop transmission command includes a frame 801 indicating a video transmission stop command and a frame 802 indicating a camera ID. The camera ID 802 includes ID information of a camera for stopping image transmission.

9 is a flowchart illustrating a process of transmitting / receiving continuous image data according to an embodiment of the present invention.

Referring to FIG. 9, in order for the robot application program 501 to continuously obtain image data, the robot application program 501 may include a vision processor 504, an image buffer 505, and a callback function 505. There is. If there is image data in the image buffer 505, the vision processor 504 reads the image data, performs vision processing such as face detection, and erases the image data. The image buffer 505 stores the image data transmitted by the robot abstraction layer 502 using the callback function 506 to temporarily process the image so that the vision processor 504 may process the image. The callback function 506 resides in the robotic application but is executed by the robot abstraction layer 502. The callback function 506 is used to send the image obtained by the robot abstraction layer 502 to the image buffer 505.

First, the robot application program 501 transmits an image transmission request command to the robot abstraction layer (S901). This video transmission request command includes a camera ID, a transmission period, and a pointer to a callback function. The camera ID indicates the number of the camera to acquire. The transmission period indicates the number of transmission frames per second, and the robot abstraction layer prepares an image transmission request command for how many frames per second the image should be transmitted to the robot application program 501. The pointer of the callback function is the pointer used by the robot abstraction layer to call the callback function of the robot application.

When the robot abstraction layer receives an image transmission request command (S902), the image is acquired from the camera 503 (S903), compressed (S904), and then a callback function is called to transmit the image to the robot application 501. In operation S905, the standby operation is performed for a predetermined time in order to match the image transmission period (S906). At this time, the robot abstraction layer 502 repeats the process of acquiring, compressing, and transmitting the above image until the image transmission stop command is received, so that the robot application program can continuously receive the image.

When the robot application program 501 wishes to terminate the vision processing for some reason, the robot application program transmits an image transmission stop command to the robot abstraction layer 502 (S907). When the robot abstraction layer 502 receives the image transmission stop command (S907), the process of acquiring, compressing, and transmitting the above image is stopped to terminate the image transmission process.

As described above, it has been described with reference to the preferred embodiment of the present invention, but those skilled in the art various modifications and changes of the present invention without departing from the spirit and scope of the present invention described in the claims below I can understand that you can.

As described above, according to the present invention, since the robot abstraction layer continuously transmits image data, it is possible to reduce time delay due to image transmission and reception and to reduce the response time of the robot.

Claims (8)

In the method for transmitting and receiving the camera image on the robot common framework, Requesting the image data transmission from the robot application layer to the robot abstraction layer; Obtaining external image data by the robot abstraction layer requested to transmit the image data; And And transmitting the image data acquired from the outside to the robot application program until the robot application program requests to stop transmitting the external image data. The method of claim 1, wherein the robot abstraction layer acquires image data using at least one or more cameras. The method of claim 1, wherein the robot abstraction layer transmits the image data acquired from the outside to the robot application program in a compressed data format. The method of claim 1, wherein the command transmitted by the robot application program to request image data transmission to the robot abstraction layer includes an image transmission request command frame, a camera ID frame, a transmission period frame, and a callback function ID or port number frame. Camera image transmission and reception method in a robot common framework, characterized in that. The robot common framework of claim 1, wherein the command data transmitted by the robot application program to request to stop transmitting image data to the robot abstraction layer includes an image transmission stop command frame and a camera ID frame. How to send and receive camera video. The method of claim 1, wherein the process of acquiring the external image data and transmitting the external image data to the robot application program is repeatedly performed until the robot application program requests to stop transmitting the external image data. Camera image transmission and reception method in the robot common framework, characterized in that. The method of claim 6, wherein the externally acquired image data is transmitted to the robot application program at a predetermined period. The method of claim 1, wherein the externally acquired image data transmitted from the robot abstraction layer is temporarily stored in an image buffer.

Images