edp final report updated vipul

Ryerson University

Engineering Design Project 2009/2010:

Robotic Arm Motion Tracking with

Haptic Feedback

FLC: Dr. Matthew Kyan

By:

Umair Niaz, Vipul Potluri, Daryl Adrian L. Yamson

2

Certificate of Authorship

We certify that this project is our own work. The work in this project has not previously

been submitted for a degree nor has it has been submitted as a part of requirements for a

degree except as fully acknowledged within the text.

We also certify that this report has been written by us. Any help that we have received in

our project work has been acknowledged.

We authorize Ryerson University to lend this report to other institutions or individuals for

the purpose of scholarly research.

Umair Niaz

Vipul Potluri

Daryl Adrian L. Yamson

3

Abstract

Robotic Arm Motion Tracking with Haptic Feedback

Umair Niaz, Vipul Potluri, Daryl Adrian L. Yamson

Telepresence is the idea that we can be „present‟ in a digital sense, from some remote

location. Telepresent haptic interaction extends the sensation of forces/touch across a

network. Extending this technology to robotic arms would be a great enhancement to user

experience. It‟s a known fact that robotic arms are extremely useful in several industrial

applications but the manual control of robotic arms has been found to be a bit difficult.

This project aims to develop a four degree of freedom (4 DOF) robotic arm that tracks the

motion of another similar 4 DOF input robotic arm wirelessly with simple haptic

feedback. The position of each joint of the input arm was taken using a set of

potentiometers attached to the joints. The movement in the joints would cause a change

in resistance in the potentiometer, hence causing a potential drop or increase. This change

in potential was then sent to the microcontroller as an analog input. This analog input was

then converted to a digital output PWM signal by the microcontroller that would be sent

wirelessly to the servomotors of the output arm to control the motion accordingly. The

rigidity of the object could be measured by a force sensor on the gripper of the output

arm, which sends a feedback to the input arm using a servo torque. This would enable the

user to know how hard the object is while handling it so that the user doesn‟t grip the

object too hard and end up breaking it. Another haptic functionality that was

implemented in this project was to sense the weight of the object. This function was

implemented by placing a force sensor below the arm to sense the weight of the object.

This weight was then translated to a feedback force on the input arm that is generated by

DC motors. Although this project demonstrates simple haptic functions, there is a lot of

scope for complex haptics to be implemented to feel the state of the object. This project

still has some issues related to noise. Even though, majority of the noise was removed

from the system, the user could feel minute jitter in the joints. However, this project was

able to demonstrate simple haptics that can create a base for much higher-level projects to

implement haptics.

4

Acknowledgements

We extend our gratitude to our instructor Dr. Matthew Kyan for being extremely helpful

in order to successfully complete this project and also for allowing us to work in his lab.

We would like to thank Dr. James Smith for his lessons in instrumentation, as they were

very helping while designing the hardware part. We would also like to thank for him for

his suggestions regarding the Haptics implementation in our project. We are also thankful

to Dr. Y.C. Chen for his lessons in robotics and control systems, as they were helpful in

understanding the kinematics behind the robotic arms. We would also like to thank Dr.

Gosha Zywno and Mr. Raymond Phan for helping us with our research in the initial

stages of the project.

Special thanks also go to Mr. Jim Koch for his suggestions in our hardware design. We

would like to thank our friends and family for all the support and mainly Shiv for being

our unofficial parts supplier when needed. We would also like to thank Mr. Ian Fyffe for

providing us with his research report that helped us a lot for a better understanding.

5

Table of Contents

Table of Figures ............................................................................................ 7

1. Introduction ............................................................................................ 8

1.1 Objective ................................................................................................................................... 8

1.2 Applications ............................................................................................................................. 9

1.3 System Overview ................................................................................................................... 9

2. Theory ................................................................................................... 12

2.1 Microcontroller ................................................................................................................... 12

2.1.1 Selection Criteria........................................................................................................ 12

2.1.2 Arduino Mega .............................................................................................................. 12

2.2 Actuators ............................................................................................................................... 13


2.2.2 Servo Control ............................................................................................................... 14

2.2.3 Torque Calculation .................................................................................................... 16

2.3 Haptic Functions ................................................................................................................ 17


2.3.2 Force Sensing Resistors .......................................................................................... 18

2.4 Communication................................................................................................................... 18


2.4.2 Zigbee Networking .................................................................................................... 19

3. Design .................................................................................................... 21

3.1 Robotic Arms ....................................................................................................................... 21

3.1.1 Building Materials ..................................................................................................... 21

3.1.2 Position Feedback ..................................................................................................... 21

3.2 Haptic Functionality ......................................................................................................... 23

3.2.1 Sensing the rigidity of the object ......................................................................... 23

3.2.2 Sensing the weight of the object .......................................................................... 25

3.3 Communication................................................................................................................... 26

3.3.1 Configuration ............................................................................................................... 26

6

3.3.2 Hardware Set-up ........................................................................................................ 28

3.4 Power Supply ....................................................................................................................... 29

3.4.1 Power Regulation ...................................................................................................... 29

3.5 Software ................................................................................................................................. 31

3.5.1 Position Feedback ..................................................................................................... 31

3.5.2 Gripper Haptics .......................................................................................................... 31

3.5.3 Weight Haptics ............................................................................................................ 32

3.5.4 Wireless communication ........................................................................................ 32

4. Performance and Results .................................................................... 35

4.1 Evaluation of Theoretical System Performance .................................................... 35

4.1.1 Evaluation of Theoretical System Speed .......................................................... 35

4.2 Evaluation of the Position Feedback Nature of the Robotic Arms ................ 35

4.3 Noise Reduction .................................................................................................................. 37

4.4 Physical Structure of the Robotic Arms ................................................................... 37

4.5 Haptic Functionality ......................................................................................................... 38

4.5.1 Rigidity Sensing .......................................................................................................... 38

4.5.2 Weight Sensing ........................................................................................................... 38

4.6 Wireless Communication ................................................................................................ 39

4.6.1 Performance Requirements ................................................................................... 39

4.6.2 Analysis of Performance ......................................................................................... 40

5. Conclusion............................................................................................. 41

6. Bibliography ......................................................................................... 42

7. Appendix A – Torque Calculation ..................................................... 43

8. Appendix B – Servo Modification ...................................................... 46

9. Appendix C – Datasheets .................................................................... 49

10. Appendix D – Code .............................................................................. 69

7

Table of Figures

Figure 1-1: System Block Diagram ................................................................................................ 11

Figure 2-1: Arduino Mega ................................................................................................................. 12

Figure 2-3: Servo Wires ..................................................................................................................... 14

Figure 2-2: Servo Motor Block Diagram ..................................................................................... 14

Figure 2-4: Pulse Variation for Servo Control .............................................................................. 15

Figure 2-5: Torque Calculation at the Joint ................................................................................ 16

Figure 2-6: Resistance vs. Force Plot ............................................................................................ 18

Figure 2-7: XBee module and XBee Shield ................................................................................. 19

Figure 2-8: XBee Point-to-Point Configuration ........................................................................ 20

Figure 2-9: XBee Radiation Pattern .............................................................................................. 20

Figure 3-1: Output Robotic Arm..................................................................................................... 21

Figure 3-2: Position Feedback for Servo ..................................................................................... 22

Figure 3-3: 10K Potentiometer ....................................................................................................... 22

Figure 3-4: Driving Gear of the Servo .......................................................................................... 23

Figure 3-5: Wires to motor contacts + position feedback .................................................... 25

Figure 3-6: Zibgee Modules on Arduino ...................................................................................... 26

Figure 3-7: XBee parameters ............................................................................................................. 27

Figure 3-8: Block Diagram for Wireless Communication ......................................................... 28

Figure 3-9: XBee shield jumper ...................................................................................................... 28

Figure 3-11: Power Regulation Circuit ........................................................................................... 29

Figure 3-10: Hardware connections of XBee, XBee shield and Arduino ........................ 29

Figure 3-12: Transformed Power Supply ................................................................................... 30

Figure 3-13: ‘A’ Wireless Test for a LED ..................................................................................... 33

Figure 3-14: ‘B’ Wireless Test of a Servo .................................................................................... 33

Figure 3-15: ‘D’ Wireless Test of a Servo from a FSR ............................................................. 33

