AUTONOMOUS CONTROL OF AN OMNI-DIRECTIONAL MOBILE ROBOT

Projects, Vol. 11, 2004 ISSN 1172-8426 Printed in New Zealand. All rights reserved. 2004 College of Sciences, Massey University AUTONOMOUS CONTROL OF AN OMNI-DIRECTIONAL MOBILE ROBOT C. J. Duncan Abstract: This document focuses on developing PC based wireless control of a previously con constructed and working omni-directional mobile robot. Specifications for the communication were outlined, based on the positional information from the robots two optical mice. A communication device was purchased and programs for the interfacing to the PC and Mitsubishi M16C/62 microcontroller through the serial ports (RS 232) on the robot were developed. The communication is half duplex, so when two way communications was achieved with developed programs timing was important. The three degrees-of-freedom (x y and z) need to be relayed to the computer and back to the robot. Project is unable to be finished as the robot is broken. Results from the initial programs indicate that control maybe possible if the additional wireless device features are used or control accuracy reduced. Keywords: Mecanum, omni-directional, wireless control, M16C/62 1 INTRODUCTION This document focuses on developing PC based wireless control of a previously constructed and working omni-directional mobile robot. The robot was first started as a Masters Thesis at the start of the year 2000 [1]. During the year 2002 more project work was carried out on the robot [2]. At the end of the year 2002 the robot consisted of a LCD display, a new driver board and two optical mice that were interfaced to a Mitsubishi M16C/62 microcontroller. The working robot at the start of 2003 could move on a set path course programmed into the microcontroller, display its working status and control was maintained via PID controllers. For wireless control a wireless connection device called a Direct Servo Wireless Communication Device (DS-WCM) was purchased from Total Robots in the U.K. The device was found to meet the requirements that the positional data transfer rate and project budget. The product was purchased as a bundle of two devices with some additional wire connections. Tests were carried out on the devices to check there signal reliability and strength in the laboratory environment. Results from these tests showed that the devices would be fine for laboratory use in this project, with some careful placement to reduce the effects of electronic interference. Once testing was complete a series of programs were developed for communication to the DS-WCM through the computers and microcontrollers serial port. Adapting these two programs two way communications was developed between the microcontroller and the computer using the wireless link. At this point the project stalled due the robot being broken. Further development was not carried on past this point but a number of possible options for adding the DS-WCM to the robot were considered as the device has many ways it can be interfaced to the microcontroller. With the delay of the communication, control of the robot may not be possible using just the normal data transfer method used in the other programs. A combination of I/O s and the data bytes to relay information or a reduction in the accuracy of the control may make the system controllable. 2 BACKGROUND At the start of 2003 the robot consisted of a LCD display, a new driver board and two optical mice were interfaced to a Mitsubishi M16C/62 microcontroller. The robot was fully functional it could move on a set path course programmed into the microcontroller, display its working status and correct for slippage in movement via the three programmed PID controllers for x, y and z movement. The two optical mice provide the positional information. The z movement is the rotation of the robot and is worked out by calculating the difference between the two mice. The robot as it was received at the beginning of this project can be seen in Figure 1. The four Mecanum wheels that can be seen in figure 1 make the omni-direction possible. The rollers on the wheels are angled at 45º to the y axis (forward and reverse). When the wheel is driven the move- 1

