Report on the Strength of materials i lab

FINAL REPORT ON THE DEVELOPMENT OF STRENGTH
OF MATERIALS REMOTE LABORATORY: A NON-EE/CS
iLAB FOR STATIC BENDING TEST

BY

ISHOLA, BABATUNDE ISAAC
(EEG/2006/064)

SUBMITTED TO

DEPARTMENT OF
ELECTRONIC AND ELECTRICAL ENGINEERING
OBAFEMI AWOLOWO UNIVERSITY
ILE – IFE

IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE
AWARD OF BACHELOR OF SCIENCE DEGREE
ELECTRONIC AND ELECTRICAL ENGINEERING

JANUARY, 2012.

Department of Electronic & Electrical
Engineering,
Faculty of Technology,
Obafemi Awolowo University,
Ile-Ife.
Osun State.
22th January, 2012.

The Coordinator,
EEE 502: Final Year Project,
Department of Electronic & Electrical Engineering,
Ile-Ife.
Osun State.

Dear Sir,
LETTER OF TRANSMITTAL
Kindly accept the accompanying copy of project proposal of my final year project titled
“Development of Strength of Materials Remote Laboratory: A Non-EE/CS iLab for Static
Bending test”. This was undertaken in partial fulfillment of the requirements for the award
of a Bachelor of Science Degree from the Department of Electronic and Electrical
Engineering, Obafemi Awolowo University.

Thank you.

Yours Sincerely,

ISHOLA Babatunde
I.
EEG/2006/064

CERTIFICATION

This is to certify that this report was prepared by ISHOLABabatunde Isaac (EEG/2006/064) in
accordance with the requirements stipulated for the execution of a final year project as a
fulfilment of the requirements for an award of Bachelor of Science (B.Sc) degree in Electronic and
Electrical Engineering.

…………………………………
Dr. K.P. Ayodele
(Project Supervisor)

DEDICATIOIN

“But there is a spirit in man: and the inspiration of the Almighty giveth them understanding.”

-Job 32:8 (Holy Bible KJV)

ACKNOWLEDGEMENT

“Blessed be the Lord my strength, which teacheth my hands to war, and my fingers to fight:”-
Ps.144:1

I recognize my source of strength and intellect – My Lord and Savior Jesus Christ

I am especially grateful to my supervisor, Mr.AyodeleK.P. for his ready help and continual
contributions

To all the members of the iLab-Project team and all G12 members, I can but express meager thanks.

To all my friends without whom I would be a total stranger in this world, I say thank you for being
there.

Words can describe my gratitude to all members of my family: my mother and brothers. I couldn’t
have wished for a better company.

ABSTRACT

This project report introduces the concept of remote virtual laboratories, discusses the
various implementations of remote laboratories with emphasis on MIT’s iLab Framework, its
architecture and unique design which makes it the choice for implementation of Strength of
Materials lab. Contained in this chapter also is a brief discussion on the static bending test
experiment, the pedagogics of the experiment, how it is performed traditionally and with
virtual instrumentation. Equipment and machines used in testing the strength of materials
for experimentation and industrial application would also be considered here.

The main goal of the project is to develop a remote online laboratory called the Strength of
Materials laboratory, a platform for performing static bending test over the internet. The
experiment is for determining the properties, such as the Young Modulus of beam.The design
process, components, devices and equipment needed to build the Static bending test
machine is described in this report. Described also is the use of sensors, actuators, software
components and programming platform used in achieving the design goal.

Major challenges faced ranging from remote application of load to getting the right sensor
to read the deflection of the beam, proposed solution; the design of the automated system
for performing the beam deflection experiment, control flow/block diagram, work done so
far; circuit already constructed, programs already written, challenges encountered during
development are all discussed in this report.

TABLE OF CONTENT
LETTER OF TRANSMITTER…………………………………………………………………………………………………………………..II

CERTIFICATION………………………………………………………………………………………………………………………………….III

DEDICATION……………………………………………………………………………………………………………………………………...I
V

ACKNOWLEDGEMENT…….……………………………………………………………………………………………………………….…
V

ABSTARCT……………………………………………………………………………………………………………………………………….…V
I

TABLE OF
CONTENT………………………………………………………………………………………………………………………….VII

LIST OF
FIGURES………………………………………………………………………………………………………………………………..IX

CHAPTER ONE ....................................................................................................................................... 11
INTRODUCTION ..................................................................................................................................... 11
1.1. BACKGROUND ....................................................................................................................... 11
1.2. SCOPE .................................................................................................................................... 12
1.3. OBJECTIVES ........................................................................................................................... 13
1.4. JUSTIFICATION....................................................................................................................... 13
CHAPTER TWO ...................................................................................................................................... 16
LITERATURE REVIEW ............................................................................................................................. 16
2.1. STATIC BENDING TEST ........................................................................................................... 16
2.1.1. BASIC THEORY ............................................................................................................... 16
2.1.2. EXPERIMENT PEDAGOGICS ........................................................................................... 18
2.2. STRENGTH OF MATERIALS LABORATORIES, EQUIPMENT AND MACHINES .......................... 19
2.3. REMOTE VIRTUAL LABORATORIES ........................................................................................ 23
2.3.1. ILABS-PLATFORM FOR REMOTE EXPERIMENTATION.................................................... 23
2.3.2. THE iLAB SHARED ARCHITECTURE................................................................................. 24
CHAPTER THREE .................................................................................................................................... 28
METHODOLOGY .................................................................................................................................... 28
3.1. RESTATING THE TASK AHEAD................................................................................................ 28
3.2. KEY ISSUES ............................................................................................................................. 29
3.3. PROPOSED SOLUTION/DESIGN ............................................................................................. 30
3.3.1. LINEAR ACTUATOR-LOAD APPLICATION ....................................................................... 30
3.3.2. LOAD SENSOR – FORCE MEASUREMENT ...................................................................... 32
3.3.3 POTENTIOMETER – DEFLECTION MEASUREMENT ........................................................ 35

3.3.4 BEAM REPLACEMENT .................................................................................................... 36
3.4. WORK DONE – PHASE 1 ........................................................................................................ 38
3.4.1 PHASE 1 - THE MICROCONTROLLER UNIT ..................................................................... 38
3.4.2. PHASE 1 - LOAD SENSING .............................................................................................. 46
3.4.3. PHASE 1 - THE ROBOTIC ARM ....................................................................................... 48
3.4.4 PHASE 1 - AUTOMATED RACK AND CHASSIS DESIGN ................................................... 58
3.5. Challenges and Solution ........................................................................................................ 60
3.5.1. POWER ISSUES .............................................................................................................. 60
3.5.2. READING FROM SENSOR ............................................................................................... 60
3.5.3. CONTROLLING COUPLED DYNAMIXEL........................................................................... 60
3.6. PHASE 2 - REDESIGNING ....................................................................................................... 61
3.6.1 PHASE 2 - USE OF NI DAQ AND LABVIEW...................................................................... 61
3.6.2 PHASE 2 - ROBOTIC ARM CONTROL .............................................................................. 62
3.6.3 PHASE 2 - RACK AND CHASSIS DESIGN .......................................................................... 65
3.6.4. DETERMING WHEN THE BEAM REACHES BREAKS ........................................................ 65
3.6.5. PHASE 2 - LAB CLIENT DEVELOPMENT .......................................................................... 65
3.6.6. PHASE 2 - THE EXPERIMENT EXECUTION ENGINE............ Error! Bookmark not defined.

LIST OF FIGURES

Figure 2.1.a: Beam Bending
Configuration……………………………………………………………………………….7

Figure 2.1.b: Typical setup of the
Lab...….....…………………………………………………………………………….7

Figure 2.2.a: NI LabVIEW Strength of Materials
Lab………………………………………………….………….10

Figure 2.2.b: 2820-040 Bend fixtures for
wood……………………………………………………………………..10

Figure 2.2.c: Yoke Deflectometer with
extensometer…………………………………………………….…….10
Figure 2.3: Materials testing machine with 30 KN
capacity…………………………………………………………………12

Fig. 2.4: Overview of the iLab Shared Architecture ………………………………………………………..……16

Figure 3.1: 150 lbs Force Linear Actuator from Firgelli
Automations………………………………….….21

