Embed Size (px)
DESCRIPTION
Ishola, B.I., "On the Development of the Strength of Materials Laboratory: A Non-EE/CS iLab for Static Bending Test". Final Year Project Thesis, March, 2012
Citation preview
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)
(b)
Figure 3.2. (a) iLoad Digital USB Integrated Load Cell- load sensor (b) experiment test bench
F
R1 R2
Load Sensor
Linear Actuator
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
(a)
(b)
Figure 3.12. USB2 Dynamixel (a) Back view (b) and the front view
Serial Connector
USB Connector
3 Pin Connector 4 Pin Connector
Status display LED Function selection
switch
(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");
output_high(PIN_B1);
}
else if(cmd == 's')
{
output_high(PIN_B1);
output_high(PIN_B2);
printf("stop");
set_adc_channel(0);
delay_us(1000);
deflection = Read_ADC();
printf("\n\r%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.Collections.Generic; 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("o0w0\r"); } /* public void interact() { try { if (com.IsOpen) com.Close(); else
{ com.Open(); //com.WriteLine("o0w0\r"); com.WriteLine("slc\r"); 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.Collections.Generic;
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 control.onLed(254, 0); control.onTorgue(254, 1); //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") { control.onLed(254, 0);
control.onTorgue(254, 0); 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