C.J. Duncan & Dr. W. L. Xu ment force applied is at this angle. With four wheels and controlling the speed and the direction movement in any direction can be achieved. Figure 1 Existing robot as received. The robot is a complete system and carries out much a lot of computations for geometry, control and status. If the robot is going to have additional sensors integrated or other devices then freeing up resources on the microcontroller will be needed. Being able to move computations to a PC linked to the microcontroller could accomplish this task. 2.1 PERFORMANCE SPECIFICATION The main goal for the wireless control of the omnidirectional robot at the completion of the project is that: The control should be transferred to a computer and there should not be any loss of control. 3 METHODOLOGY To carry out this project steps for the project development were outlined. These simple goals are as follows Build or purchase a wireless communication device. Develop a PC and microcontroller programs for communication Integrate the Wireless device into the current robot Transfer control from the robot to the PC Attempt to maintain the same accuracy in control Initially research into what communication products that was currently available was done. Products were judged on several specifications that the robot and project outlined. One of the more important specifications the communication speed was located by looking at the positional information that is needed for the PID control, both how frequent the information is addressed and how much data is required to be communicated. After locating a product that meets the system requirements, the development of programs to establish the communication was carried out. For each end of the communication, the computer and microcontroller programs were created first. These were for interfacing with the wireless device. Once the interface is setup then developing two way communications can be done. The third goal is to integrate the communication device on to the robot. This is comprised of hardware and software elements. Placement of the device will be important to avoid electrical interference. By programming the software in the other programs carefully much of the programs will be transferable to the robot program. The fourth goal in the project is transferring the control instructions from the robot program to the computer program. The instructions and the variables will have to be adjusted but the robots control instructions are fairly simple to follow and should transfer easily. The last step or goal will be the tuning of the controllers PID values. A simulation of the robot system was used to establish the values for the controllers and by adding in the approximate communication delay the PID values can be obtained. It is possible at this point that the control of the robot will be determined as not possible with the delay in the communication. In this event adjusting the role of the communication maybe needed. 4 DESIGN METHODOLOGY 4.1 ESTABLISHING THE COMMUNICATION REQUIREMENTS There are a lot of communication possibilities for robots, but not all are suitable for this type of communication role. To insure that the correct device was constructed or purchased the requirements for the communication needed to be outlined. Most of the specifications were fairly obvious but were still important. They are as follows The device needs to be able to interface to the computer and microcontroller. Communication must be both ways (PC to robot and robot to PC). The data transferred must be accurate. 2

Autonomous Control of an Omni-directional Mobile Robot Reasonable power consumption. The range of the communication should be suitable for laboratory work. device contains a transmitter and receiver pair under a protective cover. An onboard OOPic microcontroller is also placed under the cover. Other specifications of the system needed to be worked out based on the robots programming and free resources. The Mitsubishi M16C/62 on the MSA0654 development board has a number of I/O ports, serial port connection capable and is capable of I2C communication when configured correctly. So the interface method used is fairly flexible. The communication speed required much more working in order to find the rate at which the data needs to be transferred. The robot obtains positional information from the two mice every 0.3 sec. Each mouse provides x and y positional data relative to the last communication. The x and y data is sent in a three byte format. The first byte is the control byte with overflow and sign bits. These three bytes from one mouse need to be transferred to the PC every 0.03 seconds. The data rate was worked out on the bases of this information and was found to be 2400 bits per second. Included in this calculation is an additional 3 bytes meant as a safety factor and some redundancy for future applications. It is important to note that this value assumes that the data is can flow both ways at the same time or full duplex. This value assumes that all the mice data 6 bytes needs to be relayed back to the PC. 4.2 THE PRODUCT SELECTION There are a considerable number of communications products on the market today. Many of the products that were found were too expensive (above $200 NZ) or if affordable then could not produce anywhere near the data transfer rate needed. Transceivers and transmitter/receiver pairs were both looked at and half/full duplex products were considered. Most of the considered products were half duplex products sold by companies overseas and were located on the internet. 4.3 THE PRODUCT SELECTED The product decided on is the Direct Servo Wireless Control Module (DS-WCM) purchased in a bundled pair would be suitable for the robots needs. The device is half duplex but has a communication rate of 4800 bps. There are a number of features to the device that made it an attractive purchase [7]. The device itself uses 18 registers that configure the device or are data to be transferred to the remote device. To assign data to the registers then the data sent to it must be sent in a packet indicated by surrounding brackets and the correct values for reading data, writing data and etc must be included. Each Figure 2 Direct Servo Wireless Control Module (DS-WCM) cover off. 4.4 TESTING THE PRODUCT Using the software provided with the DS-WCM and two serial ports on the same computer, the two communication devices were tested by sending data back an forth, turning I/O s on and off (shown by an LED) and reading the I/O values as inputs at the remote device. The devices were moved around the laboratory in test to locate the how the device was effected in it s performance. The devices were placed at several locations around the room. They locations were as follows 1. Next to the other DS-WCM. 2. At the fair end of the laboratory room. 3. On either side of the computer. 4. On either side of a glass window. 5. On either side of a wood wall. Each situation was trialled three times and the results recorded. This test was done in order to get an idea of the communication quality for both penetration and distance 4.5 PC (CREATED SOFTWARE) TO PC (PROVIDED SOFTWARE) The first program developed was a simple program that would send data via the serial port. The value 50 was to be sent across the wireless link and would wait for a confirmation signal or error. In constructing this program an example program was located on the internet for serial port communication (RS 232). This programmed called comport sourced from [3] was used as a template and customized to the DS-WCM 3