Figure 3.2.a: iLoad Digital USB Integrated Load Cell- load
sensor………………………………………...24

Figure 3.2.b: experiment test
bench………………………………………………………………………………..……24
Figure 3.3: Block Diagram of the MCU showing its interaction with the
PC…………………………………………29

Figure 3.4.a: relay interfacing
circuit…………………………………………………………………………………….30

Figure 3.4.b: schematic diagram for linear
actuator………………………………………………….…………..30
Figure 3.5.a: USB PIC Programmer
……………………………………………………………………………………………………..32

Figure 3.5.b: Usbpicprog:0.2.0
application………………………………………………………………………………………..…32

Figure 3.6: Microcontroller
Circuit………………………………………………………………………………………..34
Figure 3.7.a: +/- 12V
PSU……………………………………………………………………………………………………………………35

Figure 3.7.b: Max233 RS232
Schematic……………………………………………………………………………………………….35

Figure 3.8.a:Command set for the load
sensor………………………………..……………………………………37

Figure 3.8.b:load sensing application
window……………………………………………………………..………..37
Figure 3.9.a: Original design with 7 AX12 + 5
DOF………………………………………………………………………………..40

Figure 3.9.a: (b) Modified design with 5 dynamixel +
4DOF……………………………………………………..……….40

Figure 3.10: System connection for controlling multiple
dynamixels…………………………………….41

Figure 3.11: Control table for the AX12 dynamixel……………………………………………………………..44

Figure 3.12.a:USB2 Dynamixel Back view………………………………………………………………...45

Figure 3.12.b: USB2 Dynamixel front view…………………………………………………….………….45

Figure 3.13.a: Power supply schematic for powering the robotic

arm………………………………………….……46

Figure 3.13.b: Power supply circuit for powering the robotic

arm……………………………………………………...46

Figure 3.14: Different views of the Static Bending Test Machine
…………………………………………………….…..49

Figure 3.15: LabVIEW VI for controlling the

experiment....…………………………………….……………….53

Figure 3.16: The Static Bending Test Lab Client

Interface…………………………………………………………………57

Figure 3.17: Showing the streaming of the live video feed from the server………………………………………58

Figure 3.18: (a) Experiment Execution
Engine……………………………………………………………………………………60

Figure 3.18: (b) LabVIEW front panel called by the LabVIEW
dll…………………………………………………………60

CHAPTER ONE

INTRODUCTION

1.1. BACKGROUND
The Engineers Council for Professional Development in the United States define engineering

as the creative application of scientific knowledge in order to design and develop machines,

apparatus, structures and manufacturing processes to construct or operate; or to forecast

the behaviour of certain operating conditions. The application of this scientific or theoretical

knowledge taught in classes is realized through the use of laboratory experimentation; to

verify theories and also empower students to design and develop systems for the benefit of

mankind.

Experiments are indispensable for developing skills to deal with physical processes and

instrumentation. Students perform experiments to verify the theories taught in class, analyse

systems and ultimately project laboratory experienceto real life applications. However,

because of the rising cost of undergraduate laboratory equipment, increasing undergraduate

enrolments, coupled with the chronic underfunding of tertiary institution (particularly in a

developing country like Nigeria), the use of traditional laboratories has declined a great deal.

Over the years, with the decline in quality and quantity of traditional laboratories, laboratory

experimentation has metamorphosed and now we have different alternative to

experimentation. Among such include simulations, virtual laboratories and remote

laboratories. While simulation and virtual laboratories are both “all-software”, remote

laboratories are a hybrid of virtual laboratory and the traditional laboratory as it has both

hardware and software components. Virtual laboratories can be seen as online simulation.

Remote Laboratories on the other hand is real laboratory equipment controlled remotely.

1.2. SCOPE
The scope of the project involves development and deployment of a remote online

laboratory for static bending test, a civil engineering experiment to determine the strength

of materials. Traditionally, the experiment is performed by applying a known force on a

beam supported at both ends and measuring the resulting deflection of the beam. The

amount of deflection gives an indication of the material of the beam. Hence it is also called

beam deflection experiment.The task at hand is to make this experiment available to

students but remotely via the internet.

The first phase of the project involves design and construction of a control system that will

automate the whole process of the experiment allowing remote configuration and

measurement of the variable of the experimental setup. The application of a user-specified

force on the beam, measurement of the resulting deflection, ensuring availability of the lab

at all times and having it in mind that all these have to be achieved remotely with no human

intervention. Also, a computer program that will control/coordinate the execution of the

experiment would be developed.

The second phase involves creating the user interface to the lab that would allow remote

access to the experimental setup over the internet. This would involve developing an internet

application, establishing a communication link between the user interface and the remote

experimental setup over the internet using web services, setting up a web site that manages

the experiment records, and other administrative issues like login, authentication,

authorisation among other function. A database where experiment specification would be

stored to be loaded by a computer program that interfaces with the control system.

1.3. OBJECTIVES
A laboratory experiment usually involves a finite set of elements being configured in a finite

number of ways, with measurements being carried out at certain nodes of the setup. The

primary objective of this project is to bring the laboratory experience to the students. A way

to achieve this is to have a reconfigurable experimental setup remotely and providing a

means of accessing it over the internet.

For this particular laboratory, i.e. the strength of materials laboratory, providing a remote

access to it would involve first setting up the experiment and as there is no such

experimental setup before, there is need to develop an automated system for performing the

experiment and creating a set of software suite for manipulating the system over the

internet. The aims and objectives are highlighted below.

 Design and construction of the control system that will automate the whole process

of the experiment-requires understanding of how it works in the traditional setting.

 Providing a remote access to the laboratory experiment over the internet

 Setting up a central system for managing experiments, administration, record

keeping etc.

 Integrating the experiment into the MIT iLab Framework [iLabs]

 Deployment of the Strength of Materials laboratory during the rain semester for use

by 200 level students of the faculty of technology, OAU offering CVE 202

 Ensuring reliability and availability of the lab

1.4. JUSTIFICATION
In a Civil Engineering 200 level course (CVE 202) usually offered by students of the faculty of

technology, one of the topics taught is Strength of Materials, where we are taught how the

deflection of a beam under load is related to its modulus of elasticity; a property unique to

all materials. In essence, the nature/material of a beam could be determined by a simple

beam deflection experiment usually known as the static bending test. As part of the course

content, the student is supposed to have a laboratory session to demonstrate this theory.

Unfortunately, this laboratory session has been ruled out over a decade ago probably due to

lack of funding and logistics. This however in the long run have a negative effect on the

students as they can’t relate all those formulas and complex equations been taught in class

to the real world.

In a bid to rescue the situation, we proposed using an alternative to the traditional

laboratory. One is the use of a virtual laboratory and the other is the use of a remote

laboratory. Development of a remote laboratory for the Strength of Materials Lab rather

than students having physical contact with the lab, making it an online remote laboratory

effectively overcome many of the logistics associated with the traditional

laboratories.Students don not have to be physically present in the laboratory before

interacting with the lab equipment to perform the experiment. All lab configuration and

measurement are done remotely hence making the lab so flexible. Students can access the

lab anytime and from anywhere in the world as long as there is internet connection; perform

experiments at their leisure time, from their hostel, on holiday etc. thus improving student’s

efficiency and at the same time overcoming most of the challenges of accompaniedwith a

traditional laboratory setup such as space constraint, time constraint and most especially

cost as only one setup can serve all students saving the university the extra cost of buying

multiple equipment.

The Strength of Materials laboratory to be developed would be a unique one as all currently

operational remote laboratories in the university are electrical engineering/computer science

laboratories. This reflects a global trend as most remote labs are in these fields. The reason

for this is that it is much more difficult to build remote labs for other domains since such labs

would need to use a lot of sensors and actuators to convert the quantities and parameter of

interest in such domains to electrical signals that can be transferred over the internet. This

lab however is in the field of civil engineering so a way has to be found to convert the various

parameters into electrical signals. So it would be the first of its kind.

CHAPTER TWO

LITERATURE REVIEW

This chapter presents a review of subject matter for this project. This subject matter is rather

wide – from Static Bending Test Experiment, to remote virtual laboratories. Hence, for

brevity, only the aspects of subject matter which have an important relation to the project