Figure 3-16: ‘C’ Wireless Test of a Servo from a Potentiometer ........................................ 33

Figure 3-17: ‘E’ Wireless Test of the Robotic Arms ................................................................ 34

Figure 4-1: Output Arm controlled by Potentiometers on a breadboard ...................... 35

Figure 4-2: Position Feedback Nature of the Base Joint ....................................................... 36

Figure 4-3: Position Feedback Nature of the Elbow Joint .................................................... 36

Figure 4-4: Position Feedback Nature of the Wrist Joint...................................................... 36

Figure 4-5: Pivot Structure to support the Output Arm ....................................................... 37

Figure 4-6: Output Arm Gripper with FSR ................................................................................. 38

Figure 4-7: Output Arm with FSR .................................................................................................. 38

8

1. Introduction

Robotics has profound cultural roots. Over the course of the centuries, human beings

have been constantly seeking substitutes capable of mimicking human behavior and

sensing various interactions with our surroundings. In 1965, the Computer Graphics

pioneer Ivan Sutherland, envisioned the building of an “ulti-mate display”, a multimodal

synthetic environment, which included force and feedback [1]

. He was one of the first

researchers to realize the significance of the sense of touch, especially for the

enhancement of virtual worlds. As the philosopher Bertrand Russell put it in [2]

:

“It is touch that gives out sense of “reality”…Not only our geometry and physics, but out

whole conception of what exists outside us, is based upon the sense of touch.”

Nowadays, multimodal human-machine interfaces have been established as one of the

most important fundamental components of information technology in the 21st century.

They already have decisive impacts on all areas of our professional and private life, for

example covering everyday communication, manufacturing, trade, financial services,

health care and entertainment.

In recent times, the importance of sense of touch for human-computer interaction has

finally been realized and it is widely believed that haptic interfaces will be a major

improvement for human-system interaction. Nevertheless, although the need for high-

definition haptic systems has clearly been identified, up to now no haptic system has been

created that is used on a day-to-day basis. This is due to the fact that haptic technology is

still at its infancy and most of these devices are still just expensive prototypes.

The word „Haptics‟ is derived from the Greek word „haptesthai‟ which literally means „to

touch‟ [3]

. Haptics interface, therefore, gives the illusion of touching one‟s surroundings.

The word „surroundings‟ may refer to a real physical object but in a remote location or a

virtual object in a computer program. There are many types of Haptics interface, such as

Machine Haptics, Computer Haptics, Multimedia Haptics, etc. In our project, we will be

applying haptics interface that includes humans in the loop, referred to as Human haptics.

The idea is to make one of the robotic arms controllable by a human and the second arm

follow the user‟s instructions.

1.1 Objective

The main objective of this project is to build a robotic arm to implement simple haptic

functions. The first goal of the project was to build a robotic arm that tracks the motion of

a similar looking input robotic arm that is controlled manually by the user. The next main

goal was to successfully implement a few simple haptic functions on the robotic arms to

virtually sense the state of the object like the rigidity and the weight.

The above objectives had to be met with real-time movement having very minimal delays

or lags. Ideally, both arms are required to be moving very smoothly without jitters.

9

1.2 Applications

Robotic arms are extremely useful in several applications such as manufacturing, surgery,

handling hazardous objects, handling microscopic objects and very heavy objects.

Mastering the manual control of robotic arms has been found to be a bit difficult.

As the main goal of this project is to implement telepresence, this idea could be extended

to various other applications that do not require robotic arms at both ends. A similar idea

could be extended where the output robotic arm could be controlled using the human arm

directly, where the movement of the human arm controls the motion of the output arm.

A lot of other applications could be considered that are directly related to this project. A

haptic feedback to the applications mentioned above would definitely enhance the user

experience. Haptic robotic arms with powerful force feedback could be of a huge help to

product design engineers to check out complex assembly problems in a virtual reality

environment.

1.3 System Overview

The system can be divided into sub-blocks such as input, output, and power sub-blocks.

The input consists of an input robotic arm with two microcontrollers and their

corresponding wireless modules. The purpose of input robotic arm is to send position

feedback to the output arm using potentiometers and letting the user experience rigidity

and weight of the load at the output arm, i.e. gripper haptics and weight haptics. There is

a separate microcontroller for each of the functions - position feedback and haptics. One

of the microcontrollers is programmed to collect and send position feedback and other is

programmed to perform both gripper and weight haptics. Wireless module is used on

each microcontroller to send position feedback and receive haptics feedback.

The output consists of an output robotic arm, two microcontrollers, and wireless module.

The purpose of the output robotic arm is to follow the movement of the input arm exactly

through position feedback received. It is also responsible for sending gripper and weight

haptics feedback to the input arm for the user to experience. Same as input sub-block,

there are two microcontrollers, one for translating position feedback and other for

collecting haptics feedback. Thus, there are two wireless modules for each

microcontroller for receiving and sending information.

The power sub-block consists of a power supply suitably chosen to provide power to both

input and output arm. It has multiple ground and voltage terminals for easy access; it has

protective circuit for reverse, noise reduction instruments and a fuse.

10

The basic overview of system is given below:

Arduino Mega – One of the microcontrollers collecting input arm feedback to be

sent to the output arm through a wireless module.

Arduino Duemilanove – There are three of these microcontrollers, one at the

input side and two at the output side. One at the input side is responsible for

implementing haptics feedback. One of the two microcontrollers at the output side

is responsible for implementing position feedback and other is responsible for

collecting haptics feedback to be sent the input arm.

Arduino XBee Shield Wireless Module – It is the communication protocol

module employed for our system. There is a separate pair of XBee module for

robotic feedback and haptics.

Hitec HS-755HB Giant Scale Servo – This particular model is used at base and

elbow to support both weight of the arm and load. These high torque servo

motors.

Hitec HS-422HD Standard Heavy Duty Servo – This servo was employed at

wrist, gripper rotation, and gripper. This servo is small in size but has suitable

torque for our system.

10 K Potentiometer – Potentiometers were used to send position of each joint

from input to output arm. Depending on the resistance on potentiometer there will

be different potential difference translating into position feedback at output arm.

Interlink Electronics 0.5” Circular FSR – Force sensor used to sense the load at

the output arm. As the load is pressed hard the resistance of force sensor goes

down increasing potential difference. This potential difference is used along with

set threshold for gripper haptcs to sense rigidity of the load.

Hitec HS-422HD DC Motor – This servo was modified to control its DC motor

with a DC motor controller, ROB-09457. DC motor on servo has system of gears

providing enough torque for gripper haptics and weight haptics. One of them is

used at the gripper and other is used at the elbow of the input arm.

Interlink Electronics 0.2” Circular FSR – Force sensor responsible for sensing

weight of the object is placed underneath the output arm‟s base. As the load is

placed in the gripper the base exerts force on sensor which is sent to the input arm

for weight haptics.

ATX Power Supply Unit – It is PC power supply modified for our system to

fulfill power requirement of the system.

The entire functionality of the arm could clearly be understood looking at the block

diagram below. The motors and the potentiometers would be connected to the first

microcontroller that would send the data wirelessly to the microcontroller at the output

arm. This data would be sent to the servomotors to position accordingly. The force

sensors at the output arm will then communicate back wirelessly to give the haptic

feedback at the input arm.

11

Figure 1-1: System Block Diagram

12

2. Theory

2.1 Microcontroller

2.1.1 Selection Criteria

Microcontrollers come in various ranges, from low-power, small architecture to highly

sophisticated high-speed processor core. The selection is therefore, dependent on the

specific application. We look at the amount of memory required, number of I/O pins,

communication interfaces, programming language, ADC and DAC pins, and input and

output capture requirements, voltage supply, etc. Also, the MCU must be able to process

data in real-time, thus it must be capable of multitasking.

Microchip Technologies Inc.[4]

suggested following factors while selecting the

microcontroller:

Architecture 8 bit

Operating Frequency >1 KHz

Memory >15 KB

Digital Communication Peripherals Serial Communication (RS232, USB),

Wireless Protocols (optional)

Capture/Compare/PWM Peripherals Ideally 10 PWM (Output Compare or

DEMUX can be used as well)

Analog Input Ideally 10 (otherwise we need MUX)

