Distributed Robot Control

Distributed Approach for Robot Control Jinu Jyachandran [email protected]

Vivek Vijayan [email protected] Amrita School of Engineering Amritapuri

ABSTRACT: This paper deals with humanoid robot control

and hardware interfacing using a distributed system approach. Distributed computing has emerged as one of the main ways to achieve parallel processing and real-time computing. The platform independent nature helps the robotic components (like Head, Arm and Legs) to run on different machines under different configuration and can be efficiently controlled. The distributed robot control system uses JMS, Threads and Dynamic proxy technology which makes the system best suited for this particular application. The robot is controlled through voice commands which is taken by a client machine and sent to a remote central server. The central server will interact with different remote machines and will invoke these commands on corresponding machines. According to the commands the motors are controlled using a PIC microcontroller. The commands are accessed from remote machines through a wireless NIC placed inside the robot which is connected serially to the USART module of the PIC. The head part of the robot has webcams which is used to process images. According to the information given by the server software, which does image processing, the servo motors turn to track an object or to move the distance as specified by the controller. Each body part of robot is controlled by a specific PIC16F877 microcontrollers defined by an address. Thus according to the commands from client machine the robot can perform the various assigned tasks.

1 INTRODUCTION Humanoid Robots is becoming one of the inevitable part of the technological revolution. Some Robots are of such intelligence that it could compete that of a living being. This paper deals with design of such a robot which is controlled by distributed systems and its hardware interfacing. 2. DISTRIBUTED ROBOT CONTROL SYSTEM 2.2 SOFTWARE APPROACH– AN OVERVIEW Distributed computing has emerged as one of the main way to achieve parallel processing and real-time computing. The main reason behind this is openness and scalable architecture which makes developers make a system that is going to be independent of the operating environment. There many advantages for adopting this

technology. One is software development cost get reduced. That is many clients can access the same code. The client-side application development process is reduced because duplication of effort is less. Second reason is that resource loading can be better balanced. The whole client-server paradigm is based on the ability of many machines or processes to request the resources or services provided by a single or a few machines or processes, so that CPU, memory, and disk resources are more effectively allocated. And it also gives platform independence to your system. The client and server Communicate through a known protocol that does not rely on hardware. 2.3 CHARACTERISTICS OF DISTRIBUTED COMPUTING In a distributed environment, programs that the client runs make calls to programs in other address spaces, either locally or remotely. This approach allows the client program to be written specifically for the client architecture and still allows the client program to make calls (through a known protocol) to server programs that are running in a different architecture. 2.4 DESIGN CONSIDERATIONS There are some points to be remembered when designing distributed system. Here latency and partial failures can cause the system in a bad condition. Latency means the delay that is occurring during processing. Here proper analysis of what should reside locally and what can be accessed remotely is crucial to the performance of the distributed application. Obviously, a service that can be accessed over a local bus will be faster than one that must use the network. As the number and speed of processors that can be put in a system increases, the speed gap between local and remote access increases. Partial failures are to be considered. In a local application, if a single component fails (a disk crashes, a CPU panics, or memory fills up), the application will fail to run. When writing a local application catastrophic failure is not considered, because there is little if anything that you can do to recover.

Fig.1: General architecture for distributed object systems. Fig.2: 3. ADOPTED TECHNOLOGIES: 3.1 JMS (JAVA MESSAGING SERVICE) Messaging is a method of communication between software components or applications. A messaging system is a peer-to-peer facility: A messaging client can send messages to, and receive messages from, any other client. Each client connects to a messaging agent that provides facilities for creating, sending, receiving, and reading messages. This is based on two types of messaging systems.

3.2 DYNAMIC PROXIES: Dynamic Proxies allow new types to be generated on-the-fly at runtime. These types enable the composition of generic services around existing code. A proxy forces to call the methods indirectly through the proxy object. Here client object will not be aware of the existence of proxy object.

Point-to-point messaging service Publish subscribe messaging service. Messaging enables distributed communication that is loosely coupled. A component sends a message to a destination, and the recipient can retrieve the message from the destination. However, the sender and the receiver do not have to be available at the same time in order to communicate. In fact, the sender does not need to know anything about the receiver; nor does the receiver need to know anything about the sender. The sender and the receiver need to know only what message format and what destination to use. In this respect, messaging differs from tightly coupled technologies, such as Remote Method Invocation (RMI), which require an application to know a remote application's methods.

Fig.3 Architecture of Dynamic Proxy.

3.3 JAVA THREADS: Objects provide a way to divide a program up into independent sections. Each of these independent subtasks is called a thread, and you program as if each thread runs by itself and has the CPU to it self.