development, and which are necessary for a better grasp and understanding of the projects

essentials are presented here.

2.1. STATIC BENDING TEST

2.1.1. BASIC THEORY
The Young Modulus is a material property that describes its stiffness and is therefore one of

the most important properties in engineering design. The material property which tells us

how stiff it is within its elastic limit is called its Modulus of Elasticity (MOE) or simply Young

Modulus, E. The bending of beams is one of the most important types of stress in

engineering. Bending is more likely to be a critical stress than other types of stress - like

tension, compression etc. In this experiment, we will determine the MOE of the various

materials and using Solid Edge to determine the Second Moment of Area for the different

cross-sections. To do this, we perform a beam deflection experiment which is known as the

Static bending test. Figure 2.1.a below, we show the different ways the beam deflection

experiment can be configured

(a)

(b)

Figure 2.1: (a) Beam Bending Configurations (b) Typical setup of the Lab

Bending Equations

Units: Force (Newton), Span Length (mm), Stress (MPa)
E = Young's Modulus or Mod of Elasticity (MPa)
I = 2nd Moment of Area or Area Moment (mm4) which can be calculated using Solid Edge sketch
For a rectangular beam, we use the formula

So that E = (W x L3)/(48 x d x I)

2.1.2. EXPERIMENT PEDAGOGICS
OBJECTIVE: The objective of this laboratory experiment is to determine the Young’s Modulus

i.e. the Modulus of Elasticity of a material.

APPARATUS: Beam, Support, Weight, Vernier scale.

INTRODUCTORY INFORMATION: Probably the most common type of structural member is

the beam. A beam may be defined as a member whose length is relatively large in

comparison with its thickness and depth, and which is loaded with transverse loads that

produces significant bending effects. Whenever a real beam is loaded in any manner, the

beam will deform such that an initially straight beam will assume some deformed shape

depending on the modulus of elasticity of the beam.

The modulus of elasticity of a material is the ratio of the stress to the strain of the material.

The modulus of elasticity is determined by the value of deflection of the beam under a

Bending Static Test. The value of deflection is used to calculate the moment of elasticity of

the material. The modulus of elasticity of a beam depends on the following factors:

 The applied load / force

 The span or length of the beam

 The width of the beam and its thickness

PROCEDURE: The experiment involves using a simply supported beam with two ends fixed.

The length of the beam is specified and should be kept constant throughout the experiment.

Note that the length of the beam here is the distance between the two fixed ends. A known

weight is applied on the beam at any point between the two fixed ends and the

corresponding deflection measured. Additional weight is either added or removed and the

resulting deflection measured. This is done severally and a table showing force and its

corresponding deflection is obtained.From the table we can plot the graph of force vs.

deflection and the modulus of elasticity of the material can be determined. Figure 2.1.b

shows a typical setup of the static bending test experiment.

2.2. STRENGTH OF MATERIALS LABORATORIES, EQUIPMENT AND MACHINES

NI Strength of Materials Lab: This Strength of Materials Lab is based on the NI Distributed

I/O platform and the NILabVIEW graphical programming software. The Lab consists of a set

of elementsrequired to build particular devices for specific laboratories and NI measurement

devicesrequired to acquire sensor readings and transfer them to a computer. The

computerprocesses the readings and helps visualize the data in time domain. Data

acquisition andprocessing is done with the help of NI LabVIEW.Fig. 2.2. (a) shows the NI

Strength of Materials Lab hardware setup and NI LabVIEW interface.

2820-04x Series (Bend Test Fixtures for Wood): 2820-04x Series bend fixtures shown in fig.

2.2. (b) are designed forstatic bend/flexure testing on a range of wood andtimber products

according to common InternationalStandards. The beam attaches to the test

instrumentusing simple mechanical interface which allows it tobe removed when not in use.

Deflection of the specimen can be measured using theoptional deflection measurement yoke

and a suitableextensometer.

(a)

(b)(c)

Figure 2.2. (a) NI LabVIEW Strength of Materials Lab (b) 2820-040 Bend fixture for wood

(c) yoke deflectometer with extensometer

Strength of Materials Laboratory at University of MACAU: The objective of this particular

strength of materials lab at University of Macau is to demonstrate the basic principles in the

area of strength and mechanics of materials and structural analysis to the undergraduate

students through a series of experiments. Tests such as the tension tests of a steel coupon,

torsion of model circular sections and bending of a steel bar are conducted in the lab. It alos

introduces students to data acquisition system (Strain gauges and dial gauges etc) used in

experimental study.This computer controlled machine records the load displacement

relationship of the test specimen. Load can be applied through either load or stroke

control. The computer data acquisition can process the data and display the stress-strain

diagram of the test-materials instantaneously. The material testing machine is shown in fig.

2.3. below.

National Institute of Technology,Tiruchirappalli- Strength of Materials Laboratory:This

Strength of Materials Laboratory offers facilities for testing building materials for their

strength, behaviour and suitability for various applications.

Strength of Materials Laboratory, ANNA University: have experiment for determining the

Young’s modulus of the material of the steel beam by conduction deflection test

Figure 2.3. Materials testing machine with 30 KN capacity:

2.3. REMOTE VIRTUAL LABORATORIES
Due to the various challenges associated with traditional laboratory setting, the

advancement in technology has brought about alternative to laboratory experimentation.

The various options range from simulation, virtual laboratories and remote laboratories.

Simulations are software applications that use the theory behind the experiment to model a

laboratory setting. Virtual laboratoriesare more like simulation except that they are internet

based applications that is run over the internet.Remote laboratories however area hybrid of

virtual laboratories and traditional/conventional laboratories. It is important to emphasize

that remote laboratories are real laboratories. Simply put, it is a real experiment remotely

located. There are a number of remote laboratories all over the world cutting across

different engineering disciplines like electronics, electrical, computer, mechanical, Also, there

are different approaches to the implementation to internet accessible remote laboratories

examples include the iLab Project at Massachusetts Institute of Technology (MIT), remote

lab at University of South Australia (UNISA),Remote laboratory at Blekinge Institute of

Technology etc. For this project, the iLabs waschosen as the platform for developing the

Strength of Materials remote laboratory as because of its uniqueness.

2.3.1. ILABS-PLATFORM FOR REMOTE EXPERIMENTATION
iLabs are remote laboratories based on the MIT iLabs Shared Architecture, whose multi-

tier topology makes them suitable for bandwidth-constrained environments. The iLab

project at MIT is dedicated to the creation of a movement to develop and disseminate

technology and pedagogy for sustainable and scalable iLabs so that they can be shared

worldwide.

Based on the experiences of the different iLab development teams, the iLabs Project

developed a suite of software tools that would make it efficient to bring online complex

laboratory experiments, and provides the infrastructure for user management. The iLabs

Shared Architecture has the following design goals:

 Minimize development and management effort by providers of remote labs.

 Provide a common set of services and development tools.

 Scale to large numbers of users worldwide.

 Allow multiple universities with diverse network infrastructures to share remote labs.

iLabs employ on-line laboratories to enrich higher education in Africa by sharing laboratory

facilities in science and engineering. With the rising cost of undergraduate laboratory

equipment and increasing undergraduate enrolments, it is a novel solution to the problems

of inadequate funding of undergraduate laboratories. Examples include remote

experimentation in the fields of microelectronics, chemical engineering, polymer

crystallization, signal processing etc.

2.3.2. THE iLAB SHARED ARCHITECTURE
To facilitate the rapid development and effective management of iLabs, the iLab team in MIT

has developed a toolkit of reusable modules and a set of standardized protocols and web

services referred to as the iLab Shared Architecture. This software framework is now being

used by several iLab groups worldwide to develop new iLabs. This effort forms the kernel of a

major new programmatic and institutional initiative at MIT to promote shared access to

laboratory equipment by educational institutions around the world.

The iLab Architecture is a three-tiered architecture consisting of the Lab Client, Service

Broker and the Lab Server. Fig. 2.1 shows the iLabs architecture overview. These three tiers

are connected together using web services; web Application Programming Interface (API)

used for communication between client and server over HyperText Transfer Protocol (HTTP).

iLab’s design pattern separates online laboratories into three distinct modules connected by

a web service architecture.