Physical Size Small to Medium

Cost <$100

Programming Language C programming language

2.1.2 Arduino Mega

As stated before, for a given price we can buy the best MCU and evaluation board but we

are constraint by our budget. The

engineering solution is to employ as

much ingenuity possible while

remaining within the limited

resources. After evaluation, we

selected Arduino Mega MCU

evaluation board because it is the

least expensive of the available ones

in the market and more or less fulfills

our requirement with additional add-

ons, i.e., ZIGBEE modules for

Figure 2-1: Arduino Mega

13

wireless communication between the arms. It is not possible to include evaluation content

for every MCU in this report for brevity.

Summary of Features [4]

Microcontroller ATmega1280

Operating Voltage 5V

Input Voltage (recommended) 7-12V

Input Voltage (limits) 6-20V

Digital I/O Pins 54 (of which 14 provide PWM output)

Analog Input Pins 16

DC Current per I/O Pin 40 mA

DC Current for 3.3V Pin 50 mA

Flash Memory 128 KB of which 4 KB used by bootloader

SRAM 8 KB

EEPROM 4 KB

Clock Speed 16 MHz

2.2 Actuators 2.2.1 Selection Criteria

The basic requirement for the project is to use some kind of an actuator in order to make

the rotation of the arms possible. Two types of motors are considered in order to perform

this job.

Stepper Motor: A stepper motor works with permanent magnets, which are

attached to the output shaft. Around the body of the motor is a series of coils that

create a magnetic field that interacts with the permanent magnets. When these coils

are turned on and off the magnetic field cause the rotor to move. As the coils are

turned on and off in sequence the motor will rotate forward or reverse.

Servo Motor: A servomotor basically operates using pulse signals from the

microcontroller. The output shaft is then controlled according to the pulse widths of

the signal received by the microcontroller.

Various differences can be pointed out between both the motors, but the solid reason for

bending towards a servo is due to its position feedback control. Usually a stepper motor

easily serves the purpose of a servo in these kinds of robotic arms, as a high rotation per

min (rpm) is not required. The stepper motor would probably be better than a servo for a

general robotic arm, where high speed is not a priority due to its high holding torque

nature and a comparatively cheaper cost.

14

Therefore, even though a stepper motor would be a better choice for a non-industrial

robotic arm, where high acceleration is not a priority, the servomotor is considered for

our project as it operates similar to a stepper motor at low speeds but also provides

positional feedback. The amount of noise interference in servomotors would also be

much lesser when compared to the servomotor.

2.2.2 Servo Control

A servo consists of several internal main parts:

The motor

Gearbox

Position Sensor

Error Amplifier

Motor Driver

Circuit to decode the requested position

It can be seen in the figure below that three wires are coming out.

Red – Power (+5V)

Black - Ground

White/Yellow (depending on the servo) – Coded Signal

The servo consists of an output shaft. This shaft can be positioned to specific angular

positions by sending the servo a coded signal. As long as the coded signal exists on the

input line, the servo will maintain the angular position of the shaft. As the coded signal

changes, the angular position of the shaft changes.

This coded signal is a pulse of varying length approximately every 20 msec. The length

of the pulse is usually 1 or 2 milliseconds depending on the desired angle.

Figure 2-3: Servo Motor Block Diagram [5] Figure 2-2: Servo Wires

15

The signal controlling a servo can be supplied by the microcontroller in two ways:

Pulse Width Modulation (PWM)

Timers

Usually, PWM generators are most commonly used due to less complexity in software

algorithms. They usually operate by generating an accurate pulse between 0% and 100%

duty cycle. But a single PWM generator would not be sufficient to control all the servos.

So the microcontroller chosen is capable of providing sufficient PWM generators in order

to control all the servos.

The control wire is used to communicate the angle. The angle is determined by the

duration of a pulse that is applied to the control wire. This is called Pulse Coded

Modulation. The servo expects to see a pulse every 20 milliseconds (.02 seconds). The

length of the pulse will determine how far the motor turns. A 1.5-millisecond pulse, for

example, will make the motor turn to the 90-degree position (often called the neutral

position). If the pulse is shorter than 1.5 ms, then the motor will turn the shaft to closer to

0 degrees. If the pulse is longer than 1.5ms, the shaft turns closer to 180 degrees.

Figure 2-4: Pulse Variation for Servo Control [6]

The control pulse is fed to a pulse width to voltage converter. This circuit charges a

capacitor at a constant rate while the pulse is high. When the pulse goes low, the charge

on the capacitor is fed to the output via a suitable buffer amplifier. This essentially

produces a voltage related to the length of the applied pulse. The circuit is tuned to

produce a useful voltage over a 1ms to 2ms period. The output voltage is buffered and so

does not decay significantly between control pulses.

A sensor, usually a potentiometer, reads the current rotational position of the output shaft,

which produces a voltage that is related to the absolute angle of the output shaft. The

position sensor then feeds its current value into the Error Amplifier, which compares the

current position with the commanded position from the pulse width to voltage converter.

In order to record the current position of the servo, all we need to do is to connect a wire

to the potentiometer to read the voltage values at all positions. These readings can be sent

to the „tracking‟ arm to move accordingly.

16

2.2.3 Torque Calculation

The approximate torque required at each joint had to be calculated initially to choose the

best servo required for the movement of the output arm. It is very important to perform

these calculations initially because if a higher torque is applied to the servo than it can

handle, it would start jittering as it keeps trying to hold the weight when it cannot.

The servos available in the

market are usually denoted in

the units „oz-in‟ or „Kg-cm‟. If

we consider a basic light servo

with 3.2 Kg-cm; it means that if

there was a horizontally oriented

weightless robot arm 1cm long

and a 3.2 Kg weight applied on

the end, the servo could keep the

arm straight. If it was a load of

3.1Kg, the servo could

accelerate the arm with 0.1 Kg-

cm. of torque. If it were a 3.3 Kg

weight, it would move

downwards with a torque of 0.1

Kg-cm, despite the servo's best

efforts. If gravity is not a factor

(ie, not lifting against gravity), it would accelerate the mass at a rate of Torque / (mass x

distance^2) rotations/second.

Gravity pulls down against any rotational arm with a torque of mass x length of arm. So,

take the torque provided by the motor, subtract the torque created by gravity, and if the

number is still greater than zero the arm will move in the direction the motor is turning.

So in our case, we will need different servos at each joint of the arm. The gripper would

need the lightest servo, only depending on the weight of the object lifted by the arm. But

when it comes to the second joint from the gripper, it should be powerful enough to carry

everything above it including the object, gripper and the weight of the material above it.

So in order to achieve this, that joint would require a stronger servo compared to the one

used at the gripper. It goes for the rest of the joints below. The base servo would have to

be the strongest in the entire arm, while the gripper has the lightest.

The torque at each arm is then calculated considering the individual forces at each joint.

Worst-case scenarios are considered for all the joints during the torque calculation to

make sure that arm would not jitter for weights below 300g. The proposed servos can be

seen in the appendix section, which were calculated accordingly with the torque

calculations.

Figure 2-5: Torque Calculation at the Joints

17

2.3 Haptic Functions

The primary objective of our robotic arm project is to introduce the haptics technology

into it to get the virtual „feel‟. The following are the haptic functions that we would want

to achieve:

Haptic sense to feel the solidity of the gripped object

Haptic sense to feel the weight of the lifted object at the elbow

There are many types of sensors available that can be used to implement the haptics

feedback required for this project. Each one of them has their own specialty and

functionality. We are to find a sensor that is to be placed on the gripper of our robotic

arm as well as a sensor that is to be placed below the arm. This sensor on the gripper shall

detect if the robotic gripper has gripped an object, while the sensor below the arm

measures the weight of the object.


The following are the requirements that need to be considered: Measures load and force with reasonable range (in lbs)

Flexible material that can be easily attached to the gripper

Rigid material that can sense various shaped objects

Reasonable price

Proximity sensors cannot be used since they detect objects at a distance. Slip sensors also

have a different functionality as it detects shear force. Furthermore, force sensors

measure force or load. So we have considered choosing force-sensing resistors (or force

sensors) to implement the haptic feedback. Force sensors can be generally classified in to

two types: hard and thin film sensors. The former (e.g. Phidgets Force Sensors) are not

