Download - Omni Robot

7/29/2019 Omni Robot

1/6

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 andworking omni-directional mobile robot. Specifications for the communication were outlined, based on the posi-tional information from the robots two optical mice. A communication device was purchased and programs forthe interfacing to the PC and Mitsubishi M16C/62 microcontroller through the serial ports (RS 232) on the ro-bot were developed. The communication is half duplex, so when two way communications was achieved withdeveloped programs timing was important. The three degrees-of-freedom (x y and z) need to be relayed to thecomputer and back to the robot. Project is unable to be finished as the robot is broken. Results from the initialprograms indicate that control maybe possible if the additional wireless device features are used or control accu-racy reduced.

Keywords: Mecanum, omni-directional, wireless control, M16C/62

1 INTRODUCTION

This document focuses on developing PC basedwireless control of a previously constructed andworking omni-directional mobile robot.

The robot was first started as a Masters Thesis at thestart of the year 2000 [1]. During the year 2002 moreproject work was carried out on the robot [2]. At the

end of the year 2002 the robot consisted of a LCDdisplay, a new driver board and two optical mice that

were interfaced to a Mitsubishi M16C/62 microcon-troller.

The working robot at the start of 2003 could moveon a set path course programmed into the microcon-troller, display its working status and control wasmaintained via PID controllers.

For wireless control a wireless connection devicecalled a Direct Servo Wireless Communication De-

vice (DS-WCM) was purchased from Total Robots in

the U.K. The device was found to meet the require-ments that the positional data transfer rate and pro-ject budget. The product was purchased as a bundleof two devices with some additional wire connec-tions.

Tests were carried out on the devices to check theresignal reliability and strength in the laboratory envi-ronment. Results from these tests showed that thedevices would be fine for laboratory use in this pro-ject, with some careful placement to reduce the ef-fects of electronic interference.

Once testing was complete a series of programs weredeveloped for communication to the DS-WCMthrough the computers and microcontrollers serial

port. Adapting these two programs two way com-munications was developed between the microcon-troller and the computer using the wireless link.

At this point the project stalled due the robot beingbroken. Further development was not carried on pastthis point but a number of possible options for add-ing the DS-WCM to the robot were considered asthe device has many ways it can be interfaced to themicrocontroller.

With the delay of the communication, control of therobot may not be possible using just the normal datatransfer method used in the other programs. A com-bination of I/Os and the data bytes to relay infor-mation or a reduction in the accuracy of the controlmay make the system controllable.

2 BACKGROUND

At the start of 2003 the robot consisted of a LCDdisplay, a new driver board and two optical mice

were interfaced to a Mitsubishi M16C/62 microcon-troller. The robot was fully functional it could moveon a set path course programmed into the microcon-troller, display its working status and correct for slip-page in movement via the three programmed PIDcontrollers for x, y and z movement.

The two optical mice provide the positional informa-tion. The z movement is the rotation of the robotand is worked out by calculating the difference be-tween the two mice. The robot as it was received atthe beginning of this project can be seen in Figure 1.

The four Mecanum wheels that can be seen in figure1 make the omni-direction possible. The rollers onthe wheels are angled at 45 to the y axis (forwardand reverse). When the wheel is driven the move-

1


2/6

C.J. Duncan & Dr. W. L. Xu

ment force applied is at this angle. With four wheelsand controlling the speed and the direction move-ment in any direction can be achieved.

Figure 1 Existing robot as received.

The robot is a complete system and carries out mucha lot of computations for geometry, control andstatus. If the robot is going to have additional sen-

sors integrated or other devices then freeing up re-sources on the microcontroller will be needed. Beingable to move computations to a PC linked to themicrocontroller could accomplish this task.

2.1 PERFORMANCE SPECIFICATIONThe main goal for the wireless control of the omni-directional robot at the completion of the project isthat:

The control should be transferred to acomputer and there should not be any lossof control.