Lab Client: The Lab Client is an application that runs in a web browser which the students

interacts with to configure experiment, send the experiment specification and retrieve result.

The Lab Client is the front end of the system. It is the interface (usually graphical) through

which a student interacts with the remote experiment. The interface is a depiction of the real

lab and allows the student to make modifications (set experiment specification) thereby

placing the interface in one of a large number of finite states. Lab Client are usually

developed using Java, C# or LabVIEW but recently, iLab OAU has pioneered the use of

another technology, the Adobe Flex Framework to develop Lab Client.

Fig. 2.4. Overview of the iLab Shared Architecture

Service Broker: The Service Broker is the middle tier, a web application that provides web

service with a number of APIs. It is essentially is the middleman that links the Lab Client with

the Lab Server (hardware backend) by providing the shared common services. It also serves

administrative and storage purposes. The Service Broker was developed by the iLab MIT

team using the Microsoft.NET Framework: Active Server Pages (ASP) plus C# as the code-

behind. The student’s client communicates solely with the Service Broker, which forwards

experiment specifications to the Lab Server. The Service Broker has a very rich web service

interface through which it communicates with the Lab Client and Lab Server. Usually the

Service Broker will reside on a server machine different from the clients system. The Service

Broker performs administrative, authorisation, authentication functions; it takes care of the

authentication and the authorization of users, user session, and experiment data storage,

forwarding experiment specification to the Lab Server and retrieving the result.

Lab Server: The Lab Server is the hardware backend, the remotely located laboratory

experiment setup. It executes the experiments (based on the experiment specification sent

by the student) on the real hardware equipment and sends back the result of the experiment

to the Lab Client through the Service Broker. The Lab Server has two components the

software and the hardware. The software components include the Generic Server

component (Lab Server web service), the experiment execution engine and a database while

the hardware is the laboratory device we are interacting with.

CHAPTER THREE

METHODOLOGY

3.1. RESTATING THE TASK AHEAD
The task at hand is to create a platform for performing static bending test experiment over

the internet using the MIT iLab framework. So it involves development of the Lab Client and

the Lab Server and deployment of the experiment on the Service Broker. The Lab Client

would be developed with the Adobe Flex Framework; a programming platform from Adobe

Systems Incorporated for creating Rich Internet Application (RIA). The Lab Server would

consist a Microsoft SQL Database, a C-Sharp program that coordinates the execution of the

experiment and would serve as entry point into the hardware, and of course the static

bending test machine that would be constructed for performing the experiment. The Service

Broker however would be the OAU iLab Service Broker for batched experiments developed by

the MIT iLab team. Hence the only task here would be configuring the Service Broker and

setting up the lab client and lab server on it so the experiment is available on the OAU iLab

website.

To make an existing traditional laboratory experiment an iLab, a series of questions needed

to be answered. The first most important question we need to answer is can we control the

lab equipment from a personal computer? To what extent do we have control over the

parameters and quantities involved in the experiment? If the answer to the first question is

no, then it’s basically impossible to make such an experiment an iLab. If the answer to the

first question is yes then we start thinking of how to make that computer a server so that a

client computer can have access to such system. So it’s like a (user) computer controlling

another (server) computer that controls the equipment.

3.2. KEY ISSUES
Making an experiment an iLab involves sending and receiving of electrical signal for

configuring and measuring of quantities and parameters associated with the experiment.

Hence most iLabs are in the domain of electronic/electrical and computer engineering. The

Strength of Materials iLab being discussed here is however an exception to the trend as it lies

in the domain of civil engineering and materials science. This makes it somewhat difficult to

make it an iLab. Nevertheless, with the right combination of sensors and actuators it is

possible to convert physical variables/quantities into electrical signals.

We once again reiterate the steps involved in carrying out the experiment.

 A beam supported on a pivot at both ends

 A known force is applied at any point between the two pivots

 The beam deflects due to the load applied

 The deflection of the beam is measured using a deflection measuring instrument

 The value of deflection is used to calculate the modulus of elasticity which is a unique

property for every material.

Developing a remote online laboratory for this experiment involves the use of a number of

sensors and actuators to create a control system for virtual experimentation. The key

problems to be solved would involve:

 How do we apply a user-specified force on a beam located remotely?

 How do we measure the amount of force applied on the beam

 How do we measure the resulting deflection of a beam due to the applied force since

the deflection is not an electrical signal?

 In case the beam breaks due to excessive load applied on it or rather reaches critical

limits as yield/plastic limit, what happens next? How will the experiment continue?

How do we ensure the continuity of the experiment?

 How do we even known if the beam is broken?

Answering these questions and having it in mind that there is absolutely no human

intervention and that the whole process has to be automated brings us a step closer to

designing the fully automated system that would allow this experiment to be carried out.

3.3. PROPOSED SOLUTION/DESIGN
Taking the highlighted issues one after the other, we propose a conglomeration of hardware

and software, sensors and actuators connected to a central computer which also acts as a

network server allow remote configurability of the system over the internet.

3.3.1. LINEAR ACTUATOR-LOAD APPLICATION
For the remote application of load, we use the FA-PO-150-12-8" (20:1) Linear Actuator with

Potentiometer Feedback from FIRGELLI AUTOMATIONS shown in fig. 3.1 with a 2-12 inches

stroke that extends and retracts when operated in forward and reverse mode. The end of the

stroke is mounted on the system under test i.e. the beam and when operated applies a

vertical downward force on the beam. To operate the actuator in the forward mode, a +12

volt dc power supply is applied while operating it in the reverse mode requires a -12 volt dc

power supply. Consequently, 3 modes of operation can be identified; FORWARD, REVERSE

AND STOP. The forward mode is that of increasing force, in the reverse mode-decreasing

force and for the stop mode, force is constant.

Figure 3.1. 150 lbs Force Linear Actuator from Firgelli Automations

So to apply an amount of load with no initial load, we start out with operating the actuator

in the forward mode and when the load reaches the desired limit, we switch to the stop

mode. Assuming we are applying a load which is less than initial load, we operate the

actuator in the reverse mode and stop when we get the desired load. A PIC microcontroller

circuit is used to control the linear actuator from a PC in the first phase of development but

in the second phase the PIC was replaced with NI USB 6009, a small Data Acquisition Device

(DAQ). A detailed description of this is given in section 3.4.1.

3.3.2. LOAD SENSOR – FORCE MEASUREMENT
To measure the amount of force applied on the beam requires a sensor that can that sense

force and convert it to electrical signal. As the load is being applied by the linear actuator,

we need a sensor that can measure the force on the beam in real time so that when the

desired load value is reached the actuator can stop. Using iLoad Digital USB Integrated Load

Cell manufactured by Loadstar SENSORS shown in fig. 3.2(a), a load sensing device that

senses the force applied on it and outputs it to a computer system through the USB port

using a Virtual COM port. The iLoad Digital USB load cells offer direct measurement of static

loads via the USB port of a PC. No need for signal conditioners, data acquisition systems or

special software. It provides unprecedented integration of sensing and measurement

electronics to provide Plug and Sense simplicity for compressive load and force

measurement.

Its distinguishing features includes: Plug and Sense Simplicity, Digital Integrated Electronics,

Standard USB output, Power supplied via USB port, integrated power conditioning, Stored

Calibration. The iLoad Digital sensor appears on the PC as a virtual COM port. Using a

standard terminal emulator, we can send commands to the sensor to directly display sensor

output in pound (lb) as ASCII text. You can query loads one reading at a time or get a

continuous stream of readings using a terminal emulating program.

Two iLoad sensors would be placed at the two ends of the beam with a wedge mounted on it

to provide a sharp pivot and also distribute the load towards the centre of the device. The

beam would be mounted on the wedge and the actuator applying a downward force at the

centre of the beam (see fig. 3.2(b)). The downward force due to the linear actuator equals

the sum of the two upward forces at the ends of the beam. Each sensor can sense the

reaction on it due to the applied force. Hence if we can read the force value on each of the

sensors and sum them, we can get the exact force acting on the beam i.e. F = R1+R2.

(a)

Linear Actuator

R1 R2

Load Sensor
F
(b)

Figure 3.2. (a) iLoad Digital USB Integrated Load Cell- load sensor (b) experiment test bench