suitable for robotic grippers as they are not flexible and are bigger in size. Thin film

sensors on the other hand are lighter, smaller, and flexible, although some are still only

optimized for human touch (e.g. Interlink Force Sensors). Taking into account all the

requirements for selection, the Interlink Electronics Force Sensors, which are thin film

force sensors, are best suited for our design project for gripper and weight haptics.

18

2.3.2 Force Sensing Resistors

A force sensor is basically a resistor that changes accordingly with the force applied on it.

When the force sensor has no load, its resistance is very high (>5MΩ). When a force or

load is applied, the resistance decreases. This resistance is measured by connecting an

ohmmeter to the two outer pins. This device is designed such that force is inversely

proportional to the resistance. Conversely, force is directly proportional to conductance

(1/R).

In order to test the force sensor, a table must be completed to test the precision of the

A201 Force Sensor. Resistances are to be measured with respect to various sample

forces. Conductance is then calculated from these resistance values (G=1/R). If the device

is working correctly, the plot of conductance vs. force should be linear and should show a

straight line with a positive slope as seen below.

2.4 Communication


The initial idea for communicating between both the robotic arms was to use a common

microcontroller and wire them together. But considering the applications of the project,

wireless communication would definitely be a better idea. We have considered various

ways of communicating wirelessly with the least amount of noise, as noise reduction is

one of the most important aspects in the project. Using Radio Frequency (RF)

communications between the arms for wireless control would be the cheapest available in

the market. But that was not chosen due to noise considerations. Bluetooth technology

would be the best for faster communication and also a wider range. Considering the cost

limitations, we had to choose Zigbee networking protocol. This provides both fast

communication and has reasonable cost.

Figure 2-6: Resistance vs. Force Plot [7]

19

2.4.2 Zigbee Networking

To accommodate wireless communication between the two robotic arms of our project, a

device called XBee is needed. The XBee modules use the Zigbee networking protocol

for fast peer to peer networking between the two robotic arms. It is based on the IEEE

802.15.4 standard for wireless personal area networks. The protocol is more suitable for

radio frequency (RF) applications that requires low data rate but extends battery life and

has secure networking. The serial port is used to move data from one module to the

other. Figure 1 below shows the XBee module on the right and the XBee shield on the

left. The XBee shield is essentially the XBee module‟s break out board and is used to

interface to the Arduino microcontroller.

The XBee modules are designed for high throughput applications and with low latency.

The following are the important performance/networking specifications of these modules:

Power output: 1mW (+0 dBm) North American & International version

Indoor/Urban range: Up to 100 ft (30 m)

Outdoor/RF line-of-sight range: Up to 300 ft (90 m)

RF data rate: 250 Kbps

Interface data rate: Up to 115.2 Kbps

Operating frequency: 2.4 GHz

Receiver sensitivity: -92 dB

Spread Spectrum type: DSSS (Direct Sequence Spread Spectrum) Networking

topology: Point-to-point, point-to-multipoint, & peer-to-peer

Error handling: Retries & acknowledgements

Filtration options: PAN ID, Channel, and 64-bit addresses

Channel capacity:

- XBee: 16 Channels

- XBee PRO: 12 Channels

Addressing: 65,000 network addresses available for each channel

The XBee modules can be set up to operate in a point-to-point, point-to-multipoint, or

peer-to-peer configuration. The figure below shows a point-to-point connection, which

Figure 2-7: XBee module and XBee Shield

20

will be implemented in our robotic arm project. In a point-to-point (peer-to-peer)

connection, the two modules are forced to only communicate with each other without a

Master/Slave relationship. The modules then remain synchronized and share both roles

of master and slave. Digi‟s peer-to-peer architecture features fast synchronization times

and fast cold start times.

In order for the two modules to talk to each other, they need to be configured initially.

The X-CTU software from Digi enables us to do this. The following are the parameters

that need to be considered for operation:

Channel: Must be the same value for both modules

PAN ID: Must be the same value for both modules

Destination Address High: Leave as default

Destination Address Low: Must be the same value as the 16-bit address of the

other module

My 16-bit Source Address: Must be unique on every modules

End Device: Can be set as either coordinator or end device

End Device Association: Determine the flexibility of an end device during

association

Baud Rate: The speed at which the modules will communicate and must be the

same for both modules.

The figure below shows the radiation pattern of a chip

antenna connected to an XBee module. The pattern is

normalized to the peak of the dipole antenna.

Figure 2-9: XBee Radiation Pattern

Figure 2-8: XBee Point-to-Point Configuration

21

3. Design

3.1 Robotic Arms

3.1.1 Building Materials

Building both the robotic arms was quite a

task for our team. Considering our low

experience with mechanical parts, we decided

to use pre-made parts to make our custom

shaped arm. Using a robotic arm kit that

would be readily available in the market

would be a better idea, but considering the

budget limitations and our design

considerations, the option was not considered.

The servos at each joint were chosen

appropriately taking the torque calculations

(as shown in Appendix A) in to

consideration. The maximum weight to be

lifted by the arm was approximated to be

around 300g.

The following materials were used in order to

build both the arms:

Lynxmotion Little Grip

Lynxmotion Low Profile Axis

Lynxmotion Aluminum Servo Brackets

Lynxmotion Aluminum L-Connectors

]Hitec HS-422HD Standard Servos

Hitec HS-755HB Giant Scale Servos

A few dampeners were also used while building in order to support the physical structure

of the arm. As a result, the arm turned out to be physically very stable. The current design

of the arm can be seen in the figure on the side. This arm consists of 4 Degrees of

Freedom - Vertical and circular motion of the arm, gripper rotation and gripping.

3.1.2 Position Feedback

One of the main goals of our design project was to design both the arms such that the

output arm tracks the motion of the input arm and move accordingly without any jitters in

real-time. The initial for position feedback was to use two servos at both ends at all the

Figure 3-1: Output Robotic Arm

22

joints that give the position feedback. This would ideal to upgrade the project when

motors are required at both ends. But considering the cost limitations, two different

approaches were used for the position feedback.

3.1.2.1 Position Feedback for the Gripper and the Elbow Joint

Since the motor torque was required at the gripper and elbow joints for force feedback, a

servo motor had to be used for position feedback.The input

servo would have to be modified, as shown in the figure

beside that it gives the current position to the microcontroller

that would be sent to the output servo. It can be seen from

the figure below that two additional wires are coming out

apart from the three regular wires for the servo. While one

wire is grounded internally, the other is connected to the

wiper (potentiometer) of the servo. The change in the servo‟s

shaft position would be recorded as the change in voltage at

the wiper, which will be measured by the microcontroller

that is sent to the output servo to be moved accordingly. This would be a perfect way to

measure the position feedback without removing the motor control at the input arm (for

haptic feedback).

The next step after soldering the feedback and the ground wires to the servo is to find the

maximum and minimum voltage recorded when the servo was rotated 180 degrees to 0

degrees. The voltages were recorded to be 1.86 V when the shaft position was 180

degrees and 0.34V when the shaft position was 0 degrees. This voltage would be sent to

the microcontroller as an input signal to the output servo. The max and min voltages

would be mapped accordingly using the function „map‟ in the Arduino library. When this

function is used, the microcontroller sees the range 1023 as the reference voltage, which

is 5V. This ratio was used to calculate the corresponding ranges for the min and max

voltages of the wiper, which were „70‟ and „379‟ that represent 0 degrees and 180

degrees correspondingly. These values were tested out to be accurate.

3.1.2.2 Position Feedback for the Other Joints

Considering the cost limitations, the usage of

servos for position feedback at the other joints

would not be a good choice as they are meant for

only position feedback and not any kind of motor

control. The driving gears between the motor and

the shaft for each servo would have to be cut in

case servos are used at the input arm for

feedback, making the motors useless. So the

Figure 3-2: Position Feedback for Servo

Figure 3-3: 10K Potentiometer

23

usage of potentiometers was considered, as it cuts the cost by a lot and serves the purpose

very effectively. As a result, 10K pots were used at all the other joints for the position

feedback. As shown in the figure, it consists of three pins. The first pin and the third pin

would have to be connected to the 5V power supply and ground respectively. The middle

pin is the one that gives the position feedback. The rotating knob of the potentiometer