3 METHODOLOGY

To carry out this project steps for the project devel-opment were outlined. These simple goals are asfollows

Build or purchase a wireless communicationdevice.

Develop a PC and microcontroller pro-grams for communication

Integrate the Wireless device into the cur-rent robot

Transfer control from the robot to the PC Attempt to maintain the same accuracy in

control

Initially research into what communication productsthat was currently available was done. Products werejudged on several specifications that the robot and

project outlined. One of the more important specifi-cations the communication speed was located bylooking at the positional information that is neededfor the PID control, both how frequent the informa-tion is addressed and how much data is required tobe communicated.

After locating a product that meets the system re-quirements, the development of programs to estab-lish the communication was carried out. For eachend of the communication, the computer and micro-controller programs were created first. These werefor interfacing with the wireless device. Once theinterface is setup then developing two way commu-nications can be done.

The third goal is to integrate the communicationdevice on to the robot. This is comprised of hard-

ware and software elements. Placement of the devicewill be important to avoid electrical interference. By

programming the software in the other programscarefully much of the programs will be transferableto the robot program.

The fourth goal in the project is transferring the con-trol instructions from the robot program to thecomputer program. The instructions and the vari-ables will have to be adjusted but the robots controlinstructions are fairly simple to follow and shouldtransfer easily.

The last step or goal will be the tuning of the con-trollers PID values. A simulation of the robot system

was used to establish the values for the controllersand by adding in the approximate communicationdelay the PID values can be obtained. It is possible atthis point that the control of the robot will be deter-mined as not possible with the delay in the commu-nication. In this event adjusting the role of thecommunication maybe needed.

4 DESIGN METHODOLOGY

4.1 ESTABLISHING THE COMMUNICATIONREQUIREMENTS

There are a lot of communication possibilities forrobots, but not all are suitable for this type of com-munication role. To insure that the correct device

was constructed or purchased the requirements forthe communication needed to be outlined. Most ofthe specifications were fairly obvious but were stillimportant. They are as follows

The device needs to be able to interface tothe computer and microcontroller.

Communication must be both ways (PC torobot and robot to PC).

The data transferred must be accurate.2


3/6

Autonomous Control of an Omni-directional Mobile Robot

Reasonable power consumption. The range of the communication should be

suitable for laboratory work.

Other specifications of the system needed to be

worked out based on the robots programming andfree resources. The Mitsubishi M16C/62 on theMSA0654 development board has a number of I/Oports, serial port connection capable and is capableof I2C communication when configured correctly. Sothe interface method used is fairly flexible.

The communication speed required much moreworking in order to find the rate at which the dataneeds to be transferred. The robot obtains positionalinformation from the two mice every 0.3 sec. Eachmouse provides x and y positional data relative to thelast communication. The x and y data is sent in a

three byte format. The first byte is the control bytewith overflow and sign bits.

These three bytes from one mouse need to be trans-ferred to the PC every 0.03 seconds. The data rate

was worked out on the bases of this information andwas found to be 2400 bits per second. Included inthis calculation is an additional 3 bytes meant as asafety factor and some redundancy for future appli-cations. It is important to note that this value as-sumes that the data is can flow both ways at the sametime or full duplex. This value assumes that all themice data 6 bytes needs to be relayed back to the PC.

4.2 THE PRODUCT SELECTIONThere are a considerable number of communicationsproducts on the market today. Many of the productsthat were found were too expensive (above $200NZ) or if affordable then could not produce any-

where near the data transfer rate needed. Transceiv-ers and transmitter/receiver pairs were both lookedat and half/full duplex products were considered.Most of the considered products were half duplexproducts sold by companies overseas and were lo-cated on the internet.

4.3 THE PRODUCT SELECTEDThe product decided on is the Direct Servo WirelessControl Module (DS-WCM) purchased in a bundledpair would be suitable for the robots needs. The de-