C.J. Duncan & Dr. W. L. Xu needs. Adjustments to the settings were needed for the required serial port communication rate and for the other requirements of the DS-WCM. The serial port had to be configured for 4800 baud no parity, no handshaking, 8 data bits and 1 stop bit. To send data to the DS-WCM the correct data packet needed to be sent. This data is the setup information for the registers onboard the DS-WCM. It configures the timeout period, the DS-WCM address, the address to send to and other settings of the device. This program made use of methods of both sending and receiving data from the DS-WCM. Any sending and receiving of data would follow a similar method to this program. Only the addition of some loops and assigning the values of certain registers would produce a program that could communicate continuously. 4.6 MICROCONTROLLER TO PC (PROVIDED SOFTWARE) The development of this program is the much like the previous software, as the data packet is sent and the DS-WCM values transferred. What s different is the setting up of the serial communication. The microcontroller uses several registers to configure the communication protocol. To transmit and receive on the microcontroller the values of the register need to be changed, unlike the PC program where receiving is just a different command. 4.7 DATA TRANSFERRED BOTH WAYS Transferring data both ways is more difficult as timing of the communication becomes more of a factor. One side of the communication has got to start the communication and the other must be waiting to receive the data or the communication will become confused. The microcontroller was decided to be the initial side of the transmission. As the final robot program can only process information when the robot is ready to start movement. At the other end the PC program is programmed to stay in continuous loop of checking the DS-WCM for data transferred. Once data is received then the PC sends the value 4 back. The microcontroller first sent through the value one, the second time it can transmit the value two is sent and so on, until the PC transmits a zero back. The zero indicates 100 has been sent through in the last transmission, at this point the program ends. Developing this program was a fairly straight forward process as much of the previous programs design is the bases for this one. In this program however making use off subroutines that could be used on the robots final programs was done. 4.8 ADAPTING TO THE ROBOTS PROGRAM For the placement of the communication programs into the robots program and the transfer of the PID computations to the PC, the transfer of the instructions is fairly straight forward in. Variables would need to match to the programs at each end of the communication and with a few other adjustments the program should work. The computations carried out would easily transfer to the PC and the program should fit into the internal flash memory of the microcontroller. During the process of development a possible role of the I/O s on the DS-WCM has been considered as a way that the data overflows and direction bits could be relayed to the robot and vice versa. There are 8 I/O s on the device, if four are configured as inputs and four as outputs then the range of the data values could be increased from -128 to 127 (8 bits) to 16 times this range (12 data bits). This would mean that the data sent to the PC could be carried out less frequently. If this is not needed then the I/O s could be used to indicate the start and stop and which data byte is being sent i.e. x, y or z (the rotational movement). There is no need to send all 6 data bytes if the calculation of z is calculated on the microcontroller, as z indicates the difference in the two x and y values at each mouse. The same I/O s may also be used as an interrupt on the robot to indicate data transferred. The programs to this point have being polling the serial connection checking for a change in the data. 4.9 THE CONTROLLABILITY OF THE ROBOT With the PID control on the robot the robot can achieve a reasonable amount of control, but when this control is placed on to the PC the added delay of the communication could result in the system being uncontrollable. To make the system controllable the amount of positional data processed may need to be reduced. In carrying out tests and some of the programs development programs the speed of the data being transferred seems to be a bit low for control given the positional information needs to be sent every 0.03 seconds. If this rate of data transfer was introduced to the DS-WCM then the device could not keep up. The device should be able to carry out the data transfer rate by the calculations done earlier but error correction methods programmed in to the device seem to slow the transfer rate. For the system to remain controllable the frequency at which the three PID s operate would need to be reduced. This could be done by increasing the data amount transferred and sending the combination of two mouse readings. If needed additional overflow bits could be added to take into the doubled up data. 4