would have to be connected to the servo brackets. This way, rotating a joint would rotate

the potentiometer instead that would give the change in voltage to the microcontroller.

This is essentially the same concept as using the servo for position feedback.

The max and min ranges were calculated similarly, which came out to be 1023 and 0 for

5V and 0V. These values were mapped and tested out to be accurate.

3.2 Haptic Functionality

The implementation of haptic functionality was the main goal of our design project. The

two haptic functionalities that were implemented in the project include sensing the

rigidity of the object held by the output gripper at the input gripper and also sensing the

weight of the object at the elbow joint of the input arm.

3.2.1 Sensing the rigidity of the object

The rigidity of the object held by the output gripper could be measured using force

sensors at the gripper as well as the output servomotor torque. The detailed description of

this implementation could be seen below.

3.2.1.1 Input Arm

This gripper consists of the modified „Lynxmotion Little Grip Kit‟ with grooves to hold

on to when manually controlling the gripper. The gripper is controlled using a Hitec HS-

422HD standard servo and a 10K potentiometer. The servo is used for the haptic

feedback received from the output arm (basically used for gripping), which is modified to

give the position feedback to the output arm.

Ideally, the driving gear would have to be removed

from the servo in order to achieve free rotation of the

shaft without any signal, as the gripper is controlled

manually. But removing the driving gear will not

produce the haptic feedback from the output arm. As a

result, a very low torque servo has been chosen that

can be moved „almost freely‟ at no signal with the

driving gear intact.

Driving Gear

Figure 3-4: Driving Gear of the Servo [8]

24

The gripper haptics was implemented using two designs. The desired implementation

would be selected by the user. The first logic was implemented using the servo torque as

discussed in the weight haptics section (Section 3.2.2). Using this logic, the user would

have to apply force on the gripper in order to keep holding the object. This logic was

implemented in order to let the user experience real-world logic, where one would have

to keep applying an inward force to hold the object. Depending on the user‟s comfort, a

second logic was implemented that could be selected by a switch that is placed on the

base of the robotic arm. Using this logic, the inward motion of the input arm gripper

would be blocked once an object is held and a threshold force is reached at the output

arm gripper. This logic would enable the user to feel the rigidity of the object without

actually applying continuous inward force to hold the object. In order to enable the free

motion of the input arm gripper for the user when no object is being held at the output

end, the input servo would have to be detached. This was due to the fact that the servo

shaft could not be moved against its torque when it is holding its position. Once the

output arm holds an object, a feedback voltage would be sent through the PWM pin of

the microcontroller to the input servo. As the signal is received at the input arm as soon

as the output arm held the object, the position of the input gripper would freeze

approximately at the same position as the output gripper. In order to improve the

accuracy of the system, the position feedback of the output gripper when holding an

object would be sent to the input arm gripper in order to stop at the same position. The

problem arises when the user tries to let go the gripper, as the gripper servo would be

frozen when the output gripper holds an object. In order to solve this problem, a switch

was introduced in our design. This switch would be placed in a position that the user

would always press it while trying to let go of the gripper. Once the switch gets pressed,

it would detach the input gripper servo again to enable free motion once again. But once

the output gripper detects an object, the input servo would again be frozen at a

corresponding position.

Applying either of the above logics, the input gripper would react accordingly depending

on the rigidity of the object at the output end.

3.2.1.2 Output Arm

This gripper consists of the original „Lynxmotion Little Grip Kit‟ with 2 Hitec HS-

422HD standard servos and a 0.2” Circular Force Sensor. The servos are used for

gripping and rotational movements of the gripper.

The force sensor that will be placed on the gripper will be providing the force feedback to

the input arm to produce the haptic effect. This detects the amount of force applied on the

gripper, which is indirectly the change in resistance again. This produces a change in

voltage as the force is exerted on the gripper. When the output gripper meets an obstacle

(like an object to pick up), then the servo board needs to apply more voltage in order to

achieve that position. This voltage would be produced internally. As a result of this, the

torque applied by the output gripper is measured more directly. So, the force measured by

the force sensing resistor increases in contact with the target as the output gripper‟s motor

torque increases.

25

3.2.2 Sensing the weight of the object

The weight of the object being lifted could be calculated by placing a force-sensing

resistor between the joints of the base and elbow to record the weight applied by the

object. This feedback would be „felt‟ at the elbow joint of the input arm using the servo

torque. The detailed description of this implementation could be seen below.

3.2.2.1 Input Arm

The elbow joint at the input end consists of a Hitec

HS422HD standard servo. This servo was modified in

various ways in order achieve the required objectives.

A wire was soldered on to the potentiometer of the

servo in order to give position feedback. Instead of

using the regular servo signal wires, a couple of wires

are soldered directly on to the motor contacts. This

could be seen in the figure below. Any kind of

movement in the input arm would cause a change in

voltage in the internal potentiometer of the servo. This

voltage would be recorded and sent to the Arduino to

control the output arm. The servo that is connected to

the elbow joint will be used to produce the haptic effect. According to the corresponding

force recorded at the output arm, a certain voltage will be applied to the servo‟s motor

directly through the contacts. A small amount of force at the output would apply a low

voltage on the servo‟s motor and hence a low torque applied by the motor in the opposite

direction. A heavier object on the output arm would produce a high opposing torque at

the input arm. So the user would have to push it hard in order control the arm.

Applying the above logic, the weight of the object could be felt at the elbow joint of the

input arm. The heavier the object at the output end, the larger will be the force felt at the

input end.

3.2.2.2 Output Arm

The elbow joint at the output end consists of a Hitec HS-755HB giant scale servo for the

arm movements according to the position received from the input arm.

A 0.3” force sensor would be placed in between the joints of the base and elbow. This

force is then calculated with no load and will act as the threshold voltage. So any external

force acting on the arm (when a certain object is lifted) would cause an additional force

on the force sensor, which is then measured and sent to the Arduino. This measured force

is transferred to the servo‟s motor at the elbow joint of the input arm to exert a force in

the opposite direction.

Figure 3-5: Wires to motor contacts + position feedback

26

3.3 Communication The design of our robotic arm project has been updated

to accommodate wireless communications between

them. Both arms then must track each other

wirelessly. We considered taking the Zigbee protocol

route for our project. In particular, two XBee Shields

and two XBee modules were used for radio

communications. Each robotic arm should then be

connected to its own Arduino microcontroller, XBee

shield, and XBee module.

This set-up offers considerable advantages to our

project. The primary advantage is that the XBee

modules are bi-directional. Each module can be used

to transmit and to receive signals. The second advantage is that we can assign a unique

address to each of the XBee modules since each unit has a unique serial number. Two of

them can be set up exclusively to talk with each other and ignore all other possible causes

of interference. The third advantage is that the XBee module has a built in data packet

and error checking protocols to facilitate on multiple data transmissions. Lastly, these

XBee devices are completely compatible with our own Arduino microcontrollers for they

were purposely designed as such. The figure above shows how the three parts (Arduino

MCU, XBee shield, and XBee module) are conveniently connected with each other.

3.3.1 Configuration

One of the main goals of this project was to enable the wireless control. As discussed in

the design section above the wireless control of the entire project was successfully

implemented. Initially, the XBee modules had to be configured so that they can talk and

communicate with each other. The first and the second XBees will communicate

exclusively while the third and the fourth XBees also communicate exclusively. There

are different types of protocol that the XBee modules can function upon. We decided to

configure the XBees into using the Peer-to-Peer networking protocol. The P2P

networking protocol enables each of the relevant modules to become both master and

slave. This protocol serves our project best since we only have two nodes (Two robotic

arms) with equal priority. There is no need to have a server and a client relationship.

The X-CTU software was used to update the firmware and configure the parameters of

the XBee modules to enable P2P networking protocol. The figures below show the

interface of the X-CTU software and the parameters for a pair of XBee modules. The

figure on the left contains the firmware and parameters of the first module. To the right

is the second module. This pair of XBee modules is in charge for the movements of the

robotic arm servos.

Figure 3-6: Zibgee Modules on Arduino [9]

27

Figure 3-7: XBee parameters

Below are the exact configurations that are being used in our project.

First module parameters:

• Channel - Set to “C”

• PAN ID - Set to

“3332”