3.3.3 POTENTIOMETER – DEFLECTION MEASUREMENT
On the application of force on the beam, the beam deflects by a particular amount. We

need to communicate the value of the deflection to the user. One easy way that could be

done is providing a visual feedback using webcam but the problem with this approach is that

the deflection usually is in millimetre range. The user might not be able to measure

accurately the deflection using this technique due to parallax and resolution. Therefore we

rule out this method.

If a way can be found to measure the amount by which the linear actuator applying the force

extends or retracts, then we can have a measure of the deflection as this would be

proportional. The linear actuator used is a 12'' Stroke 150lb Force Linear Actuator (described

in section 3.3.1) with built in 10K ohms Potentiometer. As stated earlier, the actuator

extends or retracts based on the polarity of the voltage supply. The built in 10K ohms

potentiometer is used to measure the deflection.

The potentiometer value changes as the actuator protrudes and retracts and the resistance

value is proportional to the linear displacement action of the actuator. By measuring the

resistance value of the potentiometer, we can calibrate the system to get the value of

deflection. In the first phase of development, we used a PIC microcontroller with an inbuilt

10 bit analogue to digital conversion (ADC) module; we can accurately measure the

deflection thus achieving the conversion of the physical variable (deflection) to electrical

signal (voltage). In the second phase, we replaced the PIC with the NI USB 6009 as it could

measure with an even higher resolution of up to 14 bits. This would be described in details in

section 3.4.1.

3.3.4 BEAM REPLACEMENT
In case of deformation or damage of the beam, there is no lab attendant to replace the

beam as this is a remote laboratory where everything is expected to be automated and the

experiment must continue. During the course of the experiment, a student might apply an

extremely high force on the beam to the extent that the beam breaks into two. In this kind of

scenario, two options came to mind:

1. We can put a limit as to what the student can do, like putting a limit on the force

applicable from the user interface, so that a particular amount of force that would

cause the beam to break or deform is disabled even from the user interface. But the

problem with such method is that the pedagogics of the experiment is altered

already and the critical points disabled are very important in the experiment for the

concept to be fully understood. Though the student will still be able to perform the

experiment, the experience might not be as that in a real laboratory setting.

2. The second way which is the most efficient but hard way is to allow the students to

do whatever they would on the beam, even if they have to break it to get maximum

output from the lab experience. Now the problem arises if the beam breaks or

deforms. Continuing the experiment on the same test subject will give unreliable

result so there is need to replace the beam with a new one.

Going for the second option, i.e. allowing the student to have the complete laboratory

experience will require a configuration of automated systems which will include a robotic

arm for replacing the beams, an automated rack system holding the beams.

A robotic arm such as those used in assembly line by manufacturing industries for high

precision jobs will be used solely for the purpose of picking a new beam on the rack and

placing it on the test bench in the event of a beam break.

To ensure the accuracy, precision repeatability and reliability of the robotic arm, we try

as much as possible to avoid the robotic arm going to pick beam at different location on

the rack. Rather, we automate the rack itself so that the beams are always arranged so

that a beam is always available at a particular location.

Assuming the robotic arm pick a new beam at location X, the rack arranges the

remaining beams such that another beam replaces that taken at location X and the next

time the robotic arm needs a new beams it just goes to the same location X and avoid

determining where the next beam is. So the automated rack is for ensuring a beam is

always available at a specified location.

3.4. WORK DONE – PHASE 1
This section gives a detailed description of devices, components and parts of the system. The

hardware, firmware and software that have been developed and those that are still being

developed are discussed under this section. The process of design and development of each

of the component part including the controller unit, power supplies, robotic arm, chassis and

rack are all discussed here. Most of the design described here is work in progress as it is the

first phase of the project development. Significant change was made in the design and these

would be discussed in the second phase of the project design.

3.4.1 PHASE 1 - THE MICROCONTROLLER UNIT
In the first phase, the microcontroller unit (MCU) coordinates the operation of the Linear

Actuator, measuring the deflection and the communication between the circuit and the PC.

The block diagram with arrows indicating control flow presented in fig. 3.3 shows the

microcontroller and how it interacts with the linear actuator, measure deflection through a

feedback loop and a two-way channel for communicating with the computer system through

the serial port. The microcontroller unit used is Programmable Integrated Circuit (PIC) of the

18F family specifically PIC 18F2550, a 28 pin re-programmable Integrated circuit.

Controlling the linear actuator from the PIC involves the use of relays as switches as MCU

cannot directly control the actuator. This is due to the fact that PICs generally use +5V power

supply and the linear actuator uses a +/-12 V power supply which makes it impossible for the

microcontroller output pin to directly control the actuator. Two relays are used, one for

switching to +12V and the other for switching to -12v. The relay is connected to the output

pin of the PIC and the firmware (embedded program) on the PIC controls when the relays

switch on/off. The relay switches on when the output pin of the microcontroller goes HIGH

and off when output goes LOW. A transistor BC547 was used to switch on/off the relay. Fig.

3.4.(a) shows the schematic of the interfacing a relay to a MCU.

Figure 3.3: Block Diagram of the MCU showing its interaction with the PC

(a)

(b)

Figure 3.4. (a) relay interfacing circuit (b) schematic diagram for linear actuator

The value of the potentiometer on the actuator is measured using the Analogue to Digital

Converted module of the same PIC used to control the actuator. Fig. 3.4.(b) shows the

schematic diagram of the actuator. The blue and white wires are connected to the positive

and negative voltage reference (+5V and Gnd) of the PIC for the ADC conversion. The yellow

wire connected to any analogue input pin of the PIC so its value can be read by the internal

ADC module of the PIC.

The circuit that does the control action plus the ADC was first simulated in Proteus (a circuit

simulation software) see appendix I. The firmware (see appendix II) that controls the

microcontroller was written in C language using the PIC C CCS Compiler and after successful

compilation and build, the compiler automatically generates an HEX file which can be

embedded into the PIC using a PIC programmer.

The PIC programmer hardware (shown in fig. 3.5.(a)) used in burning the hex code into the

chip was home-made with the original circuit from www.usbpicprog.org. Custom software

that is being used with the programmer is usbpicprog version 0.2.0. The interface of the

usbpicprog application is shown in fig 3.5.(b). The programmer connects to the PC through a

USB interface.

The PIC 18F2550 to be programmed is mounted on the programmer, the usbpicprog:0.2.0

application detects the programmer and the type of PIC chip on it. The hex code generated

by the CCS complier is loaded into the software and written into the chip by clicking on the

“program” command. On successful programming, the programmer is disconnected and PIC

removed and can then transfer back to the main circuit board.

(a)

(b)

Figure 3.5. (a) USB PIC Programmer (b) Usbpicprog:0.2.0 application

The microcontroller circuit shown in fig. 3.6 was built on a vero board in modules consisting

 +/-12V power supply circuit,

 The relay circuit

 The circuit that interfaces the PIC with the PC.

The power supply circuit (schematic-fig.3.7.(a) ) consist a 240/12V 500mA transformer, a

bridge rectifier, regulator ICs, capacitors, diodes, resistors and LEDs. The bridge rectifier

converts the AC signal to DC and the capacitor straightens the waveform and the regulator

ICs 7812 and 7912 produces the constant +12V and -12V respectively. The relay circuit has

been described already in section 3.4.1. and the schematic is shown in fig. 3.4. (b).

For interfacing the PIC with the PC, we use the RS232 protocol for serial port communication.

Components used include: Max233 IC, DB 9 female connector, USB to Serial Converter Cable

and Prolific USB to serial driver to be installed on the PC. A terminal emulator program was

written in C# to send command to the PIC. The 3 basic commands used (for now) is “f”, “r”

and “s” where f instructs the PIC to operate the actuator in forward mode, r corresponds to

reverse mode while s instructs the PIC to stop the actuator and return the analogue value of

the potentiometer to the PC. The source code of the firmware controlling the PIC is attached

in appendix II.

Figure 3.6: Microcontroller Circuit

(a)

(b)

Figure 3.7: (a) +/- 12V PSU (b) Max233 RS232 Schematic

3.4.2. PHASE 1 - LOAD SENSING
To measure the force applied on the beam, we use the iLoad Digital Sensor. As mentioned