vice is half duplex but has a communication rate of4800 bps. There are a number of features to the de-

vice that made it an attractive purchase [7].

The device itself uses 18 registers that configure thedevice or are data to be transferred to the remote

device. To assign data to the registers then the datasent to it must be sent in a packet indicated by sur-rounding brackets and the correct values for readingdata, writing data and etc must be included. Each

device contains a transmitter and receiver pair undera protective cover. An onboard OOPic microcon-troller is also placed under the cover.

Figure 2 Direct Servo Wireless Control Module(DS-WCM) cover off.

4.4 TESTING THE PRODUCTUsing the software provided with the DS-WCM andtwo serial ports on the same computer, the twocommunication devices were tested by sending databack an forth, turning I/Os on and off (shown by anLED) and reading the I/O values as inputs at theremote device. The devices were moved around thelaboratory in test to locate the how the device waseffected in it s performance. The devices were placedat 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 re-sults recorded. This test was done in order to get anidea of the communication quality for both penetra-tion and distance

4.5 PC (CREATED SOFTWARE) TO PC(PROVIDED SOFTWARE)

The first program developed was a simple programthat would send data via the serial port. The value 50

was to be sent across the wireless link and would waitfor a confirmation signal or error. In constructingthis program an example program was located on the

internet for serial port communication (RS 232). Thisprogrammed called comport sourced from [3] wasused as a template and customized to the DS-WCM

3


4/6


needs. Adjustments to the settings were needed forthe required serial port communication rate and forthe other requirements of the DS-WCM. The serialport had to be configured for 4800 baud no parity,no handshaking, 8 data bits and 1 stop bit. To senddata to the DS-WCM the correct data packet neededto be sent. This data is the setup information for the

registers onboard the DS-WCM. It configures thetimeout period, the DS-WCM address, the address tosend to and other settings of the device.

This program made use of methods of both sendingand receiving data from the DS-WCM. Any sendingand receiving of data would follow a similar methodto this program. Only the addition of some loopsand assigning the values of certain registers wouldproduce a program that could communicate con-tinuously.

4.6 MICROCONTROLLER TO PC (PROVIDEDSOFTWARE)

The development of this program is the much likethe previous software, as the data packet is sent andthe DS-WCM values transferred. Whats different isthe setting up of the serial communication. The mi-crocontroller uses several registers to configure thecommunication protocol. To transmit and receive onthe microcontroller the values of the register need tobe changed, unlike the PC program where receivingis just a different command.

4.7 DATA TRANSFERRED BOTH WAYSTransferring data both ways is more difficult as tim-ing of the communication becomes more of a factor.One side of the communication has got to start thecommunication and the other must be waiting toreceive the data or the communication will becomeconfused.

The microcontroller was decided to be the initial sideof the transmission. As the final robot program canonly process information when the robot is ready tostart movement. At the other end the PC program is

programmed to stay in continuous loop of checkingthe DS-WCM for data transferred. Once data is re-ceived then the PC sends the value 4 back. The mi-crocontroller first sent through the value one, thesecond time it can transmit the value two is sent andso on, until the PC transmits a zero back. The zeroindicates 100 has been sent through in the lasttransmission, at this point the program ends.

Developing this program was a fairly straight forwardprocess as much of the previous programs design isthe bases for this one. In this program however mak-ing use off subroutines that could be used on the

robots final programs was done.

4.8 ADAPTING TO THE ROBOTS PROGRAMFor the placement of the communication programsinto the robots program and the transfer of the PIDcomputations to the PC, the transfer of the instruc-tions is fairly straight forward in. Variables would

need to match to the programs at each end of thecommunication and with a few other adjustments theprogram should work. The computations carried out

would easily transfer to the PC and the programshould fit into the internal flash memory of the mi-crocontroller.

During the process of development a possible role ofthe I/Os on the DS-WCM has been considered as a