• Destination Address High - Set to “0”

• Destination Address Low - Set to “2”

• My 16-bit Source Address - Set to “1”

• End Device - Set to “0”

• End Device Association - Set to “0”

• Baud Rate - Set to “3”

Second module parameters:

• Channel - Set to “C”

• PAN ID - Set to

“3332”







Below are the parameters of the third and fourth XBee modules. This second pair of

XBee modules is in charge with the haptics feedback signal transmission.

Third module parameters:

• Channel - Set to “D”

• PAN ID - Set to

“3333”







Fourth module parameters:

• Channel - Set to “D”

• PAN ID - Set to

“3333”







28

The overall design for wireless communication between the arms could be seen below.

Figure 3-8: Block Diagram for Wireless Communication

As seen in the block diagram above, the first XBee module is in charge of sending

potentiometer readings from the input arm to the receiving second XBee module on the

output arm. This pair is responsible for wireless robotic arm movements. Consequently,

the fourth XBee module is in charge of sending gripper force sensor readings, weight

force sensor readings, and gripper position feedback readings from the output arm to the

receiving third XBee module on the input arm. This pair is responsible for wireless

haptic functionality.

3.3.2 Hardware Set-up

There are several connections necessary for enabling

XBee wireless communication between the two

robotic arms. These hardware connections need to

be done after configuring the XBee modules and not

prior. This is to decrease the troubleshooting

difficulties. The XBee modules then need to be

connected to the XBee shields. These modules were

factory designed so that it can be plugged directly on

to the shield with no additional connections and

soldering necessary. The XBee shield in turn connects to the Arduino MCU. The TX and

RX pins of the Arduino MCU and the XBee shield must be in line with each other as well

as the ICSP pins. This procedure is also plug-and-play. A combination of the XBee

module, XBee shield, and Arduino MCU is considered as a single set. Our project needs

Figure 3-9: XBee shield jumper

29

four sets. Two sets are considered as the

senders and the other two sets are considered

to be the receivers. The sender set contains the

user interface devices (Potentiometers or Force

Sensors) while the receiver side contains the

output devices (such as Servos). The XBee

shield has jumpers that need to be relocated

each time a sketch is uploaded and when

wireless communications are enabled. Moving

the jumper to the XBEE position will enable

wireless communications as shown in the figure.

While moving the jumper to the USB position

will allow the user to upload a sketch in to the Arduino MCU. Otherwise, all wireless

communications will be kept disabled and the sketch will not be uploaded.

The hardware connections between the XBee module, XBee shield and the Arduino

MCU could be seen in the figure.

3.4 Power Supply

Efficient power supply is the cornerstone to the success of our robotic project. It provides

the power source to all the servomotors and sensors. Just using battery will not do the job.

In fact, there are some rules that need to be taken under consideration before making

continuing. We need a circuit that regulates the desired voltage, supply the required

amount power at all times, and allow for additional special requirements of particular

application [10]

.

3.4.1 Power Regulation

The power regulation circuit has the following additional features:

Short circuit protection

Regeneration

Negative voltages

Noise protection

Considering the cost

limitations, a computer power

supply would the cheapest and

the most reliable type of power

source. This power supply

consists of a 12V rail that could

provide 120W of power and a

Figure 3-11: Power Regulation Circuit

Figure 3-10: Hardware connections of XBee, XBee shield and Arduino

30

5V rail that could provide 150W of power. This amount of power would be more than

required for an efficient power supply for our project. But in order to use this unit, further

changes had to be made.

The following components were required

for the changes:

DC Toggle Switch

LED + Resistor: 10 Ohms, 10W

Power Resistor: 330 Ohms

Binding Posts

Banana Plugs

Heat Shrink Tubing

The transformed power supply could be

seen in the figure below.

In order to convert PSU to our power supply, we need to first identify which wires are 5

V, 12 V, and GND, etc. The 5 V rail can be used as it is since it already regulated to 5 V.

In addition to that we proposed an additional fuse, on/off switch, LED, and a capacitor to

take out any transients. The 5 V supply will provide power to MCU and sensors. On the

other hand, the 12 V rail need to be regulated to around 6~6.5 V to provide power to

servos. Its schematic is identical to 5 V except it has an additional switching regulator.

The switching regulator is similar to regular voltage regulator but it is much more

efficient. A regular voltage regulator may burn and melt due to overwhelming power

requirement. This is where switching regulator comes.

Before choosing the switching regulator, we found the total power consumed in worst

case and it was about 93 Watts for all the motors and sensors. We used a 3 Amp

Adjustable Switching Regulator from Dimension Engineering (model DE-SWADJ3). It

should be ideal for our application as it provides maximum of 25 Watts and an adjustable

output voltage from 3 to 13 V. Using this switching regulator with four 12 V rails should

provide ample power to the servos.

Figure 3-12: Transformed Power Supply

31

3.5 Software

3.5.1 Position Feedback

The algorithm for getting the position feedback of the joints was not very complicated.

This is due to the built in libraries of the Arduino, which were really helpful in terms of

programming. The function „analogRead ()‟ reads the analog input from the input arm

that was mapped using the „map ()‟ function. Mapping the values had to be done

carefully, as we had to make sure that the joints in the output arm move to the exact same

position as the input arm. The syntax for the „map ()‟ function could be seen below.

map (value, fromLow, fromHigh, toLow, toHigh)

This function maps the values read from the analog input to an output that is understood

by the microcontroller for digital output. As the potentiometer was given a 5V input, it is

obvious that the voltage varies from 0V to 5V. As the Arduino MCU takes a 10-bit

analog input, the reference range for microcontroller was noted to be 0 to 1023. This

reference voltage then had to be mapped to the corresponding voltage values of the

digital input. The digital input our case was the angle of the servo shaft, which was 0 to

179 degrees. This mapping had to be done differently when the position feedback was

received from a servo. It was noticed that the voltage of the internal potentiometer does

not vary between 0V and 5V. After measuring the voltage of the servo‟s internal

potentiometer, it was observed to be 0.33V at 0 deg and 1.82V at 180 deg. So the values

were mapped from the range of 69 to 373 for the joints that used servo for position

feedback.

3.5.2 Gripper Haptics

While the similar logic for position feedback was applied for gripping the object, the

algorithm had to be extended to implement the gripper haptics. The force sensor reading

was read by the MCU‟s analog port again using the „analogRead ()‟ function. A certain

threshold was set for the force sensor so that it detects the objects only when the gripper

reaches a proper gripping position. This voltage change caused by the FSR was read as

the analog input to the MCU. Along with this signal, the position feedback of the output

servo gripper was also recorded and sent to the MCU. Both these signal were then used in

order to produce the required feedback on the input arm. The algorithm was designed in

such a way that the servomotor on the input arm is detached until the force sensor reads a

signal higher than the preset threshold value. Once the signal is sent to the input gripper,

the position feedback from the output gripper was used to hold the gripper at the exact

same position.

The above algorithm was working fine to hold the motion of the input arm when the

output arm at the same position is holding an object. But the problem aroused when the

user tried to let go the object. As the input servo is frozen and it has to be controlled

manually, it would not be possible to move the servo manually anymore. We then came

to a conclusion that some sort of an indication has to be sent manually to the MCU to

32

detach the servo when the user wants to let go the object. As a result, a switch was placed

on the input gripper that would be pressed automatically when the user wants to let go of

the gripper. This switch was used as an interrupt to let the MCU detach the input servo.

Therefore, the algorithm worked fine and it could obstruct the user from closing in on the

gripper anymore and would let the user let go of the gripper whenever desired.

3.5.3 Weight Haptics

Implementing this part of the project was a very challenging goal. We came up with a

design, where the MCU should control the servo‟s internal motor directly. We tried

implementing this using the „analogWrite ()‟, but we were unable to produce the required

voltage to generate a strong torque through the MCU using this logic. This was due to the

limited voltage required by the servo to rotate the servo as discussed in the previous

sections of the report (0.33V and 1.82V). As a result, the maximum value „analogWrite

()‟ function, 255 could map only up to 1.82V. In order to produce the required torque, we

require around 3.5V to be sent to servo‟s motor directly from the MCU for heavy

weights. As a result, we decided to control the servo‟s internal motor similar to a DC