earlier, it’s a Plug and Sense device which allows easy load measurement via the USB port as

it presents itself as a Virtual COM port to the PC. A computer program that can

communicate with the serial port of the computer was written in C-Sharp which has a set of

API for serial port communication; the System.IO.Ports class. Before using the device, FTDI

driver must be installed on the PC so as to present the USB device as a virtual COM port. The

COM setting for the device is as follow:

BaudRate = 9600bps, DataBits = 8, StopBit = One, Parity = None

Interacting with the load sensor requires knowing the specific commands that the sensor

receives and the corresponding output hence the use of the device’s datasheet is imperative.

The datasheet was downloaded from the support page of the manufacturer’s website

(www.loadstarsensors.com). The set of command that can be issued to the load sensor and

the corresponding output is shown in fig. 3.8 (a) below.

For example, sending a command o0w0 with a carriage return outputs the force

continuously. To do this, we first define the port setting as above, open the port and write

the command to the COM port. For example the program line below

SerialPort com = new SerialPort();

com.WriteLine("o0W1" + "r");

implies we write the command o0W1 to the COM port and in response to this command, the

sensor returns a continous stream of ASCII text to the PC which can be read using the

DataReceivedEventHandler function. Fig. 3.8. (b) shows the command window of the

(a)

(b)

Figure 3.8. (a) Command set for the load sensor (b) load sensing application window

running application that communicates with the load sensor through the virtual COM port.

The surce code for the application running above is attached in appendix III.

3.4.3. PHASE 1 - THE ROBOTIC ARM
The Design: A modified version of the AX-12 Robotic Arm originally designed by Alex Kirk of

CrustCrawler is to be used for replacing of the system under test (i.e. the beam). It uses a

total of 5 dynamixel (servo) units and has 4 degrees of freedom (DOF). The robotic kit was

purchased from CrustCrawler, a company that designs robots. The kit contains 7 AX-12

dynamixels with the component parts that make up the robotic arm. The AX-12 dynamixel is

a powerful and feedback rich servo motor module manufactured by Robotis

(www.robotis.com). The technical specification of the AX12+ servo is listed below:

• Blazing fast 1,000,000 bps communication speed

• Full feedback on position, speed, load, voltage and temperature

• 300 degree movement in 1024 increments

• Full control over speed and torque in 1024 increments

• Built in LED status indicator

• Automatic shutdown based on voltage, load or temperature

• Single cable network connections

• Servo movement range can be set by the user

The robotics kit was assembled following the instruction manual that came with the kit. The
assembled robotic arm is shown in fig. 3.9. (a) with 7 AX12 dynamixels with 5 DOF consisting
the base, shoulder, elbow, wrist and gripper.

During the course of experimenting with the robotic arm, the original design had to be
modified to reduce the complexity of the forward and inverse kinematics and torque
balancing issues and most important to suit our application. The modified version of the

robotic arm now has 4 degrees of freedom and 5 dynamixel units. The two servos at the
shoulder joint have been removed and the new design given below in fig. 3.9. (b). It has a
base that can turn 360 degrees, elbow wrist and gripper. The end effector being the gripper
would be used for picking the beams.

Communication Protocol: The communication protocol for the AX12 dynamixel is half

duplex asynchronous serial communication with port setting 1Mbps, 8 bit, 1 stop bit and no

parity. A multi-drop method of connecting multiple dynamixel actuators to a single node is

employed by using the half duplex UART. Thus a protocol that does not allow multiple

transmissions at the same time should be maintained when controlling the dynamixel

actuators. The main controller communicates with the Dynamixel units by sending and

receiving data packets.

There are two types of packets; the “Instruction Packet” (sent from the main controller to

the Dynamixel actuators) and the “Status Packet” (sent from the Dynamixel actuators to the

main controller.) For the system connection in fig. 3.10., if the main controller sends an

instruction packet with the ID set to N, only the Dynamixel unit with this ID value will return

its respective status packet and perform the required instruction. If multiple Dynamixel units

have the same ID value, multiple packets sent simultaneously collide, resulting in

communication problems. Thus, it is imperative that no Dynamixel units share the same ID in

a network node.

(a) (b)

Figure 3.9. (a) Original design with 7 AX12 + 5 DOF (b) Modified design with 5 dynamixel + 4DOF

Figure 3.10. System connection for controlling multiple dynamixels

The instruction packet is the packet sent by the main controller to the dynamixel units to

send commands. The structure of the instruction packet is as follows:

The datasheet that describes the AX-12 dynamixel unit shows its control table with the RAM

and ROM address having read/write attributes allowing instructions to be written to and

read from the a specified address. The control table for the AX12 dynamixel is shown in fig.

3.11. The set of instructions which can be sent to the dynamixel includes Read, Write,

Reg_Write, Sync_Write, Action, Ping etc. For example, to move the servo to a particular

position, we write the desired value (0-1024) to the specific address (30) for goal position.

Another row on the control table allows for speed manipulations, another for torgue etc.

To operate the dynamixel actuator, the main controller must support TTL level half duplex

UART. Hence, to control such dynamixel unit from a PC, a TTL level converter is needed. One

of such devices is the USB2Dynamixel (fig. 3.12.). The USB to dynamixel is basically a “Virtual

Serial Port” that attaches to the USB port on a PC. USB2Dynamixel is the connector between

the dynamixel units and the computer. It interfaces the computer through the USB port thus

a TTL to USB converter. Command is sent to the dynamixel through the USB2Dynamixel. The

USB2Dynamixel is a USB device so it cannot power the dynamixel unit. Hence a separate

power supply is needed.

Power Supply: To power the robot arm, we need a 9V, 4.5A power supply as we need to

power 5 dynamixel actuators with each actuator needing about 900mA current at 9V. The

power supply circuit uses a pass transistor (MJ2955) to deliver the high current needed. The

schematic diagram for the 9V, 6A power supply is shown in fig 3.13 (a) and the constructed

circuit in fig. 3.13 (b).

Figure 3.11. Control table for the AX12 dynamixel

USB Connector

Serial Connector
4 Pin Connector 3 Pin Connector

(a)

Function selection
Status display LED
switch

(b)

Figure 3.12. USB2 Dynamixel (a) Back view (b) and the front view

(a)

(b)

Figure 3.13. Power supply circuit for powering the robotic arm (a) schematic (b) circuit board

Programming: There are varieties of platforms programming languages by which we can

control the robotic arm which includes using PIC C for microcontroller application or from the

system using a high level programming language like C#, java, LabVIEW, MatLab, VB.NET

etc. Since our experiment engine would be written in C#, it is a better choice to use C# to

program our robotic arm.

Using a set of Dynamic Linked Libraries (DLLs) to interface the dynamixel hardware and the

C# program we can send control signals to the dynamixel and consequently get a feedback

through the same channel. The DLLs presents the functions that can be used to manipulate

the dynamixel hardware. Hence it serves as an entry point into the dynamixel module.

For example, the code snippet bellow moves a dynamixel servo with id 4 to a position 1000

with speed 300 using the INST_WRITE command. Position and Speed are both 2 bytes hence

the high (1000 & 0xFF00 / 0x100) and low (1000 & 0xFF). For every communication, the

dynamixel.dxl_initialize method must be called and so also the terminate() function at the

end of all command blocks.

dynamixel.dxl_initialize();
dynamixel.dxl_set_txpacket_id(4);
dynamixel.dxl_set_txpacket_length(7);
dynamixel.dxl_set_txpacket_instruction(dynamixel.INST_WRITE);
dynamixel.dxl_set_txpacket_parameter(0, 0x1E);
dynamixel.dxl_set_txpacket_parameter(1, (byte)(1000 & 0xFF));
dynamixel.dxl_set_txpacket_parameter(2, (byte)((1000& 0xFF00) / 0x100));
dynamixel.dxl_set_txpacket_parameter(3, (byte)(300 & 0xFF));
dynamixel.dxl_set_txpacket_parameter(4, (byte)((300 & 0xFF00) / 0x100));
dynamixel.dxl_tx_packet();
dynamixel.dxl_terminate();

Moving more than one unit at a time using the write command is impossible because it uses