way that the data overflows and direction bits couldbe relayed to the robot and vice versa. There are 8I/Os on the device, if four are configured as inputsand four as outputs then the range of the data values

could be increased from -128 to 127 (8 bits) to 16times this range (12 data bits). This would mean thatthe data sent to the PC could be carried out less fre-quently. If this is not needed then the I/Os could beused to indicate the start and stop and which databyte is being sent i.e. x, y or z (the rotational move-ment). There is no need to send all 6 data bytes if thecalculation of z is calculated on the microcontroller,as z indicates the difference in the two x and y valuesat each mouse. The same I/Os may also be used asan interrupt on the robot to indicate data transferred.

The programs to this point have being polling theserial connection checking for a change in the data.

4.9 THE CONTROLLABILITY OF THE ROBOTWith the PID control on the robot the robot canachieve a reasonable amount of control, but whenthis control is placed on to the PC the added delay ofthe communication could result in the system beinguncontrollable. To make the system controllable theamount of positional data processed may need to bereduced.

In carrying out tests and some of the programs de-velopment programs the speed of the data beingtransferred seems to be a bit low for control giventhe positional information needs to be sent every0.03 seconds. If this rate of data transfer was intro-duced to the DS-WCM then the device could notkeep up. The device should be able to carry out thedata transfer rate by the calculations done earlier buterror correction methods programmed in to the de-

vice seem to slow the transfer rate.

For the system to remain controllable the frequencyat which the three PIDs operate would need to bereduced. This could be done by increasing the dataamount transferred and sending the combination of

two mouse readings. If needed additional overflowbits could be added to take into the doubled up data.

4


5/6

Autonomous Control of an Omni-directional Mobile Robot

Another option is to reduce the reading resolution ofthe mice. Each mouse was designed to take readingsat such a rate that 17 counts per mm were taken.

This level of positional accuracy seems to successivefor a mobile robot of this type. So dividing the posi-tional counts down to just 1 value per mm the

amount of data transferred could be reduced greatly.

4.10 MOUNTING THE DS-WCM DEVICE ONTHE ROBOT

The DS-WCM device for the robot needed to bemounted in a position that would allow the aerial tobe clear to pick up signals and try to place the devicein a location that would reduce the interference fromthe other onboard electronics. Looking at the robot,attaching the device to the plastic cover above themicrocontroller appears to be the best place. Themount itself will hold the PCB of the device screwed

to the cover. There are no side guards to the mountas this would just help in blocking the signal from thedevice. Figure 3 is an adapted picture of where thedevice would be mounted.

Figure 3 An adapted picture of the robot showingthe area where DS-WCM would be added.

4.11 DEVELOPMENT HALTEDAt this point the development and implementationcould go no further as the robot was broken. Adding

the programs to the robot would be pointless with-out being able to see if the control would work. Sothe communication system was not added to therobot.

4.12 DEVELOPMENT OBSTACLESIn carrying out this project a few problems haveslowed the progress on the project. Most were ex-pected from having to becoming familiar with thecurrent robots systems. The other obstacles were inbecoming familiar with the software for program-ming the Mitsubishi M16C/62 microcontroller andestablishing the serial port communication at the PC.

The first obstacle that was discovered was in under-standing the program established on the robot. Forthe most part the program was straight forward butcertain sections of the code were confusing in how it

was written. There are some notations present butsome simple repetitive instructions that could be in a

simple loop have been left written in out full.

The programming of the Mitsubishi M16C/62 mi-crocontroller was an obstacle as this microcontrolleris far more complex a micro than I have worked onin the past. The software has certain settings thathave to be changed between different tasks or theprogramming wont work. For instance the debugprogram will run will the normal setup and can loadand run most programs. If the serial port is discon-nected at any time the program will fail. In order toload the internal flash memory with the programFlashsta.exe must be used. This software requires