motor, where the speed and direction could be controlled directly corresponding to the

voltage sent from the MCU.

DC motor control from the Arduino would be a bit more complicated than compared to a

servo. In order to do this, we would have to build a H-Bridge circuit to control the

motors. A motor driver chip was purchased and attached to the Arduino that could

control at least two DC motors. Therefore, a small algorithm was written in order to

enable the H-Bridge pins on the chip. The original algorithm was then modified in such a

way that the MCU would produce a corresponding voltage to the servo‟s motor based on

the FSR reading.

Therefore, this algorithm worked fine, as it produced a high torque on the joint when the

output arm tried to lift a heavy object and a low torque on the joint when the output arm

tried to lift a lighter object. This lets the user feel the weight of the object being lifted by

the output arm on the input arm.

3.5.4 Wireless communication

The algorithm for implementing the wireless communication in our project was slightly

complicated. In order to do this, four codes were programmed for testing wireless

communication. As a starter, a simple program was made to wirelessly change the

brightness of a remote LED using a potentiometer (setup seen on figure A). The second

testing code was programmed to control a single servo‟s movements wirelessly (setup

seen on figure B). The third testing code was programmed to implement two way

communications between both XBee modules. One potentiometer and one servo were

attached to each of the two sets of XBee-Arduino set. This code made the XBee modules

function as both sender and receiver at the same time (setup seen on figure C). The last

33

testing code was made to control a servo wirelessly using a force sensor (setup seen on

figure D). The force sensor is similar to a potentiometer which outputs resistance values.

The testing codes were not merely used for testing but also used for the entirety of our

project. These codes were designed to be similar to the final code. All four testing codes

were successfully compiled, uploaded, and put in to action.

Our project contains four final separate codes, two codes for each robotic arm. A detailed

explanation of the functions of each of the four codes could be seen below:

Robotic Arm Send: This code reads the potentiometer values located on the user-

side robotic arm and sends them to the serial port.

Robotic Arm Receive: This code receives the signals sent by the input robotic arm

and designates them to the proper designated servo on the output robotic arm.

Haptics Send: This code reads the gripper force sensor values and the gripper

position feedback of the output robotic arm and sends it to the serial port.

Haptics Receive: This code receives the signals sent by the output arm. It is also

responsible of the haptic algorithms to be implemented on the input robotic arm.

Figure 3-16: ‘C’ Wireless Test of a Servo from a Potentiometer

Figure 3-15: ‘D’ Wireless Test of a Servo from a FSR

Figure 3-13: ‘A’ Wireless Test for a LED Figure 3-14: ‘B’ Wireless Test of a Servo

34

The Arduino Duemilanove only has one serial port but our project needs nine signals to

be transmitted. We needed to make use of the single serial port of the Arduino

Duemilanove to accommodate multiple signal transmissions. In this case, there must be

an algorithm to solve this issue. The increasing number of input and output values needs

to be taken into account for each robotic arm. These data need to be passed to the other

arm and vice versa. Every single data that is being sent must be assigned into its proper

designated receiver. If not done properly, data may be lost, misused, or sent to the wrong

receiver. The following is the explanation on how the algorithm of sending and receiving

multiple data works. As an example, the string given below contains two important parts:

first is an integer and second is the data that is being sent. This string is what is written

into the serial port by the sender which is passed on to the receiver. Essentially this is

how the movements of the output robotic arm is controlled wirelessly using the

potentiometers on the input arm.

Note: The example below uses integers to further simplify the explanation. The actual

project uses bytes to send and receive data.

“1”servo1”2”servo2”3”servo3”4”servo4”5”servo5”6”servo6

where, „#‟ is the servo label

servo# is the value from potentiometer reading

The algorithm works this way, when the receiver detects an integer number “1”

(excluding quotation marks), the next value to the right, which is data1 would be assigned

to the first servo. Consequently, “2” is for the second servo, “3” for the third, and etc.

Likewise, the algorithm for sending force sensor values and gripper position feedback

from the output arm to the input arm is shown below.

“1”gripper_fsr”2”weight_fsr”3”gripper_pos”

where, “#” is the label

gripper_fsr is the sensor reading from gripper FSR

weight_fsr is the sensor reading from weight FSR

gripper_pos is the output gripper position reading

Figure 3-17: ‘E’ Wireless Test of the Robotic Arms

35

4. Performance and Results

4.1 Evaluation of Theoretical System Performance:

In order to perform in real time, the system must be fast enough for this particular

application and use little as little memory as possible (which also affects the speed of

operation). Allowing some headroom for additional sensors is also essential, since

improvements to the system may call for the additions.

4.1.1 Evaluation of Theoretical System Speed

In order for haptics feedback to be implemented, a processing speed of at least 1MHz is

required; therefore, processing time is very important in our case. The Arduino Mega

board employs ATmega1280 microcontroller operates on a 16 MHz processor rated at 16

million instructions per second [4]

. If the sensors and potentiometer computations are

implemented in an efficient manner, these computations should take a very short time.

This means that actual rate of computation will be limited by rate of wireless

transmission/receiving of servo positions and sensors values. The wireless module,

Arduino XBee Shield, is capable of operating at 2.4 GHz frequency, however, the

distance separation of two XBee modules plays roll in the rate of transmission as well.

We have at least two force sensors, six potentiometers, and two servo potentiometers,

which are inputs to analog to digital (ADC) pins of the microcontroller board. There are

16 ADC channels; therefore we have additional six channels left for sampling.

4.2 Evaluation of the Position Feedback Nature of the Robotic Arms

One of the most important goals of our

project is to control the motion of the

output arm using the input arm that

provides the required haptic feedback.

In order to improve the accuracy of the

tracking, the construction robotic arms

were divided in to various parts. The

first step was to build the output arm

that could be controlled by

potentiometers that are connected

through the breadboard. The next step

after cancelling out all the noise in the

system was to build the output arm

where each joint was tested

individually.

Figure 4-1: Output Arm controlled by Potentiometers on a breadboard

36

The testing procedures for the main joints that support the arm could be seen in the

pictures below.

It could be seen in the figures above that the corresponding joint of the output arm is

positioned at the same place as the one of the input arm. Similarly the position feedback

nature was implemented to other parts of the arms – base rotation, wrist rotation and

gripping.

Figure 4-2: Position Feedback Nature of the Base Joint

Figure 4-3: Position Feedback Nature of the Elbow Joint

Figure 4-4: Position Feedback Nature of the Wrist Joint

37

4.3 Noise Reduction

The above methods were tested out successfully and were proved to be very accurate in

terms of position feedback. But noise was a huge issue as a lot of jittering was observed

when controlling the servos. It was noticed that the jittering was at its peak when the

shaft was nearing 180 degrees when compared to the shaft position at 0 degrees. This was

sort of taken care with the mechanical structure of the arm. Since we do not desire 180-

degree rotation of the joints, the joints were built in such a way that the servo would have

to rotate only to a max of 160 degrees. This reduced a lot of noise comparatively. But a

minute jitter in the servos was still noticed, which became more evident when attached to

the arm. This was a challenge to us to figure out the exact origin of the noise in the

system. Initially, we tried to eliminate the noise using 0.1F capacitors across the power

supply and across the analog input signal to cancel out the noise, which did not solve the

problem. We then tried to replace the capacitors with a larger capacitor that should

definitely cancel out all the noise harmonics even though it would make the whole system

slow. But unfortunately that was not the case. Finally after observing the waveforms of

the power supply harmonics in the harmonics, we came to a conclusion that it was not the

power supply that was causing the noise. The next step was to test the wires that were

used to connect the circuit to the breadboard. As the wires are basically similar to RF

communication, it was important to make sure that the RF noise was filtered. The wires

were then wrapped around with aluminum foil that was grounded, as that should cancel

out all the noise frequencies in the wires. After this being done, the noise in the system

reduced by a bit but it was still pretty evident. Therefore, we were left with only the

servos and potentiometers that could be causing noise in the system. After checking the

waveforms of all the servos in the oscilloscope, we came to a conclusion that

potentiometers were the ones that were causing noise in the system. As a result, using

better performance potentiometers for feedback solved majority of the problem. The tiny

bit of noise that still persisted was eliminated when the circuit was soldered on a printed