Autonomous Control of an Omni-directional Mobile Robot Another option is to reduce the reading resolution of the mice. Each mouse was designed to take readings at such a rate that 17 counts per mm were taken. This level of positional accuracy seems to successive for a mobile robot of this type. So dividing the positional counts down to just 1 value per mm the amount of data transferred could be reduced greatly. 4.10 MOUNTING THE DS-WCM DEVICE ON THE ROBOT The DS-WCM device for the robot needed to be mounted in a position that would allow the aerial to be clear to pick up signals and try to place the device in a location that would reduce the interference from the other onboard electronics. Looking at the robot, attaching the device to the plastic cover above the microcontroller appears to be the best place. The mount itself will hold the PCB of the device screwed to the cover. There are no side guards to the mount as this would just help in blocking the signal from the device. Figure 3 is an adapted picture of where the device would be mounted. The first obstacle that was discovered was in understanding the program established on the robot. For the most part the program was straight forward but certain sections of the code were confusing in how it was written. There are some notations present but some simple repetitive instructions that could be in a simple loop have been left written in out full. The programming of the Mitsubishi M16C/62 microcontroller was an obstacle as this microcontroller is far more complex a micro than I have worked on in the past. The software has certain settings that have to be changed between different tasks or the programming won t work. For instance the debug program will run will the normal setup and can load and run most programs. If the serial port is disconnected at any time the program will fail. In order to load the internal flash memory with the program Flashsta.exe must be used. This software requires configuring itself and setting up the microcontroller correctly as well. Finding out how to do this was difficult as the manual was of little aid. To change the programming files that are loaded on to the micro a separate library in the project editor program must be installed. The fact that this software is not explained well and the manual is little help in explaining the configuration of the software used was the main bottleneck in the project. The last main obstacle faced was in establishing the serial communication on the PC. This was more due to the fact that this type of PC hardware programming was a new topic and it took sometime to work out the best compiler to do the programming on. Most of the more well known compilers can do this type of programming, but to find references on how to do this for most of the compilers difficult. Figure 3 An adapted picture of the robot showing the area where DS-WCM would be added. 4.11 DEVELOPMENT HALTED At this point the development and implementation could go no further as the robot was broken. Adding the programs to the robot would be pointless without being able to see if the control would work. So the communication system was not added to the robot. 4.12 DEVELOPMENT OBSTACLES In carrying out this project a few problems have slowed the progress on the project. Most were expected from having to becoming familiar with the current robots systems. The other obstacles were in becoming familiar with the software for programming the Mitsubishi M16C/62 microcontroller and establishing the serial port communication at the PC. 5 RESULTS AND DISCUSSION Results from the testing done on the penetration and distance of signal transfer capabilities showed the penetration was not that consistent. The wall was to larger medium for the signal to penetrate and the computers interference was too great for the signal, but the window and room distance tests showed more promising results. The transfer of the radio signal through the glass window is a good indication that the plastic cover should not be a problem for the communication from the robot. Interference from the computer is something that will have to be avoided as it seems to affect the signal quality greatly. Moving the PC DS-WCM device to the same side as the robot is a good idea. The same sort of electrical interference will be seen on the robot. Placement of the DS-WCM on the robot will be important to avoid this. The programs developed in the project so promising result as a whole. Data could transfer at a reasonable rate with the programs and no cases of incorrect data 5

C.J. Duncan & Dr. W. L. Xu were seen in the development. Sending data across then wireless connection is fairly straight forward to program and follow. More of a problem is that the data is not automatically transferred out at the other end, with the exception of the I/O pins that change as soon as the data is received. Two way communication developed is a good means of transferring data between the two ends of the connection. With the use of subroutines the program is easy to follow and will transfer to the robots programming with little hassle. Setting up the timing between the two devices is something that has to be carefully implemented. If the devices get out of synchronisation then it is possible for data to get lost in the transmission or the communication just won t go through. For PID control the data transfer may add too much delay to the system for the control to be maintained. A better idea maybe to use the PC to set the target coordinates of the robot and other general supervisory control roles e.g. Start, Stop, environment mapping, etc. 6 CONCLUSIONS With the robot not operational it is hard to say if the control would have worked. Any conclusions have to be made on what the programs developed seemed capable of doing. From these programs I would conclude that using the same positional resolution that the original Omni directional robot used would place too much demand on the system and control would be lost. Altering the resolution may return control to the system but at a small cost to the accuracy. If control can t be obtained by the system then the role of the PC may have to be altering to a supervisory controller. This would still be of benefit to the system as the coordinates would no longer need to be fixed but could be specified by the user. 7 REFERENCES [1] Phillips, J.G, Mechatronic Design and Construction of an Intelligent Mobile Robot for Educational Purposes Massey University, Palmerston North, New Zealand, 2000. [2] Cooney, J.A, Motion Control and Intelligence of an Omni-directional Mobile Robot Massey University, Palmerston North, New Zealand, 2002. [3] http://bbdsoft.com/ [4] http://panda.cs.ndsu.nodak.edu/~achapwes/pic micro/ps2/ps2.htm [5] Pappas, C.H & Murray III, W.H, The Visual C++ Handbook Osborne McGraw-Hill, 2600 Tenth Street, Berkeley, California 94710, U.S.A, 1994 [6] http://www.m16canz.com/ [7] http://www.totalrobots.com/ 6