a single bus, so we use the REG_WRITE plus ACTION command. The REG_WRITE only stores

the instruction on the ram area but never executes it until an ACTION command is sent. The

action command is usually sent through the broadcast ID (254 which means instruction is

sent to all units). Any unit with stored instruction executes it once the action commend is

sent. Say we want to control 3 units together, each unit is sent a REG_WRITE command and

then an action command is sent through the broadcast id and so all instruction gets

executed at once.

A C-Sharp program to demonstrate controlling of the robotic arm; one or two servos at a

time was written and the source code is attached in appendix IV. This however is not the

complete program that would perform the action of beam replacement but it’s sufficient to

establish the fact that we can now move the robotic arm to any desired location. The

complete program would require precise value of the dimension of the chassis, and the rack

so as to be able to solve the inverse kinematics equation that would be used to determine

the end effectors (gripper) position. The design of chassis and rack as at the time of writing

this report has not been accomplished.

3.4.4 AUTOMATED RACK AND CHASSIS DESIGN
The rack holding the beams (for replacement) is also an automated system. This however is still in

conceptual stage and is yet to materialize. The rack is expected to make sure a new beam is always

available at a particular location in reach of the robotic arm. The beams would be arranged in the

rack in such a way as to maximize space so more beams can be supplied to the rack and ensure a

fairly large interval between beam replacements when all the beams on the rack might have finished.

The chassis holds all the systems together including the test bench, robotic arm and rack mechanism.

Fig. 3.14. shows what the whole system would look like.

Figure 3.14. different views of the Static Bending Test Machine showing test bench, robotic arm and
rack

3.5. Challenges and Solution
A number of challenges were faced while designing the power supply circuit, controlling the robotic

arm, programming; both hardware and software, designing of the mechanical systems etc. A few

problems were surmounted while few still remains a mystery.

3.5.1. POWER ISSUES
The first major issue I encountered was building the 9V 6A power supply circuit. The usually power

supply circuit I was familiar with was the simple low current PSU. With help from my supervisor, I

understood I was to use a high pass transistor to deliver the extra-high current required. After

designing this circuit, measuring the output current (no load attached) using a multimeter I got 2A or

thereabout. So I thought it didn’t work. As ridiculous as it might seem, I spent about 3 weeks on it! It

was later I discovered that it worked all the while and that all that is needed is to connect the load

and the required current will be delivered.

3.5.2. READING FROM SENSOR
Being the first time I would be writing a program to read and write to the serial port, it was

quite challenging. I had to do a lot of “googling” before I could understand how to use the

serial port class in C#. Writing to the device at first seems quite easy, the problem came I

tried reading from the device. It took a while before I could figure out what the problem was.

I was missing a carriage return (CR) at the end of the command and from the datasheet of

the load sensor; a CR must always be at the end of every command. It’s more like the

pressing the enter button after inputting a command.

3.5.3. CONTROLLING COUPLED DYNAMIXEL
Moving two dynamixels coupled together involves the use of REG_WRITE + ACTION.

Controlling the elbow joint is such an instance when this is needed as it consists of 2 coupled

joints. Because of the way the servos are joined together in this particular case they tend to

move in opposite directions when given directive to move to the same position value.

Initially, I was given the two servos to move to the same position value and what I observed

each time was that each time, it always returns error after it has moved for a short period. I

later discovered that since the servos are facing opposite directions, given them command to

same position value would only move them in opposite directions and the effect is; one

moving clockwise and the other counter clockwise.

To make sure they are synchronously moved, I simply inverted the position value of one and

give it to the other. Inverting a value implies subtracting its value from 1024 (which is the

maximum position value). Say we want to, move the 2 coupled units with id 3 and 4 to

position x where x lies between 0 and 1024, we simply move 3 to x and 4 to (1024-x).

3.6. PHASE 2 – REDESIGNING
After finishing the first phase of the development, a number of issues were considered and

this lead to a complete change of the development tools, controlling unit among others.

Also, in the first phase of the development, the lab client was left out completely. Though

this was intentionally planned so that the lab client development will be among the activities

of the final phase of development. Then we focus more on tying together all the various

components of the lab i.e. integrating the remote laboratory equipment, experiment engine,

database, service broker and the lab client to create a full-fledged iLab.

During this period, the project did undergo significant change in design as we explore better

means of solving the challenges at hand and also ways of making the project better. An

highlight of the activities carried out in the second phase of development is listed here:

3.6.1 PHASE 2 - USE OF NI DAQ AND LABVIEW
In the phase 1, we used a PIC micro controller circuit to control the actuator, read the

resistance feedback, and communicate to the computer. For the ADC we used a PIC of the

18F series which has a 10 bit ADC resolution. This resolution is high but might not be high

enough to measure very little changes in deflection. So we are considered using NI USB-

6009, an 8 inputs, 14-bit, Multifunction I/O in place of the microcontroller unit. Its ADC

resolution is 14 bit which is significantly larger than PIC 18F2550 (10bit). It has both

analogue and digital I/O hence it could also be used to control the actuator. It is also a very

portable data acquisition (DAQ) device (see fig. 3.15), so it is a good replacement for the

MCU. In addition, we also considered reading the load sensor through the device. A LabVIEW

VI program was created to operate the actuator in forward, reverse and stop mode, also the

potentiometer was connected to this same device in differential configuration so it could use

all of its 14 bits for ADC. The same program was used to read from the load sensor and the

result from the load sensor compared to the load value specified by the student which

determines when to forward, reverse or stop the actuator. The LabVIEW VI program is

shown below in figure 3.15.

3.6.2 PHASE 2 - ROBOTIC ARM CONTROL
So far, we have been able to demonstrate is the control of one or more dynamixel at same or

different time. This is sufficient only to prove the fact we can now send control signal to the

dynamixel servos but is not sufficient to replace a beam in the course of an experiment.

Controlling the robotic arm would required correct measurement of the dimensions robotic

arm, rack, chassis, test bench and beam location. All these dimensions would go into the

derivation of the inverse kinematics equation. Only after the equation has been derived and

solved can the program for controlling the robotic be written. The complete C# program for

controlling the arm was developed. 4 paths were program; default path, and 3 other paths

for picking beams at 3 different locations at relative position of 90 degrees. A thread sleep

was introduced as it was discovered that when a command is sent to a joint, it wouldn’t get

to it position before another command would be sent to another joint to move, so it was

imperative to introduce a kind of delay into the system. The Threading class in C# was used

to delay the next operation hence allowing the previous command to finish all its course

before initiating the next command.

Figure 3.15: LabVIEW VI for controlling the actuator, measure resistance and read from load

sensor

3.6.3 PHASE 2 - RACK AND CHASSIS DESIGN
Referring to figure 3.14, we designed the rack and chassis to specification with dimensions.

Also the whole project was simulated using 3D Max Studio. The result of the simulation was

also shown in figure 3.14

3.6.4. DETERMING WHEN THE BEAM REACHES BREAKS
As at the time of writing this report, I don’t have a definite way of knowing when the beam

reaches a limit where it is no longer ideal for the experiment. Maybe using a kind of sensor,

or determined from software. This portion of the work would be considered latter. So right

now it would be hardcoded into the program that when the load reaches a particular limit,

the robot arm should swing into action before the next specification to replace the beam.

3.6.5. PHASE 2 - LAB CLIENT DEVELOPMENT
Lab Client was developed using Adobe Flex, a programming platform for creating rich

internet applications (RIAs). An interface with control for specifying the value of force the

user wants to apply on the SUT. Also, a video feed was incorporated into the client program

so as to show the user what is happening at the location of the remote lab, allowing the user

to see how the “robot” configures his experiment. By this we believe we would have

succeeded in removing all doubts by the student as to whether it is a real lab or simulation

thus helping the student to have maximum user experience. The Lab client allows the user to

specify the force to be applied in either metric or imperial unit, and forward it to the server for

execution. It has a unit converter for converting force and length from one standard to another. A

quick help section for hints about the lab. The client makes a connection to the server via the service

broker web service and it consequently submits the specification to the lab server. The lab server

executes the experiment and returns the deflection value to the lab client when ever it requests for it.

The deflection would be shown a dial guage so the student can measure the deflection by reading off

its value from the dial gugae. This in a way improves the pedagogics of the experiment as in a real