circuit board. Therefore, the noise was successfully out of the system.

4.4 Physical Structure of the Robotic Arms

It was very important in our project to make sure that the

robotic arms built have perfect stability in terms of the

physical structure. The servo brackets that were used to

build the arm were designed in such a way that the

servomotor is attached to one end of the bracket but the

other end was left loose. This caused the arm to be slightly

unstable in terms of physical structure as all the weight was

falling on the side without any support. So we had to make

sure that the other side of the bracket was supported without damaging the motion of the

arm. It could be seen in the figure below that a pivot kind of mechanism was designed on

the other side of the bracket to support the entire arm. This ensured that the output arm

was stable and the weight was proportionally distributed across the arm.

Figure 4-5: Pivot Structure to support the Output Arm

38

4.5 Haptic Functionality

4.5.1 Rigidity Sensing

Sensing the rigidity of the object was one of the simple

haptic functions to be implemented in the project. This was

successfully implemented as discussed in the design part of

the report. The force-sensing resistor was attached to the

gripper as shown in the figure to sense the force exerted by

the object held by the gripper. This sends a signal to the

microcontroller that an object is being held when the force

sensor reading crosses a preset threshold. The input gripper

holds its position corresponding to the output gripper

position. This logic was successfully implemented for solid

objects. But this design was not at its best for objects with

less rigidity. This was due the fact that the feedback was not

sent as a torque but rather as a PWM signal to the servo. The design using servo torque

that is similar to the design for weight haptics was not chosen due to the fact that

applying a torque on the servo would push the servo in the opposite direction. This would

force the user to let go the gripper and it might damage the object if the gripper slipped

from the user‟s hand. As a result, a safer method for rigidity sensing was chosen that

works great on solid objects.

4.5.2 Weight Sensing

Figure 4-6: Output Arm Gripper with FSR

Figure 4-7: Output Arm with FSR

Springs for Balance

Weight Sensing

39

Sensing the weight of the object was the other haptic function to be implemented in the

project. This function was also successfully implemented as discussed in the design part

of the report. As shown in the figure, the force-sensing resistor was placed below the

whole arm. It was very critical to choose a right placement for the force sensor for this

application as the force sensor should easily be able to detect the additional weight acting

on the arm. After experimenting at various joints of the arm, it was finalized that the FSR

would be placed below the arm as shown in the figure for a better accuracy. The corners

of the base was supported by springs in order to let the whole weight of the arm fall on

the force sensor. The force acting on the arm with no load was initially noted and used as

the threshold value for the FSR. This weight was then converted to its corresponding

torque on the servo of the input arm. This was tested with three different weights. The

lightest object felt almost nothing. There was a noticeable difference when a bit heavier

object was being lifted. The servo produced a medium torque in this case that was

opposing the user‟s motion. The servo produced very high torque when tried with a

heavy object. In reality, the object being lifted might not be as heavy as the torque that is

being produced. As the motors being used are not capable of producing a very high

torque to lift heavy objects, it was necessary to map the objects in three weight ranges –

low, medium and high in order to demonstrate the weight haptics. Another main reason

for this was the inaccuracy of the force sensors. As the accuracy level for the force

sensors was very poor, a wide range of values were chosen to be mapped accordingly.

4.6 Wireless Communication

4.6.1 Performance Requirements

The performance of wireless technology using Zigbee can be measured by using the

following criteria:

Lag: Lag is the difference between the time a user enters a command and the time a

device responds. With regards to our project, lag is measured by determining the

elapsed time when the input robotic arm is moved and when the output robotic arm

responds to the commands. Since our project uses wireless technology, there is a

possibility that lags would be present.

Range: The XBee modules have a limited range. The distance between our two

robotic arms must be well under the maximum allowable range.

External interference: External interference may be due to other wireless routers or

modems that are currently running in the proximity of the XBee modules. Indeed,

this may cause external interferences and noise. Most especially if there are other

functioning XBee modules aside from our project. To avoid any interference, there

are several steps that need to be followed. Essentially, the XBee modules need to be

configured properly and uniquely.

Internal interference: Aside from external interferences, there may also be internal

interferences that may hinder proper data transmission. Since our project involves

multiple data being sent and received simultaneously, there is a possibility that a

40

single data interferes with another and gets received by the wrong receiver. To deal

with this issue, a data packet algorithm is being implemented.

4.6.2 Analysis of Performance

Lag: After thorough testing of the wireless communication in our project, some

minor lags were noticed from time to time. Even so, the lag times are very menial and

do not in any way hinder the usability of our project.

Range: The XBee range was found to be sufficient enough to be used on our project.

After all, our two robotic arms situated right next to each other, so the XBees are

more than enough to tackle the range issue. Also, since our robots are situated well

under the maximum range of the XBee modules, there is no need to worry about data

losses.

External interference: There were no interference from other routers, modems, and

XBee modules from other projects. Data were not lost or being corrupted by noise.

Internal interference: There were no internal interferences within our robotic arms.

Our algorithm in sending data worked really well and indeed it eliminated the

possibility of any internal interference on our robotic arms. Data were not lost or

being corrupted by noise.

41

5. Conclusion

This project has been successful in terms of implementing the required objectives, but it

was moderately successful in terms of accuracy. We have demonstrated that it is possible

to implement the idea of telepresence mixed with the haptics technology. But the

performance of our designs could be improved in so many ways depending on the

application being used. Our future considerations would be ease-of-use. One of the

objectives of our project was to design the input arm similar to the output arm. If this

wasn‟t the case, a much simpler design could be implemented for the input arm that is

easier to control. Ideally, this project could be extended to using some sort of a glove as

the input arm to control the output arm. Various attempts were made to eliminate the

noise in the system as that was one of our biggest concerns. Therefore, most of the noise

was eliminated after various experiments in order to get rid of it. However, a minute bit

of jitter still existed in system, which was not solved. As it is very important that these

kinds of systems have to be noise-free, this would be a big consideration for the future

projects. The haptics part of the project was successfully implemented but smoothening

those functions would be another future consideration. Due to budget limitations, the

force sensor chosen had very low accuracy. As a result, wide range of weights had to be

chosen in order to demonstrate the weight haptics. Another improvement that could be

made to the system was to implement the gripper haptics using the servo torque design

rather than the switch mechanism. We were unable to perform this due to time

limitations. However, this project was successful in terms of implementing all its

objectives within the time frame provided to us.

42

6. Bibliography

1. Brewster, S.A., Murray-Smith, R.: First International Workshop on Haptic Human-

Computer Interaction. In: Brewster, S.A., Murray-Smith,R. (eds) Haptic HCI 2000.

LNCS, vol. 2058, Springer, Heiderlberg (2001)

2. Mclaughlin, M., EspanhaM, J.: Touch in Virtual Environments. Haptics and the

Design of Interactive Systems. Prentice Hall, Englewood Cliffs (2001)

3. (El Saddik, “The Potential of Haptics Technologies,” Instrumentation &

Measurement Magazine, IEEE, vol.10, no.1, pp.10-17, Feb. 2007).

4. (2009), Microchip. Retrieved from

http://www.micrchip.com

5. (3 September, 2006), Digital Nemesis, Retrieved from

http://www.digitalnemesis.com/info/docs/rcservo/

6. Seattle Robotics. Retrieved from

http://www.seattlerobotics.org/guide/servos.html

7. Tekscan. Retrieved from

http://www.tekscan.com/flexiforce/flexiforce.html

8. Kevin Ross: Hacking a Servo by Kevin Ross

http://www.junun.org/MarkIII/Manual/kevin/servohack.html

9. Libelium. Retrieved from

http://www.libelium.com/tienda/catalog/product_info.php?cPath=22&products_id=34

10. Society of Robots. Retrieved from

http://www.societyofrobots.com/schematics_powerregulation.shtml

http://www.micrchip.com/

http://www.digitalnemesis.com/info/docs/rcservo/

http://www.seattlerobotics.org/guide/servos.html

http://www.tekscan.com/flexiforce/flexiforce.html

http://www.junun.org/MarkIII/Manual/kevin/servohack.html

http://www.libelium.com/tienda/catalog/product_info.php?cPath=22&products_id=34

http://www.societyofrobots.com/schematics_powerregulation.shtml

edp final report updated vipul

Documents