Fig.4: Remote threading in java

4. ARCHITECTURE OF DISTRIBUTED ROBOT CONTROL SYSTEM For a robot there will be multiple components (like Head, Arm, Leg etc.).In order to build a distributed application for robot these components should run on different machines and should be efficiently controlled. The robot which we are working has got Arm, Head and Base components. Our main aim was to develop an application that will hide all the system complexities from the user. Here we employed dynamic proxies and XML files. The user can configure the robot by editing the xml file where he/she can give needed modules (like Head, Arm etc.). For our robot speech driven commands are used. Here user can give commands through microphone and it will be send to the corresponding module which resides in a remote machine. The arm module incorporates commands for movement in four directions (Up, Down, Left, Right). The head module uses image recognition techniques for finding out the path. The base module is also speech driven which gives motion in four directions. The client machine will first configure the robot by adding available components to the xml file according to the need. Now it will send commands to each module through a user interface. These commands are sent to the remote server through messaging service. The messaging service uses both point-to-point and publish subscribe systems. Common commands such as system shutdown, restart etc are uses publish subscribe systems in which all

modules are informed about the command. But module specific commands are sent using point-to-point services. Here each module will have a queue And client will put commands for that particular component to that particular queue. There will be a messaging broker running at back end which will sent these commands to the queue listener running on remote servers. The queue listener program will look whether the message is coming from the queue which it is listening to, if yes it will invoke a message read program which will read the command for that particular module. The queue listener will be running only when a container class invokes it. The dynamic proxy will look for particular component class which is residing at the at the server side and after finding the class it will create a proxy class for that component during run time. This proxy class will invoke the commands sent by the client machine. The main advantage of using this proxy class is that it provides a level of abstraction between control program and component program. So that addition of extra modules will not affect the control program. shows the creation of a proxy. The thus created proxy can be invoked with the help of Invocation Handler ( ) method. This is show in The efficiency of the entire system depends on how these modules are coordinated. We use thread programming for this purpose. Resource allocation is based on producer-customer concept where some levels of priorities are given for particular commands. Problem of deadlocks are avoided since each component is interacting with client through a particular queue. Dependencies are handled by the container program where it will allow programs to run according to their priorities. The architecture can be as sown below:

5. ADVANTAGES OF PROPOSED SYSTEM:

Fig.5: Client Architecture

1. Uses JMS which is a loosely coupled technology. So client and server do not have to be available at the same time in order to communicate. This gives a operational independency so that user can send messages at any time and whenever the robot is started it will operate according to the user request. Also by using non-persistent queues we can make it a tightly coupled system. It is a better replace for RMI. 2. Any number of clients can be supported by the system. Because the queue we are using has got no size limits. 3. User interactive. Each module can be configured by the user and speech driven commands are used. 4. Code reusability. When addition of extra modules is done by the user there is no need to change the main control program. 5. Dynamic Proxies and Threads provide a good level of code abstraction and efficient controlling. 6. It is not mandatory that system components should run on different machines. User can run whole system in one machine without considering the distributed nature. 6. DISADVANTAGES SYSTEM:

OF

PROPOSED

Obviously the problem that we had discussed about distributed system applies to here also. Partial failures may lead to whole failure of the system. But the problem of latency is solved up to a limit by using the messaging service.

Fig.6: Server Architecture

7. HARDWARE The humanoid robot has a hardware part which does the functions as by the commands of the software. The hardware components consists of mainly a PIC 16F877A microcontroller, a servo motor and the component circuits. The PIC has a USART module which is used to interface with the serial port of the PC. There is also a PWM module in the PIC which can be used to set the duty cycle of the pulse used to control the motor. The motors used are servo motors which have an advantage of in built feedback. There are 3 servo motors used in the head, 6 servo motors in each hand and 2 DC motors for the base. Each body part will be controlled by a specific PIC recognized by an address from the serial port. According to the instructions given by the software the duty cycle of the addressed motor will be set and the motor turns to the will of controller. The head has 2 webcam acting as its eyes and are