laboratory the student would most probably use a dial guage and not a digital meter.

The video feed is a live stream of the activities on the lab server streamed live from the server. The

Adobe Flash Media encoder was used for capturing and streaming the video to a server which is the

Adobe Media Server Development edition. The Lab client streams directly from this server. A snap

shot of the lab client is shown in figure 3.16 and the flash media encoder with the adobe media

server in action in 3.17

Figure 3.16: The Static Bending Test Lab Client Interface

Figure 3.17: Showing the Adobe Media Server administrator console with the adobe flash media

encoder

3.6.6. PHASE 2 - THE EXPERIMENT EXECUTION ENGINE
The experiment execution engine is a C# program that controls the execution of the experiment.
When experiment is forwarded to the lab server for execution from the service broker, it goes directly
to the lab server database (a MS SQL database). The experiment engine which is always polling the
database every 2 seconds, retrieves any new experiment, deserializes it (as the experiment
specification is in xml format) and extracts the force specified by the student. This force value is
forwarded to the LabVIEW VI using a dll as the entry point. A dll was created from the LabVIEW VI
and this allows a C# program to call the required LabVIEW function based on the argument specified
in the dll. The method allows us to specify whether we want the LabVIEW to operates the actuator in
the forward, reverse or stop mode and the load specified by the student. This method is a non-void
method as it returns a value which is the resistance of the potentiometer feedback on the actuator.
This allows us after careful calibrations to get the extent of protrusions of the actuator hence the
deflection of the beam. The deflection value is serialized and converted to an xml format which is
then sent to the lab server database to be retrieved by the student when the measure deflection
button is clicked, which consequently brings up the dial gauge which shows the deflection as an
analogue value. The Figure 3.18 shows the experiment engine in action, the LabVIEW front panel that
was launched when the LabVIEW dll was called. This same program is responsible for controlling the
robotic arm. This is a separate class of which an instance of the class will be called when it’s time to
change the beam.

Figure 3.18: (a) Experiment Execution Engine (b) LabVIEW front panel called by the LabVIEW dll

APPENDIX I

SCREENSHOT OF THE PROTEUS SIMULATION OF THE MICROCONTROLLER CIRCUIT

APPENDIX II

Source Code for Linear Actuator System PIC C using CCS compiler

<code>

#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay(clock = 20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
#include <string.h>

void main()
{
char cmd;
long deflection;
setup_port_a( ALL_ANALOG );
setup_adc( ADC_CLOCK_INTERNAL );
do
{
cmd = getc();

if(cmd == 'f')
{
output_low(PIN_B1);
printf("forward mode");
output_high(PIN_B2);
}
else if(cmd == 'r')
{
output_low(PIN_B2);
printf("reverse mode");
}
else if(cmd == 's')
{
printf("stop");
set_adc_channel(0);
delay_us(1000);
deflection = Read_ADC();
printf("nr%4Lu", deflection);
}
}while(TRUE);
}
</code>

APPENDIX III

SOURCE CODE FOR THE LOAD SENSOR – READING AND WRITING TO VIRTUAL COM PORT

Program.cs

<code>

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace SerialCom
{
class Program
{
private static int forceValue;
static void Main(string[] args)
{
Console.WriteLine("Force applied: ");
forceValue = int.Parse(Console.ReadLine());

ComCom com = new ComCom();
com.openPort();
com.writeCommand();
while (forceValue > int.Parse(com.data))
{

}
Console.WriteLine("max value attained @ "+com.data);
}
}
}
</code>

ComCom. Cs

<code>

using System;
using System.Linq;
using System.Text;
using System.IO.Ports;
using System.Timers;

namespace SerialCom
{
public class ComCom
{
private SerialPort com = new SerialPort();
public String data = "0";
public ComCom()
{
com.PortName = "COM7";
com.BaudRate = 9600;
com.DataBits = 8;
com.Parity = Parity.None;
com.StopBits = StopBits.One;
//com.ReadTimeout = 1000;

com.DataReceived += new SerialDataReceivedEventHandler(com_DataReceived);

}
public void openPort()
{
if (!com.IsOpen)
{
com.Open();
}
}
public void closePort()
{
com.Close();
}
public void writeCommand()
{
com.WriteLine("o0w0r");
}
/*
public void interact()
{
try
{
if (com.IsOpen) com.Close();
else

{
com.Open();
//com.WriteLine("o0w0r");
com.WriteLine("slcr");
tim.Enabled = true;

tim.Interval = 10;
tim.Start();
//tim.Interval = TimeSpan.FromSeconds(1.0);
//tim.Start();
//Console.WriteLine("Data = " + com.ReadExisting());
}
//com.Close();
}
catch (Exception ex) { Console.WriteLine("exception thrown @ "+ex); }
}*/
public void com_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
data = com.ReadExisting();
Console.Write(""+data+"t");
}
/*public void tim_Tick(object sender, EventArgs ea)
{
inc++;
Console.WriteLine("hey");
if (inc == 5)
Console.WriteLine("d: " + com.ReadLine());
}*/
}

}

</code>

APPENDIX IV

SOURCE CODE FOR CONTROLLING THE ROBOTIC ARM-SENDING SIGNAL TO THE AX-12 DYNAMIXEL

<code>

using System;


using System.Linq;

using System.Text;

/*Motion Controller
* Author: ISHOLA Babatunde Isaac <id>techbossmb</id>
* Description: Class for manipulating the AX-12 Robotic Arm
* Date: 10/06/2011
/*
* #1 define a simple method for basic control of the robot arm 11:11 - 12:07 am in!
* #2 (2:13 pm)synchronously writing to the RAM of the dynamixel + feedback system design
* #3 18/06/11 fixed a bug in the code and wrote the part to control two dynamixels
* # blogged @ 11:19 18/06/11 1. One of the coupled dynamixels was biased, offset
* 2. The coupled units moves in opposite directions that explains the reason why the units always
return with error.
* #4 Need to start working on the feedback 11:19
*/
namespace MotionController
{
class Program
{

static int id,id1, id2, position, position2, position1, speed;
static string cmd;
static bool inTouch = true;
static int joint;

static void Main(string[] args)
{
while (inTouch)
{
Controller control = new Controller();
//indicate program start, all 7 indicators should come on
control.onLed(254, 1);
control.onTorgue(254, 1);
Console.WriteLine("Arm Controller (TM)nType 'Start' to begin and 'Exit' to quit");
cmd = Console.ReadLine();

if (cmd == "Start")
{
//indicates intiating command
//TODO(12:11): synchronous write + action command for multiple dynamixel units
Console.Write("1 or 2?");
joint = int.Parse(Console.ReadLine());
if (joint == 1)
{
//specify id, position and speed
Console.Write("Dynamixel ID:");

id = int.Parse(Console.ReadLine());
Console.Write("Specify Position between 0 and 1023:");
position = int.Parse(Console.ReadLine());
Console.Write("Specify Speed between 0 and 1023:");
speed = int.Parse(Console.ReadLine());
//execute instructions

control.rotateOne(id, position, speed);
}
else if (joint == 2)
{
//specify ids, position and speed

Console.Write("Dynamixel ID1:");
id1 = int.Parse(Console.ReadLine());
Console.Write("Dynamixel ID2:");
id2 = int.Parse(Console.ReadLine());
Console.Write("Specify Position between 0 and 1023:");
position = int.Parse(Console.ReadLine());
position1 = position;
if (position <= 512)
{
position2 = 512 + (512 - position);
}
else if(position > 512)
{
position2 = 512-(position - 512);
}

Console.Write("Specify Speed between 0 and 1023:");
speed = int.Parse(Console.ReadLine());
//execute instructions
control.rotateTwo(id1,id2, position1, position2, speed);
}
}
else if (cmd == "Exit")
{

inTouch = false;
}
}

}
}
}
</code>

APPENDIX IV

Shots from Development Phase of the remote backend

Showing the test bench – robotic arm and linear actuator mounted on a locally fabricated
frame

Showing NI 6009 being used to acquire data from the sensors and control actuation

Report on the Strength of materials i lab

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Report on the Strength of materials i lab (20)

More from Babatunde Ishola (7)

Report on the Strength of materials i lab