configuring itself and setting up the microcontrollercorrectly as well. Finding out how to do this wasdifficult as the manual was of little aid. To change theprogramming files that are loaded on to the micro aseparate library in the project editor program must beinstalled. The fact that this software is not explained

well and the manual is little help in explaining theconfiguration of the software used was the main bot-tleneck in the project.

The last main obstacle faced was in establishing theserial communication on the PC. This was more dueto the fact that this type of PC hardware program-ming was a new topic and it took sometime to workout the best compiler to do the programming on.Most of the more well known compilers can do thistype of programming, but to find references on howto do this for most of the compilers difficult.

5 RESULTS AND DISCUSSION

Results from the testing done on the penetration anddistance of signal transfer capabilities showed thepenetration was not that consistent. The wall was tolarger medium for the signal to penetrate and thecomputers interference was too great for the signal,

but the window and room distance tests showedmore promising results. The transfer of the radiosignal through the glass window is a good indicationthat the plastic cover should not be a problem for thecommunication from the robot.

Interference from the computer is something thatwill have to be avoided as it seems to affect the signalquality greatly. Moving the PC DS-WCM device tothe same side as the robot is a good idea. The samesort of electrical interference will be seen on the ro-bot. Placement of the DS-WCM on the robot will beimportant to avoid this.

The programs developed in the project so promisingresult as a whole. Data could transfer at a reasonablerate with the programs and no cases of incorrect data

5


6/6


were seen in the development. Sending data acrossthen wireless connection is fairly straight forward toprogram and follow. More of a problem is that thedata is not automatically transferred out at the otherend, with the exception of the I/O pins that changeas soon as the data is received.

Two way communication developed is a good meansof transferring data between the two ends of theconnection. With the use of subroutines the programis easy to follow and will transfer to the robots pro-gramming with little hassle. Setting up the timingbetween the two devices is something that has to becarefully implemented. If the devices get out of syn-chronisation then it is possible for data to get lost inthe transmission or the communication just wont gothrough.

For PID control the data transfer may add too muchdelay to the system for the control to be maintained.

A better idea maybe to use the PC to set the targetcoordinates of the robot and other general supervi-sory control roles e.g. Start, Stop, environment map-ping, etc.

6 CONCLUSIONS

With the robot not operational it is hard to say if thecontrol would have worked. Any conclusions have tobe made on what the programs developed seemedcapable of doing. From these programs I would con-clude that using the same positional resolution thatthe original Omni directional robot used would place

too much demand on the system and control wouldbe lost. Altering the resolution may return control tothe system but at a small cost to the accuracy.

If control cant be obtained by the system then therole of the PC may have to be altering to a supervi-sory controller. This would still be of benefit to the

system as the coordinates would no longer need tobe fixed but could be specified by the user.

7 REFERENCES

[1] Phillips, J.G, Mechatronic Design and Con-struction of an Intelligent Mobile Robot for Educa-tional Purposes Massey University, PalmerstonNorth, New Zealand, 2000.

[2] Cooney, J.A, Motion Control and Intelligenceof an Omni-directional Mobile Robot Massey Uni-

versity, Palmerston North, New Zealand, 2002.

[3] http://bbdsoft.com/

[4] http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/PS2/ps2.htm

[5] Pappas, C.H & Murray III, W.H, The VisualC++ 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
http://bbdsoft.com/http://panda.cs.ndsu.nodak.edu/~achapwes/PIC%20micro/PS2/ps2.htmhttp://panda.cs.ndsu.nodak.edu/~achapwes/PIC%20micro/PS2/ps2.htmhttp://www.m16canz.com/http://www.totalrobots.com/http://www.totalrobots.com/http://www.m16canz.com/http://panda.cs.ndsu.nodak.edu/~achapwes/PIC%20micro/PS2/ps2.htmhttp://panda.cs.ndsu.nodak.edu/~achapwes/PIC%20micro/PS2/ps2.htmhttp://bbdsoft.com/

Download - Omni Robot

Top Related