used for image processing and tracking. The head moves according to the instructions from the software to track the object. 7.1 PIC 16F877A PIC 16F877A is a 8-bit microcontroller with a RISC CPU. There are five ports A,B,C,D,E with 5,8,8,8,3 pins respectively to communicate with the external environment. There is also a USART(Universal Synchronous Asynchronous Receiver Transmitter) module which is used to connect the system inside the robot to the microcontroller. The RC6 pin of the PIC is a serial transmitter pin and RC5 pin is the serial receiver pin. As the PIC works on 5v supply and the output of the serial port of the PC gives a swing from -12v to 12v the voltage cannot be directly connected to the microcontroller. So the serial output is connected to a MAX232 IC which accepts this voltage and delivers a voltage which has a swing from 0v to 5v. 7.1.1 PWM Pulse Width Modulation is used to set the duty cycle of a square pulse. The on time of the square pulse is called duty cycle. Also it is the on time of a servo and a DC motor. So by controlling duty cycle we can control the motor. There is a PWM module in the PIC 16F877A microcontroller. If we want to set the duty cycle, we need only to pass duty cycle values to registers which automatically fixes the duty cycle The RC2 pin is the output pin of the PWM module. The PWM module in the PIC works by interrupt. After the timer has counted the value in the duty cycle register an interrupt comes which makes the output of RC2 pin compliments its previous value. Thus the duty cycle value is changed. 7.1.2 USART The USART module can be configured either as transmitter or a receiver. The transmitted value is given to a register and is transmitted bit by bit after each clock pulse. An interrupt is generated after the transmission and can be made ready for next. Similarly for reception, The received value is stored in a register and interrupt is generated after it being full and the value can be used for processing. The thing to be noted is the baud rate of the PIC and the PC should be same otherwise the received data will be corrupted. Totally there will be 3 main PIC microcontrollers for each part namely head, arm and

base. These should be selected according to the needs. The first 8 bits coming from the serial port detects the PIC to be made active. The next 8-bits gives the PIC which motor to be controlled and the last 8-bits determines the degree the motor to be rotated. The 8-bits after it again addresses the PIC that may be the previous one or another, which repeats. 8. MOTORS The 3 types of motors mainly used are DC motors, Stepper motors and Servo motors. The DC motors are difficult to control. They cannot be stopped suddenly moreover they have no in built feedback. The lack of in built feedback and the huge size make the stepper motor unsuitable. The Servo motors are of light weight and have a feedback circuit. The servo motors work on the principle of PWM. For normal servo motors the period is 18ms and can have a maximum duty cycle of 2ms.It can be made to turn the desired degree by giving the appropriate duty cycle

Fig,7

9. PARTS OF THE ROBOT AND THEIR CONTROL The different parts should be controlled in a synchronized way so as to do the specified function. 9.1 HEAD Head of the Humanoid robot consists of 1 servo motor in the common axis for the web camera acting as the eye, used to track the horizontal motion and 1 motor for the neck, used to track vertical motion . The webcam is used to capture the image. This image is sent to software where the image processing is done. 9.1.1 IMAGE PROCESSING The image received is divided into many cells. This cell system has a center cell. The object to be tracked is placed in the center cell. When the object moves the object is displaced from the centre cell. The software calculates the distance it moved from the centre cell. Now the system needs to bring back the object to the middle cell. So the calculated value is passed to the PIC and command the motors to move the specified distance. Now again the object will be moved to the centre cell. This process is repeated when the object moves. As received from the software the distance the motor should move, the PIC calculates the corresponding duty cycle for the servo motor and commands it. The servo motors in the eyes moves to bring back the image into the middle of the cell if it is vertical motion, and the motors in the neck for horizontal motion. 9.2 ARM Arm uses 6 motors – 2 motors in the shoulder,1 motor at the elbow ,1 for wrist and 2 for fingers. The PIC controlling these motors receives their instructions from the serial port. 9.3 BASE The base needs to be turned 360 degree. So

the base consists of 2 polar DC motors. These motors have a driver circuit. Relay switches can also be used instead of driver circuits. 10. CONCLUSION The distributed system approach helps to make controlling of robots more efficient since it provides modular independency and remote controlling. The microcontroller used in the robot gives the user much more flexibility. The speed of control transfers are more efficiently done using the microcontroller. Since servo motors can be completely controlled by PIC, there is much more control over the system. This way of approach in humanoid robotic design could also meet the industrial needs which gives an aid to the technological revolution. 10.1 FUTURE ENHANCEMENTS The USB interfacing with PIC 18F4550 can also be done efficiently as it gives more speed to the Robot. There can also be a speech recognition system. The base used by the Robot can be changed to legs which could balance by it’s own. The Robot can also made to sense the terrain, where it moves, so that it can adapt to any type of situations. The robot can also be tracked efficiently if we could design the system for GPS. The technology like artificial intelligence makes the ‘humanoid robot’ equivalent to a human. ACKNOWLEDGMENT REFERENCES [1] PIC 16F877A datasheet, Microchip Technology . [2] Java Message Service, SUN Microsystems. [3] Dynamic Proxies for Classes: Towards Type Safe And Decoupled Remote Object Interaction Patrick Thomas Eugster Swiss Federal Institute of Technology, Lausanne