behavior based modeling at conceptual robot design …homepage.tudelft.nl/6c92j/citingmywork/tmce...
TRANSCRIPT
BEHAVIOR BASED MODELING AT CONCEPTUAL ROBOT DESIGN AND
DESKTOP DESIGN OF EDUCATIONAL ROBOTS
A MASTER’S THESIS
in
Mechatronics Engineering
Atılım University
by
MACİT ARAZ
JULY 2012
BEHAVIOR BASED MODELING AT CONCEPTUAL ROBOT DESIGN AND
DESKTOP DESIGN OF EDUCATIONAL ROBOTS
A THESIS SUBMITTED TO
THE GRADUATE SCHOOL OF NATURAL AND APPLIED SCIENCES
OF
ATILIM UNIVERSITY
BY
MACİT ARAZ
IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE
DEGREE OF
MASTER OF SCIENCE
IN
THE DEPARTMENT OF MECHATRONICS ENGINEERING
JULY 2012
i
Approval of the Graduate School of Natural and Applied Sciences, Atılım
University.
_____________________
Prof. Dr. K. İbrahim AKMAN
Director
I certify that this thesis satisfies all the requirements as a thesis for the degree of
Master of Science.
_____________________
Prof. Dr. Abdulkadir ERDEN
Head of Department
This is to certify that we have read the thesis “Behavior Based Modeling at
Conceptual Robot Design and Desktop Design of Educational Robots” submitted by
“Macit Araz” and that in our opinion it is fully adequate, in scope and quality, as a
thesis for the degree of Master of Science.
_____________________
Asst. Prof. Dr. Zühal ERDEN
Supervisor
Examining Committee Members
Prof. Dr. Metin AKKÖK _____________________
Asst. Prof. Dr. Zühal ERDEN _____________________
Asst. Prof. Dr. Bülent İRFANOĞLU _____________________
Asst. Prof. Dr. Çiğdem TURHAN _____________________
Instructor Aylin KONEZ EROĞLU _____________________
Date: 19.07.2012
ii
I declare and guarantee that all data, knowledge and information in this document
has been obtained, processed and presented in accordance with academic rules and
ethical conduct. Based on these rules and conduct, I have fully cited and referenced
all material and results that are not original to this work.
Name, Last name: Macit, Araz
Signature:
iii
ABSTRACT
BEHAVIOR BASED MODELING AT CONCEPTUAL ROBOT DESIGN AND
DESKTOP DESIGN OF EDUCATIONAL ROBOTS
Araz, Macit
M.S., Mechatronics Engineering Department
Supervisor: Asst. Prof. Dr. Zühal Erden
July 2012, 152 pages
This thesis is a research on the conceptual design of mechatronic systems. The main
objective of the research is to develop a systematic approach for behavior-based
conceptual design of mechatronic systems, with special implementation on
educational robots. In this research, Discrete Event System Specification (DEVS)
formalism and Petri Nets are used for behavioral modeling of educational robots.
Computer simulations of case studies are performed via ArtifexTM
Software
Environment. An experimental desktop design platform is also designed and
constructed for physical simulation of robot behaviors as an educational setup.
Keywords: Conceptual Design of Robots, Behavior Based Design and Modeling,
Desktop Design, Discrete Event System Specification, Petri Net, Mechatronics
Design Education.
iv
ÖZ
KAVRAMSAL ROBOT TASARIMINDA DAVRANIŞ TABANLI
MODELLEME VE MASAÜSTÜ TASARIM PROTOTIP ROBOT
GELIŞTIRILMESI
Araz, Macit
Yüksek Lisans, Mekatronik Mühendisliği Bölümü
Tez Yöneticisi: Yrd. Doç. Dr. Zühal Erden
Temmuz 2012, 152 sayfa
Bu tez mekatronik sistemlerin kavramsal tasarımı üzerine yapılmış bir araştırmadır.
Araştırmanın temel amacı, mekatronik sistemlerin davranış tabanlı kavramsal
tasarımı için, özellikle eğitim amaçlı robotlarda uygulamaya yönelik sistematik bir
yaklaşım geliştirmektir. Bu araştırmada eğitim robotlarının davranış modellemesi
için Ayrık Olay Sistem Spesifikasyonu (AOSS) ve Petri Ağları kullanılmıştır. Örnek
olayların bilgisayar simülasyonları ArtifexTM
yazılımı ile gerçekleştirilmiştir. Bu
çalışmada ayrıca robot davranışlarının fiziksel simülasyonu için eğitim amaçlı bir
düzenek olarak, deneysel bir masaüstü tasarım platformu da tasarlanıp üretilmiştir
Anahtar Kelimeler: Robotların Kavramsal Tasarımı, Davranış Tabanlı Tasarım ve
Modelleme, Masaüstü Tasarım, Ayrık Olay Sistem Spesifikasyonu, Petri Ağları,
Mekatronik Tasarım Eğitimi
v
To
My Parents, My Family
And
Peoples of Anatolia and Azerbaijan
vi
ACKNOWLEDGMENTS
I would like to express my sincere appreciation to my supervisor Asst. Prof. Dr.
Zühal Erden for her guidance and insight throughout this research. I would also
thank to Prof. Dr. Abdulkadir Erden for his valuable advices and to Instructor Aylin
Konez Eroğlu for her contribution in some of the case studies. My special thanks are
for the technical and mental assistance of Cahit Gürel, Emre Güner, Doğan Urgun,
Meral Aday, Handan Kara, Mehmet Çakmak and all staff in the Mechatronics
Engineering Laboratories and machine shop.
This research is conducted with the support of ATILIM University Research Grant
(Project NO: ATU-BAP-1011-07, Project Title: “Behavior Based Modeling at
Conceptual Robot Design and Desktop Design of Educational Robots”).
Also to my wife, Huriye, I offer sincere thanks for her continuous support and
patience during this period.
vii
TABLE OF CONTENTS
ABSTRACT ............................................................................................................. iii
ÖZ …...................................................................................................................... iv
DEDICATION........................................................................................................... v
ACKNOWLEDGMENTS ...................................................................................... vi
TABLE OF CONTENTS ....................................................................................... vii
LIST OF APPENDICES……………………………………………………………...x
LIST OF TABLES .....................................................................................................xi
LIST OF FIGURES ................................................................................................. xii
LIST OF ABBREVIATIONS.................................................................................. xvii
CHAPTER
1. INTRODUCTION ................................................................................................ 1
1.1. Conceptual Design: An Overview……………………………………….1
1.2. Objective and Scope of the Thesis……………………………………….3
2. LITERATURE SURVEY ......................................................................................5
2.1. Engineering Design: Systematic Approaches and Design Models……....5
2.2. Discrete Event System Specification (DEVS)…….................................11
2.3. Petri Net Formalism………………………...…………………………..12
3. BEHAVIOR BASED MODELING FOR CONCEPTUAL ROBOT DESIGN…16
3.1. Systematic Approach for Behavior Based Modeling...............................16
3.2. Functional Decomposition.......................................................................18
viii
3.3. Discrete Event System Specification Model…………...........................19
3.4. Petri Net Model ………………………………………………………..22
3.5. Desktop Design Model……………………...……….…………………22
4. CASE STUDIES..................................................................................................28
4.1. Case Study 1: Curve Following Robot ................................................ 28
4.1.1. Functional Decomposition for the Curve Following Robot….28
4.1.2. Discrete Event System Model of the Curve Following
Robot………………………………………………………………...29
4.1.3. Petri Net Model of the Curve Following Robot………………31
4.1.4. Simulation of Petri Net Model for the Curve Following
Robot………………………………………………………………...35
4.1.5. Desk Top Design of the Curve Following Robot……………..37
4.1.6. Form-Integrated Model (Prototype) of the Curve Following
Robot………………………………………………………………...38
4.2. Case Study 2: Walking Dog Robot….……………………………...…..39
4.2.1. Technical Specifications of the Model…………………….….39
4.2.2. Petri Net Model of the Dog Robot……………………………40
4.2.3. Simulation of the Petri Net Model………...………………….43
4.3. Case Study 3: Climbing Cockroach Robot…………………….……….45
4.3.1 Technical Specifications of the Model…………………….…..45
4.3.2. Petri Net Model of the Cockroach Robot………………….….46
ix
4.3.3. Simulation of the Petri Net Model for the Climbing Cockroach
Robot………………………………………………………………...48
4.4. Case Study 4: Pick Packing Automated Guided Vehicle……………....49
4.4.1. Functional Decomposition for PP-AGV……………………...50
4.4.2. Discrete Event System (DEVS) Model of PP-AGV…………..50
4.4.3. Technical Specifications of the Model………………………..51
4.4.4. Petri Net Model of PP-AGV in ArtifexTM
Environment….…..54
4.4.5. Desktop Design of PP-AGV…………………………..…..….58
4.5. Case Study 5: Frog-Like Robot………………………………………...59
4.5.1. Step 1: Functional Decomposition for Frog-Like Robot…......59
4.5.2. Step 2: Discrete Event System Model of Frog
Robot………………………………………………………….…......61
4.5.3. Step 3: Petri Net Model of Frog-like Robot in ArtifexTM
Environment…………………………………………………………63
4.5.4. Desktop Design for Frog Robot……………………………....71
5. DISCUSSION, CONCLUSION AND FUTURE WORK…………………….….74
5.1. Discussion…………………………………………………………...….74
5.2. Conclusion……………………………………………………………...75
5.3. Future Work…………………………………………………………….75
REFERENCES ........................................................................................................77
x
LIST OF APPENDICES
APPENDIX
A. Description of ArtifexTM
Software.......................................................................82
B. The Report Created For Curve Following Robot by Documentation Tool of
ArtifexTM
Software………………………………………………………….……….95
C. Processor Codes………………………………………………………………...125
xi
LIST OF TABLES
TABLE
3.1 Event Descriptions for DEVS Formalism……………………………………….21
3.2 Mechatronic Components Used in the Desktop Design Platform………………23
4.1 Number and Color Codes for the Curve Following Robot’s Petri Net Model
Simulation…………………………………………………………………………...36
4.2 Behaviors of Curve Following Robot in Different Modes……………………...37
4.3 Time Data for a Measurement Session…………………….……………………45
4.4 States and Events in the DEVS Model of the Pick Packing AGV………………52
4.5 Durations for the Pick Packing AGV’s Travelling Tasks……………………….54
4.6 Number-Color State Codes for PP-AGV...……………………………………...57
4.7 Intervals of Environmental Signals for Behavioral Modes of Frog Robot……...64
4.8 Coding For Frog Robot Organ Behaviors in Different Modes….………………65
4.9 Behaviors of Frog Robot’s Desktop Design Model……………….…………….73
A.1 Explanation for some of icons on the ArtifexTM
Model Manager’s
Toolbar…….…………………………………………………………….…………..84
A.2 Explanation for Tool Icons on Drawing Tool Bar of ArtifexTM
Model Editor
Window……………………………………………………………….……………..87
xii
LIST OF FIGURES
FIGURES
2.1 A Simple Sample Petri Net……………………………...………………………14
2.2 Firing a Transition………………………………………………………….……15
3.1 Process Flow in the Suggested Systematic Approach for Behavior Based
Conceptual Robot Design………………………………………………….………..17
3.2 Algorithmic Scheme for Systematic Behavior Based Conceptual Robot
Design……………………………………………………………………………….18
3.3 A General Illustration of Functional Decomposition…………..……………….19
3.4 A Representation of DEVS Formalism……………………………………...…..19
3.5 DEVS Model For a Mechatronic System ……………………………...……….21
3.6 A view of Micro Servo...………………………………………………………..24
3.7 A view of Servo Motor……...…………………………………………………..24
3.8 A view of Arduino Uno……...………………………………………….………25
3.9 A view of CMUCAM1……………………...…………………………….…….25
3.10 SHARP Distance Sensor…………………………………………………….…26
3.11 Force Sensing Resistor…………………………………………………….…...26
3.12 Technical Drawings of Figurative Links Mounted on Mini Servo
Motors………………………………………………………………………….……26
3.13 General Appearance of the Desktop Design Platform…………………………27
3.14 Desktop Design Models of a Frog-Like Robot and an AGV…………………..27
xiii
4.1 Functional Decomposition of a Curve Following Robot …………………….…29
4.2 DEVS Model for the Operational Behavior of Curve following Robot…...……30
4.3 Architecture of the Petri Net Model ……………………………………….........31
4.4 Top Level Page of the Petri Net Model Created in ArtifexTM
Environment………………………….…………………………………………..….31
4.5 Petri Net Structure of the Power Source Unit……………………………......….32
4.6 Petri Net Structure of a Sensor Unit……………………………………...….….33
4.7 Petri Net Structure of Processor Unit of the Designed Model in ArtifexTM
Environment…………………………………………………………………..……..34
4.8 A Predicate Window of Transition………...……………………………………34
4.9 Petri Net Structure of a Wheel/Motor Unit………………………………….…..35
4.10 Screenshot of the Graphical Simulation of Curve Following Robot……….….36
4.11 Graph of Three Measures for Curve following Robot…………………………37
4.12 A view of Desktop Design of Curve Following Robot…………………...……38
4.13 Form-Integrated Model of Curve Following Robot……………………………39
4.14 Experimentally Obtained Real Time Schedule and Leg Positions of Walking
Dog…………………………………………………………………………………..40
4.15 Architecture for the Dog Robot Model……………………………….………..40
4.16: Top Level Petri Net Model of Dog’s Walking Behavior……………...………41
4.17 Petri Net Structure of Dog’s Brain Unit Constructed in Artifextm
Environment…………………………………………………………………………41
4.18 Petri Net for the Left Foreleg of walking Dog Robot…...……………………..42
xiv
4.19 Screenshot of the Graphical Simulation of the Dog’s Walking
Behavior…………………………………………………………………….……….43
4.20 Measurement Chart for a Dog’s Walking Behavior…………………...…........44
4.21 Climbing Rhythm of the Cockroach…………………………………...………46
4.22 Top Level Petri Net Model of the Cockroach Robot’s Climbing
Behavior……………………………………………………………………………..47
4.23 Petri Net Structure of the Cockroach’s Brain Unit…………………………….47
4.24 Petri Net Structure of the Cockroach’s Leg Unit………………………………48
4.25 A Screenshot of the Model Simulation…………………………………...……48
4.26 Traveling Map of Pick Packing AGV………...………………………..……....49
4.27 Functional Decomposition for a Pick Packing AGV…………………………..50
4.28 Pick Packing AGV-DEVS Model……………………………………………...51
4.29 Schematic Representation of the Pick Packing AGV………………………….53
30 Top Level Behavioural Model in ArtifexTM
Environment………………………54
4.31 Petri Net Structure of Processor Unit for PP-AGV..…………………………..55
4.32 Petri Net Structure of Left Wheel Unit………………………………..….……56
4.33 C-coding in Action part of Transition “L” in Left Wheel Unit………...….......56
4.34 A Screenshot of the AGV’s Petri Net Model Simulation...……………………57
4.35 A view of Desktop Design for PP-AGV…………...…………………………..58
4.36 Engineering Drawings for the Figurative Parts of PP-AGV …….………...…..59
4.37 Functional Decomposition of a Frog………………….…….…………………60
xv
4.38 Refined Function Decomposition of Frog-Like Robot………………….……..61
4.39 DEVS Model of Frog Robot…………………………………………...………62
4.40 Top Level Page of the Frog Robot’s Petri Net Model Created in Artifextm
Environment…………………………………………………………………....……63
4.41 Welcome Massage at the Beginning of the Simulation of Frog Robot....…..…65
4.42 Simulation and I/O Screen for Frog Robot...…………………………….…….66
4.43 Petri Net Structure of the Head Unit of Frog Robot ……………………….…...66
4.44 Petri Net Structure of the Frog Robot Brain….…………………………...…...68
4.45 C Coding In Action Part of the Transition SENSE_SIGHT…………………...68
4.46 C Coding in Predicate part of the Transition FRIGHTENED…………………68
4.47 Screenshot of Brain’s Simulating……………………………………….…..…69
4.48 Petri Net Structure of the Neck………………………………………………...70
4.49 Petri Net Structure of the Front Leg………………………………………...…70
4.50 C Codes in Action Part of Actuating Transitions…………………...…………70
4.51 A view of Desktop Design for Frog Robot………………………...…………..72
4.52 Engineering Drawing for the Figurative Legs of the Frog Robot………….......72
A.1 Startup Dialog Window…………………………………………………….…..82
A.2 create New Project Dialog Window ……………………………………...…….83
A.3 ArtifexTM
Model Manager Window………………………………………….…83
A.4 ArtifexTM
Model Editor Window………………………………………….……85
A.5 ArtifexTM
Model Window………………………………………………………88
xvi
A.6 Place Properties Dialog Window……………………………………..…...……88
A.7 Transition Properties Dialog Window……………………………..……...……89
A.8 Transition Properties Dialog Window-Predicate Section………………...…….89
A.9 Transition Properties Dialog Window - Action Section…………………..……90
A.10 Transition Parameters Dialog Window - Description Section……….……….90
A.11 ArtifexTM
Validate Window…………………………………………..….……91
A.12 ArtifexTM
Validate Toolbar…………………………………………….….…..91
A.13 Run Parameters Window………………………………………………….…..91
A.14 ArtifexTM
Validate Window and I/O Page of the Simulator………….……….92
A.15 ArtifexTM
Batch Run Tool Window…………………………………….……..92
A.16 ArtifexTM
Measure Tool Window……………………………………….…….93
A.17 ArtifexTM
Report Window…………………………………………………….94
xvii
LIST OF ABBREVIATIONS
CAD - Computer Aided Design
DEVS - Discrete Event System Specification
AGV - Automated Guided Vehicle
FM - Functional Modeling
FBS - Function Behaviour State
B-FBS - Function Environment Structure
MEMS - Micro Electromechanical Systems
UML - Unified Modeling Language
SysML - Systems Modeling Language
PNDN - Petri Net Based Design Network
1
CHAPTER 1
INTRODUCTION
Engineering design is a mapping of functional description of a product into a
physical description that would be able to perform functions to fulfill customer
needs. The designer must determine how this transformation occurs by specifying the
physical components and processes for executing the required function(s) of the
product. Global competition is creating pressure on industry such that companies are
forced to agile enough by minimizing the time of bringing new products and their
variants into the market.
The need for increased complexity and agility in product development results in
changes in the way that products are designed and produced. Design research is
forced to develop more efficient, creative and innovative engineering design
approaches. Companies encourage design teams to reduce the product development
lead time which is mainly determined by the time spent for conceptual design,
particularly for innovative and interdisciplinary products [1]. It is also estimated that
most of the lifecycle cost of a product is determined by the conceptual design [2, 3].
Importance of conceptual design in product development has resulted in considerable
effort in design research to reduce the time and cost during this stage.
1.1. Conceptual Design: An Overview
Conceptual design is an early stage of product development process and involves
high degree of uncertainty at an abstract level [4]. Conceptual design engages in
selecting concepts to solve a given design problem and deciding how to interconnect
these concepts into an appropriate system architecture. Conceptual design phase
involves development and evaluation of concept variants [5, 6] with proper function
structures and behaviors. These functions and behaviors are elaborated towards a
well-defined engineering system in detailed design phases and corresponding
physical behaviors are structured at the end of the complete design process. In order
to reduce the time spent in conceptual design, the main requirement is to develop and
evaluate a number of concept variants in a shorter lead-time using computational
design support.
2
Although computer aided design (CAD) has a great impact on the way that engineers
design products in the last few decades, existing CAD systems are mainly developed
toward embodiment and detailed design phases, graphical representation, geometric
modeling and analyses [3]. The abstraction and uncertainty of the conceptual design
make current CAD systems difficult to use for conceptual design. Conceptual design
is mainly driven by human intelligence, experience and engineering creativity.
Therefore, development of computational design support tools for conceptual design
is very difficult. Regardless of this difficulty, valuable scientific research has been
carried out to contribute to the development of computer-based support environments
for conceptual phase of product design.
A significant problem in computational support for conceptual design is the
systematic representation and evaluation of concept variants. This is not an easy task
because during this early phase, designers mainly deal with abstract, conceptual and
symbolic artifact descriptions. It is emphasized that a cheap, fast and reliable way of
evaluating concept variants for a design artifact is to make its virtual prototype as a
computational design support tool using behavioural modelling techniques [7-9].
Behavioural models and their software implementations allow designers to represent
concept variants and to analyze, compare and evaluate their possible behaviour at an
early design stage.
Being a type of multi-domain problem, conceptual design of mechatronic systems
needs a special design philosophy which is different than conventional single-domain
engineering design problems simply because of the need for integrating several types
of energy behaviors in a physically integrated system [10, 11]. Multi-domain design
is difficult because such systems tend to be very complex and most current
simulation tools operate over a single domain [12]. Multi-domain design philosophy
supports the necessity for an intensive interaction and integration between different
engineering disciplines in order to develop efficient, compact, precisely-controlled,
task repeatable, reliable, re-programmable and flexible (multi-purpose) products. The
key property of mechatronics is the integration of the mechanical, electronic,
software and control engineering fields starting from the early design stages,
particularly at the conceptual design stage. Modeling possible behaviors of an artifact
3
in conceptual design is an important research field in terms of developing product
behavior simulation and computer–aided conceptual design tools.
1.2. Objective and Scope of the Thesis
The objective of this thesis is to develop a systematic conceptual design approach for
multi-disciplinary mechatronic systems based on the representation of the intended
behaviors of design concepts. The research aims at computer modeling and
simulation for these behaviors as well as implementation of the simulated behaviors
on a distributed physical desktop design setup. This study works on a state-based
behavioral representation and modeling scheme to contribute systematic conceptual
mechatronic design.
Behavior of a mechatronic system is composed of both discrete and continuous
characteristics and evolution. Since the current research is focused on representing
behaviors at an abstract level in conceptual design, only the discrete evolution is
considered. Discrete Event System Specification (DEVS) formalism [13] is used to
represent interactions between various organs of a mechatronic system. These
interactions take place by changes in states by the occurrence of discrete events. In
order to construct a basis for DEVS model, the suggested systematic approach uses
functional decomposition, which is a method of dividing an overall function of a
design artifact into several sub-functions in a hierarchical way. DEVS model is
implemented for simulation using Petri Nets [14, 15] via ArtifexTM
Graphical
Modelling and Simulation Software.
Scope and main focus of this research is the behavioral representation of laboratory
level educational robots during their conceptual design. The suggested design
approach is called Systematic Approach for Behavior Based Modeling in Conceptual
Robot Design. In this thesis, five case studies are performed for behavioral
representation and simulation of laboratory level educational robots as a testing
platform for the systematic approach. These case studies are “Curve Following
Robot”, “Dog Robot”, “Cockroach Robot”, “Pick-Packing Automated Guided
Vehicle (AGV)” and “Frog Robot”. The developed systematic approach for
behavioral based modeling of educational robots is focused on conceptual phase and
as a result, physical prototyping the designed artifacts (robots) is not covered by the
4
scope of this research. However, a distributed physical environment with necessary
components is also designed and constructed for physical implementation of
simulated robot behaviors, independent of any geometric and dynamic parameters.
This physical environment is called “Desktop Design Setup”.
The remainder of this thesis is organized as follows: Chapter 2 is a literature survey
on modeling for conceptual design with particular focus on mechatronic design.
Chapter 3 explains the suggested systematic approach for behavioral modeling of
educational robots. Chapter 4 describes the details of case studies carried out within
this research. Finally, Chapter 5 includes discussions, conclusions and suggestions
for future research.
5
CHAPTER 2
LITERATURE SURVEY
Over the past few decades, various design methods and systematic approaches have
been developed to contribute engineering design research [5, 6, 16-18]. Design
processes are described by these methods and approaches while they are composed
of several phases. Main design phases are accepted as clarification of the need,
establishing product specifications, conceptual design, embodiment design, detailed
design, design documentation and manufacturing.
2.1. Engineering Design: Systematic Approaches and Design Models
Functional modeling (FM) is one of the most significant methods for systematic
conceptual design. Functional modeling (FM) is the name given to the activity of
developing models of devices, products, objects, and processes based on their
functionalities and the functionalities of their subcomponents [19]. Until 2000s, three
main functional modeling approaches were developed as “functional decomposition
and mapping”, “input-output synthesis” and “behavior-assisted synthesis” [20].
While the first is a top-down approach the two others can be executed either in top-
down or in bottom-up manner. Literature survey shows that these three approaches
also continue in conceptual design research after 2000.
In functional decomposition, the intended overall function is divided into smaller
lower sub-functions and it is represented by a functional hierarchy. Function to
structure mapping identifies physical structures to achieve sub-functions at different
levels of the functional decomposition hierarchy. The research activities that have
taken place in this ground are made toward definition of function [21], development
of functional prototype scheme using Function-Behavior-State (FBS) modeling for
representing design knowledge [22], development of functional design
methodologies using behavior-driven function-environment-structure (B-FES)
modeling framework [23, 24]. In the recent years evaluation of materials at an early
design phase has become an important topic and function-structure-material mapping
in functional modeling become a key research subject [25]. Input-output synthesis is
6
based on representation of the required function using an input-output transformation
scheme in the form of “generally valid functions” [5]. A design language called a
functional basis has been developed by the help of Input-Output synthesis, where
product function is characterized in a verb-object (function-flow) format to
comprehensively describe the mechanical design space [26-28]. Functional basis also
are utilized to characterize biological systems for enabling the development of a
function-based design repository for bioinspired design [29]. Bond graph modeling
also is another method used for input-output synthesis to develop design repositories
[23] and design representation schemes [24]. Bond graph approach has been a tool
for development of Schemebuilder system [30] which is used for qualitative
generation of alternative design schemes, which found a wide application area in
mechatronic design. Behavior-assisted synthesis can be used for two approaches of
functional modeling, function-behavior-structure mapping and the second direction
that is related with reasoning and decision making for functional decomposition
during conceptual design. The first deals with the determination of physical
structures that can be used to accomplish the required functions via proper behaviors.
It also conducts with the design artifact (future product), whereas the second is
towards the design process. Structure-behavior-function (SBF) modeling language
has been developed for the model of complicated engineering systems by the help of
teleological modeling [31].
Technological progresses and the competitive global market conditions led design
researches to take part in automation of conceptual and embodiment design
increasingly from the middle of 2000s. One of the essential recent works is the
development of a computational methodology as a formal language for generating
design configurations (form) from a functional description [32]. This methodology
founds its basis in empirical analysis of consumer products and grammar rules are
created to capture feasible mappings from function to product form. Agent
technology is used to develop a framework for guiding the conceptual design of
mechanical products [2, 3]. In this approach, first, the functional parameters and
design variables are given by analyzing mechanical product design requirements and
a behavioral matrix model is proposed by using Bond graph fundamental elements.
Then, an agent-based framework is prepared to solve behavioral matrix model,
7
realizing effort-flow transforming operations to produce function-means tree and
multi-solutions and making further evaluation with the aid of agent-technologies.
Ontology-based modeling of physical systems is studied to make possible
engineering knowledge management of functional knowledge [33, 34]. This study
presents an ontological modeling framework that implements semantic constraints.
Ontological modeling is also used in another study [35] which introduces the
semantic structure for design representation as a port ontology. The
conceptualization of parts is formalized by the ontology in a way that engineers and
computer aided designers can work on component connections and interactions in
system configuration. Making design alternatives in sense of configurations of port-
based objects is useful at the conceptual design stage when the geometry and spatial
layout is still not defined properly. At this point, generating the system architecture is
so important and this architecture can be captured conveniently as a hierarchical
configuration of port-based interfaces.
A major part of the systematic conceptual design mentioned, are about development
of methods and models for mechanical products. Due to technological progresses and
market conditions, at the end of the 20th century mechatronic design became an
important multidisciplinary design philosophy [36]. Hence, mechatronic systems
became a major application filed for systematic conceptual design research.
Mechatronic systems are multi-domain problems, and that is why conceptual design
for them needs a special design view which own different aspects than conventional
single-domain engineering design problems due to the need to integrate the several
distinct domain characteristics in predicting system behavior. A good mechatronic
design has to deal with mechanical, electronic, software and control items in the
same time starting from early design phases, particularly conceptual design [36, 37].
Even an identification of the design needs requires mechatronic approaches in
successful designs. Mechatronic concepts have wide implementation interval from
the identification stage of the needs down to the physical embodiment. This diffusion
is achieved through functional and behavioral synergy, which can be accomplished
through the development of concept variants on a functional basis and formal
representation of their behavior during the conceptual design stage, regardless of any
physical structuring.
8
Complexity of multi-domain designs makes it more difficult while most current
simulation tools operate over a single domain [12]. Multi-domain design requires
intensive interaction and integration between different engineering disciplines in
order to develop efficient, compact, precisely-controlled, task repeatable, reliable, re-
programmable and flexible (multi-purpose) artifacts. Multi-domain philosophy
becomes more challenging, because most modern modeling and simulation tools for
representation at a schematic, or topological, level are optimized for a single domain
[38].
There are two major integration types within a mechatronic system [39]; integration
of components (hardware integration) and integration by information processing
(software integration). Integration of components defines spatial integration which
includes embedding sensors, actuators and microprocessors into the mechanical
functions. Integration by information is mainly based on advanced control functions
and information processing of direct measurable input and output signals with
intelligent features and decision making abilities under uncertainty.
Determining one of these domains to solve the portions of a considered engineering
design problem at early stages of designing process is so important. To achieve the
overall task in an optimal way, it should be decided that which parts should be
designed as mechanical subsystems, which should be electronic, where actuators and
sensors should be located, and how these subsystems should combine. However, this
ideal integrated design philosophy is still not formally carried out in practice because
of the lack of system-level support for mechatronics conceptual design.
Three reasons should be considered; first, design processes in different engineering
disciplines have particular different aspects. Second, there is a lack of concurrent
design process across mechatronic subsystems. Third, there is the challenge of
exploring various design alternatives automatically and creatively. Despite the fact
that computers have definite advantages over humans such as better memory,
accuracy, speed, and storage capability, their inability to make informed and intuitive
decisions causes many to believe that they are not capable of embodying the
innovative process of design synthesis.
9
While different engineering domains can be described using different model
representations, for mechatronic product design which involves multiple domains, a
unified formal model representation is more desirable [40]. A mechatronic system
brings together various domains as mechanical, electrical and electronic subsystems,
generally with a micro-processing control subsystem. Within an interdisciplinary
point of view all subsystems have equal weight during the design process, regardless
of its physical nature. Achieving this goal has some difficulties if standard design
tools are used, but it is essential to obtain good results [41].
Most of the research on modeling conceptual design of mechatronic products
involves theoretical and methodological studies. In these studies modeling methods
are investigated at an abstract level and their application to specific cases. Engineers
of different disciplines working in the same design team have to communicate and
cooperate with each other on various issues [19]. But the solution to “how to bridge
the multitude of models required to support a complex design” is not trivial. FM,
being a common representation framework above the single domains, provides
means of communication among the engineers of different disciplines.
Some successful high level behavioral modeling and simulation tools are developed
for computational design support for multi-domain systems. As mentioned befor
Bond graph is one of the powerful tools developed for modeling [42]. Bond graph
provides a unified model representation across interdisciplinary system domains.
Schemebuilder is a well-known important project which represents designs as
schemes structured based on the Function/Means tree approach and simulations of
these designs are performed by the help of a partially Bond graph based ontology
[30,43]. Schemebuilder uses Dymola which has been developed for modeling and
simulation of the dynamic behavior of complex engineering systems [44, 45]. One of
the other tools developed to model and simulation in advance level is MathModelica
[46]. These tools are based on an a object-oriented modeling language, called
Modelica [47,48]. Modelica is designed for component-oriented modeling of complex
physical systems.
The Bond graph, which is a domain-neutral formal schematic paradigm, is widely
known for representation and analysis of energetically coupled physical systems.
10
Exploring multiple design choices for passive mechatronic systems combining bond
graphs and genetic programming has been initiated and explored for design of analog
filters, printers, micro-electromechanical systems (MEMS), and so forth [12, 38, 49].
Focal point of the research is the detailed design of mechatronic systems and its
strategy is to develop an automated procedure capable of exploring the search space
of candidate mechatronic systems and providing design variants that meet desired
design specifications or dynamical characteristics. This research has suggested a new
automated approach for synthesizing designs for mechatronic systems. Utilizing
genetic programming as a search method for competent design and the Bond graph
as a representation method, we have created a design environment in which open-
ended topological search can be accomplished in an efficient semi-automated way
and the design process thereby facilitated.
A useful extension to the more traditional evolutionary algorithms, coevolution, is
applied to this study, based on the previously mentioned work and inspired by
symbiosis phenomena from nature. This approach cooperatively evolves mechatronic
subsystems in parallel, and generates alternative design concepts that are comparable
or even superior to those generated using conventional methods. This approach
offers more flexibility and better performance. This study suggests an integrated
system-oriented coevolutionary synthesis approach for open-ended mechatronics
design using Bond graphs. A mechanism for bridging the various grounds of
mechatronics design with computational capabilities is offered by bringing together
Bond graphs and genetic programming. To progress this approach is a serious
research field ahead. However Mechatronics design is a mutli-disciplinary field, the
conceptual design stage with Bond graph modeling only considers energy flows and
signal flows. At the detailed design level, the design process should be accomplished
in the context of global optimization with multidisciplinary constraints and multiple
objectives, for more realistic implementation and economic trade-off analysis [40].
State and state transition structures approaches of information system modeling can
be used to model the information flow in mechatronic systems. Unified Modeling
Language (UML) is one of the most important methods is used together with Bond
graphs for integrated design of mechatronic systems [41]. UML is also used to model
physical components interchanging energy together with software components
11
interchanging data and to develop databases which can be used for the integrated
design of mechatronic systems [50]. Conceptual modeling of a specific product type
is another application case for UML which is applied with a specific application
language SysML [51]. Other modeling frameworks to support conceptual design of
mechatronic products considers “use processes”, “multiple-interaction states” and
product-human-environment interaction[52-54].
Research studies were carried out to develop a Petri Net based model for simulating
the behavior of concept variants to contribute the modeling and simulation of multi-
disciplinary designs at the early conceptual level. As the first step of the research, the
PNDN-Petri Net Based Design Network was developed [55]. PNDN is used to
model the information flow through the functions of an intended design. It uses a
Petri Net-based formalism leading to the representation of the artifact’s logical
behavior independent of any physical realization. This allows designer to use PNDN
for multi-disciplinary design philosophies such as mechatronic design.
In recent years, Discrete Event System Specification (DEVS) and Petri Net
formalism together are finding application in state-based mechatronic system
representation for educational robots [10, 11, 56]. This thesis is based on these
previous conceptual structuring for behavioral modeling of mechatronic systems
using Discrete Event System Specification (DEVS) formalism and Petri Nets for
which general descriptions are provided in the following sections.
2.2. Discrete Event System Specification (DEVS)
Discrete Event System Specification (DEVS) is a mathematical and graphical
method to model, analyze and simulate discrete event systems such as complex
manufacturing, communication, and computer systems, among others [13]. DEVS
operates at continues time base but within a specific time duration. A finite
number of events take place in this time interval and these events can change the
states of the system. Between the events, state of the system remains unchanged.
This is not same as a continuous time system, where the system state changes
continuously with time.
12
In general, DEVS is divided into two main models called atomic and coupled
models. While the atomic model describes behavior of the system, the coupled model
stands on system’s structure. Atomic model is the lowest level model of DEVS and
describes the behavior of system in terms of deterministic transitions between the
states. In other words, it describes how the inputs are put into effect and how the
outputs are generated. Higher level coupled model is a network of coupled
components, which can be either atomic DEVS models or coupled DEVS models.
Basically one has to specify two attributes of the system in the DEVS formalism, the
minor models which the entire system consists of and the hierarchy of connections
between these models. An atomic DEVS model is represented as a 7-tuple [1];
Atomic DEVS = <S, X, Y, s0, τ, δx, δy> (1)
In Equation (1),
S is a finite set of states
X is a finite set of input events. Input events are represented by “?” notation
Y is a finite set of output events which are denoted by “!”
is the initial state
τ: S defines the time lifespan of state.
is the external transition function, which defines how
an input event changes the schedule as well as a state of the system. The
internal schedule of a state s S is updated by τ(S’) if δx,(S)=(S’,1), otherwise
(i.e., δx,(S)=(S’,0)), the schedule is preserved.
is the output and internal transition function where
and denotes the silent event. The output and internal
transition function defines how a state generates an output event at the same
time, how the state changes internally.
2.3. Petri Net Formalism
Petri Nets are bipartite, directed multi-graphs which are used to model systems in
which regulated flow of objects and information occurs [14,15]. Petri Nets offers a
13
powerful modeling tool with a very wide application area. In many engineering
systems and disciplines, computer networks, communication systems, manufacturing
plants, command and control systems, real-time computing systems, logistic
networks and work flows are some of the application fields of the Petri Nets [15, 57].
Being a combination of mathematical theory and a graphical representation method
Petri Nets is a convenient instrument for both practitioners and theoreticians.
Graphical aspect of Petri Nets provides a powerful tool for visual communication
such as flow charts, block diagrams and networks [15], while the mathematical
aspect allows one to analyze and develop a mathematical model of the system [14].
Petri Nets, as a mathematical and graphical tool, enables one to work and study
information processing systems which are described as being concurrent,
asynchronous, distributed, parallel, nondeterministic and/or stochastic [15].
Informally, Petri Net has three basic items, places, transitions and arcs. The arcs
connect the places and transitions to each other. Transitions symbolize actions or
events and places represents states or conditions to be satisfied before an action or
event can be carried out. The places may contain or may not contain tokens. The
presence or absence of a token in a place can indicate whether a condition associated
with this place is true or false [14, 15].
A Petri Net is formally defined as a 5-tuple;
N = (P, T, I, O, M0) (2)
In Equation (2);
P = {p1, p2, …, pm} is a finite set of places;
T = {t1, t2, …, tn} is a finite set of transitions, such that P∪T≠∅, and
P T=∅;
I: P×T → N is an input function that defines directed arcs from places to
transitions, where N is a set of nonnegative integers;
O: T×P → N is an output function that defines directed arcs from transitions
to places;
14
M0: P → N is the initial marking, an M dimensional vector whose
components correspond to the places
A Petri Net, N, with an initial marking of M0 is denoted by (N, M0).
Initial marking represents token distribution into the places, and distribution
expresses a state of the system.
Graphically, places are depicted by circles, transitions are depicted by bars or boxes,
arcs are depicted by arrows and the tokens are represented by dots. The arcs connect
places to transition and in the same way they can connect transitions to places.
In general, arcs are marked with their associated weights. An arc with a weight of ‘k’
can be considered as a k-way arc. Weight of an arc represents the number of tokens
transported through that arc. If an arc is directed from place P to transition T, the arc
defines place P as an input place of transition T and similarly if an arc is directed
from transition T to place P, the arc defines that place as an output place of transition
T.
Figure 2.1 illustrates a very simple Petri Net. This Petri Net can model for example,
an information processing system with input and output data. In such a case, place A
represents input data storage state of the system, place C represents output data
storage state of the system, Transition B represents processing action and the token
represents the information. If the token is conveyed to place C via transition B, it can
be said that the input information is converted to output information after processing
action. Place A is an input place of transition B, while the place C is an output place
of transition B. The weights of the arcs are ‘1’ as denoted. Place A has one initial
token as given in Figure 2.1.
Figure 2.1 A Simple Sample Petri Net
15
Transition enabling and firing in a Petri Net occurs based on the rules given as
follow:
A transition T is said to be enabled if its input places contain minimum number of
tokens that are determined by the weight of the corresponding arcs. If a transition is
enabled it can fire when a transition fires, tokens are removed from each of its input
place and token are deposited to each of its output places. The number of tokens that
will be removed or deposited are determined by the arc weights.
Figure 2.2 represents an example for firing of a transition. At the initial marking,
both P1 and P2 contain 2 initial tokens. In this case transition T is enabled and it can
fire. 1 token from P1 and 2 tokens from P2 are fetched because of weights of the arcs
A1 and A2. After firing of transition T, 3 tokens are sent to each of the output places.
Thus P3 and P4 receive 3 tokens since weight of A3 is 3 and weight of A4 is 4. But
P5 receives only 2 tokens due to weight of the arc A5.
Figure 2.2 Firing a Transition
There are various mathematical constructs in Petri Net theory [14,15]. Since this
thesis mainly concentrates on the basic modeling scheme of the theory via computer
simulation, these theoretical aspects are reserved for further studies.
16
CHAPTER 3
BEHAVIOR BASED MODELING FOR CONCEPTUAL ROBOT
DESIGN
Within the scope of this study the aim is to develop a systematic approach for
behavior based conceptual design of robots as mechatronic systems, with a special
interest on laboratory level educational robot design. There are two main objectives
which are intended to be achieved by the research. The first one is to develop a
systematic conceptual design approach on the multi-domain characteristics of
mechatronic design. This process is focused on modeling the intended behavior of
the system at a high level of abstraction so as to construct a behavioral design
framework. The second objective is to develop a desktop design platform to be used
for physical simulation of the intended operational behavior during conceptual robot
design. The suggested approach is implemented on behavior based conceptual
structuring of educational design case studies at laboratory level. The implementation
includes conceptual/computer modeling/simulation as well as physical
realization/simulation of robot behaviors on the desktop platform.
3.1. Systematic Approach for Behavior Based Modeling
The first and most abstract stage is to identify the problem and to make decision
about the overall function that is required to be performed by the mechatronic
product. It is important to elaborate and define the overall problem or required
function, because the basis of the design process is established upon the problem
definition.
In this study, a systematic approach for behavior based robot design is suggested as a
process flow as it is represented in Figure 3.1. This approach starts with the
representation of the overall function of a mechatronic system as a function structure
which is obtained by functional decomposition. Then, the intended operational
behavior of the system at conceptual design based on the function structure is
represented by using Discrete Event System Specification (DEVS) formalism. DEVS
model is then used to develop a Petri Net model for simulating the intended behavior.
After a successful simulation, a Desktop Design Model is developed to obtain the
17
operational behavior on a physical distributed desktop structure with all
mechatronic/mechanical/electronic elements and interfaces, independent of any
geometric and dynamic parameters of the system. The Desktop Design Model is
called “Desktop Prototype” and it is considered as a semi-prototype to be used for
physical simulation of the robot’s intended operational behavior. The final stage in
Figure 3.1 is denoted as “Form-Integrated Robot Model” in which a real, physical
prototype of the robot is designed and produced. Although this stage is out of the
scope of the present research, it is included in the process flow using dashed lines for
the integrity of representation.
Figure 3.1 Process Flow in the Suggested Systematic Approach for Behavior Based
Conceptual Robot Design
Engineering design is an iterative process which needs systematic evaluation at
various design phases based on feedback information. An algorithmic representation
for an ideal behavior based conceptual robot design is given in Figure 3.2. The
systematic approach for behavior based conceptual robot design illustrated in Figure
3.1 is considered as a feed forward process. This is because the research is mainly
dedicated to the representation and modeling of the behavioral aspects during
conceptual design. Evaluation of behavioral simulation and desktop prototype is
based on observation and systematic evaluation is left for further studies. Detailed
explanation for each step in the systematic approach of Figure 3.1 is given in the
following sections.
18
Start
DEVS representation of Operational Behavior
FunctionalDecomposition
Petri Net Model of Operational Behavior
Behavioral Simulation
Satisfactory?
Desktop Design Prototype
Operatespropely?
Form Design Prototype
End
No
Yes
No
Yes
Scope of the research
Scope of bahavioral representation
Figure 3.2 Algorithmic Scheme for Systematic Behavior Based Conceptual Robot
Design
3.2. Functional Decomposition
The first step of the suggested systematic approach is functional decomposition,
which is the process of dividing an overall function into smaller sub-functions in a
hierarchical function structure. Note that functional decomposition is composed of
distinguished sub-parts, independent of time or sequence entity. Therefore,
functional decomposition is different from a flow chart which expresses the sequence
of events. The main purpose of functional decomposition is to break up a large or
complex process or function into smaller and more manageable chunks. As
illustrated in Figure 3.3 in general, the overall function is divided into sub-functions.
In functional decomposition, the lower layer functions completely describe the upper
layer and the upper layer has to include all of the lower layer sub-functions. The
number of the layers and the sub-functions included by each layer can be extended
by the sense of the design aims and reasoning.
19
Figure 3.3 A General Illustration of Functional Decomposition
3.3. Discrete Event System Specification Model
The second step in the systematic approach is the development of a Discrete Event
System Specification (DEVS) model [13] for the intended behavior of the system to
accomplish the functions specified in the function structure. Due to the high level of
abstraction at conceptual design, the presented approach is based on discrete event
system modeling in which the operational behaviour is represented as a sequence of
events [10, 11, 56]. Each event occurs at an instant in time and marks a change of
state in the system. Events may possibly have a continuous evolution once they start,
but this is continuous evolution is neglected for modelling the operational behaviour
at conceptual design. The primary focus is on the beginning and the end of such
events, since ends can cause new beginnings. Figure 3.4 is a general graphical
representation of a DEVS model applicable to any system.
Figure 3.4 A Representation of DEVS Formalism
20
Operation of a mechatronic system is composed of three main states at a high level of
abstraction [10]. They are called “Perception”, “Cognition” and “Motoric Action”.
During “PERCEPTION” state, the system detects its environment to collect and
process data. In “COGNITION” state, processed data is used with proper reasoning
and decision making to respond to predictable/unpredictable changes in the
environment. “MOTORIC ACTION” is the state in which physical task execution is
performed in accordance with decision making and/or as a reflexive response to
changes in environment. In general, “PERCEPTION” is considered as the initial
state; because once the system starts its operation, it is expected to start collecting
data from the environment for processing and decision making to create a motoric
action. The environment outside a mechatronic system is defined as the physical
medium which includes the physical world, and other mechatronic/non-mechatronic
systems.
The informal description given above can be expressed formally using the 7-tuple
DEVS definition as below;
M=<S, X, Y, S0, τ, δx, δy> where,
S ={Perception, Cognition, Motoric Action},
S0=perception,
Y={!send data/info, !command to actuators},
X={?request data/info, ?reflexive action},
τ (Perception)=τ (Cognition)=τ (Motoric Action)= , namely the time domain
for the states is infinitive, meaning that states do not change unless the
occurrence of an input or output event,
The way states change under the current logic of the model –changes caused
by events- are as following;
(Perception, !send data/info) (Cognition, 1)
(Perception, ?reflexive action) (Motoric Action, 1)
(Cognition, ?request data/info) (Perception, 1)
21
(Cognition, !command to actuators) (Motoric Action, 1)
δy (Perception) = (!send data/info, Cognition)
δy (Cognition) = (!command to actuators, Motoric Action)
The formal DEVS representation of a mechatronic system at the highest level of
abstraction is shown in Figure 3.5 and event descriptions are given in Table 1.1.
Figure 3.5 DEVS Model For a Mechatronic System [10]
Table 3.1 Event Descriptions for DEVS Formalism [10]
Event Name Description Property
?request data/info Cognition requires data/info
for decision making
input event
?reflexive action an unexpected occurrence of
an event in recognized
input event
!send data/info processed data/info is sent to
cognition for reasoning and
decision making
output event
!command to actuators A command is sent to
actuators for physical task
execution
output event
22
3.4. Petri Net Model
After the development of function structure and DEVS representation of the intended
behavior, Petri Net formalism is used to implement the third step of the systematic
behavior based conceptual robot design approach. DEVS representation is used as a
basis to develop a Petri Net model of the robot’s operational behavior for simulation.
Petri Net based representation is used for several reasons. First of all, since a Petri
Net is a graphical and formal tool, it is suitable both for modeling verbal behavior
descriptions at an abstract level and for developing a formal basis that may allow
further evaluation. In addition, Petri Nets are suitable for modeling systems in which
information flow is dominant as it is the case for conceptual mechatronic design.
Thus it is possible to model a mechatronic design concept at mechatronic “organ”
level [36] for which the behavior is mainly governed by information flow. Modeling
and simulation of the robot’s behavior is performed using Petri Nets [14, 15] via
ArtifexTM
Graphical Modeling and Simulation Environment [58, 59]. The software
has the ability of C/C++ code integration with models. In addition, ArtifexTM
includes measurement and documentation tools that provide the capability of
evaluating and recording the model data. Detailed explanations of ArtifexTM
software
are given in Appendix A.
3.5. Desktop Design Model
The fourth step of the systematic behavior based conceptual robot design approach is
the development of a “Desktop Design Model” and this is the final stage as far as the
scope of this thesis is considered. Desktop design model is the pre-production phase
before the prototyping of the form-integrated robot model. The desktop design
includes all mechatronic/mechanical/electronic components of the form-integrated
model as a physical structure independent of dynamical and geometrical aspects. In
the desktop model, all components are distributed on a platform and they are
properly connected such that the simulated operational behavior can be physically
observed. The desktop design platform is developed mainly for two purposes: One of
them is to develop desktop design models for the case studies conducted in this thesis
and to observe their operational behaviors physically. The other purpose is to use the
platform as a general-purpose educational set up for undergraduate mechatronics
23
design education. The desktop design platform consists of two modules with an
identical base for each. The platform is 104 cm in length and 74 cm in width. It is
composed of a wooden inclined plane attached to a metal base and legs. The desktop
design platform uses an external DC power supply. Table 3.2 gives a list of
educational level mechatronic components mounted on the setup.
Table 3.2 Mechatronic Components Used in the Desktop Design Platform
Component name Component Type Quantity
Servo Motor SM-S4306H 7
Servo Motor SM-S4505B 2
Micro Servo Motor 9g – SG90 4
Continues Servo Motor SM-S4303R 2
Processor card Arduino Uno (including I/O shield) 2
Camera CMUCAM1 1
Breadboard 170 point 3
Sound Sensor Analog microphone amplified by OPAMP 1
Digital Buzzer Digital 1
Infrared Sensor Switch E18-D80NK 1
Distance Sensor GP2D12 IR SHARP 1
Remote Control Kit IR – Arduino compatible 1
Light Sensor Analog -Cds Photo resistor 1
Temperature Sensor Analog- linear- LM35 1
Force Sensing Resistor Square and round 2
LED White 2
Potentiometer Shaft 1
Button Digital- Arduino compatible 1
Gripper BCM Gripper with Servo 1
Brief explanations about the main components of the experimental desktop design
setup are given below;
24
Servo Motor is an electromotor that turns in accordance to PWM pulses sent to it.
Two kind of servo motors are used in this experiment; first the normal servo motor
which turns in degrees (between 0 and 180) relevant to PWM pulses it receives and
the second type is continues servo motor whose RPM speed (between 0 and 70 RPM
at 6 V) and turning side changes relevant to PWM pulses it receives. Servo motors
are used to move links in the case studies. Examples of servo motors are shown in
Figure 3.6 and Figure 3.7.
Figure 3.6 A view of Micro Servo Figure 3.7 A view of Servo Motor
Arduino Uno is a microcontroller card based on the ATmega328 processor, which
has 14 digital input/output pins, 6 analog inputs and a 16 MHz crystal oscillator. It is
powered by 7-12V input voltage.
Camera: the camera used on platform is a CMUCAM1 type camera which is an
educational level camera and can be used for basic robotic experiments such as color
and object tracking and capturing images. It takes 17 frames per-second. In general
the camera plays eye role in case studies.
Digital Buzzer: is a digital actuator which makes a typical sound when it receives
digital High pulse. Sending pulses with different time intervals, different sounds can
be produced by digital buzzer. For instance, in the frog robot which is a bio-inspired
case study buzzer is used as sound organ.
Infrared Sensor Switch: is E18-D80NK type. This is an infrared distance switch with
an adjustable detection range between 3 and 80 cm. It produces High or Low digital
pulses.
25
Sharp Distance Sensor: it is an IR distance sensor which operates at approximately
10 to 80 cm. The output is analog. Alongside camera this sensor is convenient
component to take the role of sight organ in bio-inspired robots.
Remote Control Kit: it is a kit for sending remote IR commands. The kit is
compatible to Arduino microcontroller cards.
Light Sensor: it is a light sensing resistor. The resistance of the sensor changes due to
the ambient light density and can be used as an analog sensor.
Temperature Sensor: it is an integrated-circuit temperature sensor, whose output
voltage is linearly proportional to the Celsius (Centigrade) temperature. The LM35
integrate is used in this sensor.
Force Sensing Resistor: it is a force sensing resistor. The resistance of the sensor
changes due to the force applied on the surface of the resistor and can be used as an
analog sensor. It is mostly known by FSR abbreviation. This sensor especially can
operate in behalf of touch sense.
Potentiometer: is a three-terminal resistor which can divide voltage by its changeable
resistance. Potentiometer or pot has various application fields and is an important
electronic component. Can be used to adjust voltage and as a result the output of
many electronic devices.
Figure 3.8 A view of Arduino Uno Figure 3.9 A view of CMUCAM1
26
Figure 3.10 SHARP Distance Sensor Figure 3.11 Force Sensing Resistor
LED: Light Emitted Diode; this is a well-known and widely used electronic
component and is used to produce light especially in electronic-mechatronic
applications.
Gripper: is a mechanism used to grip and transport parts, generally in robotics. The
gripper used in this experimental setup is a mechanical system actuating by a servo
motor.
The desktop design platform, in sense of appearance and part placement, is designed
in a way that is suitable for educational activities. It has an open and full view, such
that one can observe all components, interconnections and physical simulation of the
behavior. For this reason, a colorless plexiglass casing is used for servo motors and
similarly, some figurative parts are designed and attached on motors to represent the
robot links. Technical drawings of two figurative links mounted on the mini servo
motors are given in Figure 3.12.
Figure 3.12 Technical Drawings of Figurative Links Mounted on Mini Servo Motors
27
General appearance of one module of the desktop design platform is illustrated in
Figure 3.13. Two case studies are physically implemented on the desktop design
platform; these are “Pick Packing Automated Guided Vehicle” and “Frog Robot”.
Desktop design models of these case studies on the platform are shown in Figure
3.14. Implementation details of these case studies are explained in Chapter 4.
Figure 3.13 General Appearance of the Desktop Design Platform
Figure 3.14 Desktop Design Models of a Frog-Like Robot and an AGV
28
CHAPTER 4
CASE STUDIES
This chapter presents the case studies conducted for the implementation of the
behavior based modeling and design approach described in Chapter 3. These case
studies are selected as the behavior based conceptual design of educational robots.
4.1. Case Study 1: Curve Following Robot
The first case study carried out within this research is a Curve Following Robot. The
systematic approach has been pursued for this case study and desktop design of the
system is developed. Although scope of the thesis does not include development of
form-integrated robot models, such a model has also been produced for this case
study from the point of the integrity of the work.
4.1.1. Functional Decomposition for the Curve Following Robot
Curve Following Robot is a car-like robot which follows a curved black line on a
white ground. In order to start up the behavioral design approach the overall function
of a Curve Following Robot is divided into two main sub-functions as “Going on
Straight Line” and “Following a Curved Line” as represented in Figure 4.1. The
Curve Following Robot turns left or right when it detects a curved line. The robot
moves straight if there exists no line or the line is straight.
The function of “Going on Straight Line” explains a situation in which robot does
not turn and the wheels take the robot straight forward permanently. The sub-
functions describe the course of changing electrical energy into mechanical energy
and transmitting the mechanical energy to the wheels.
The second main function “Following a Curved Line” describes a case in which the
machine detects a curved line and begins to turn right or left by a permanent
feedback correction mechanism. The robot has to control the route in a very small
time interval so as to be able to follow the path consistently. As illustrated in Figure
4.1, the robot is to check the line frequently whether to produce a turning command
or to go straight. When the robot produces a command, it checks the line after a
29
while again and produces a new command. This process continues until the robot
stops when the end of the route is detected.
Figure 4.1 Functional Decomposition of a Curve Following Robot
4.1.2. Discrete Event System Model of the Curve Following Robot
Discrete Event System (DEVS) model for the behavior of a car-like Curve Following
Robot is based on its functional decomposition. Figure 4.2 represents DEVS model
of its operational behavior which would be able to perform the functions given in
Figure 4.1.
Seven states constitutes DEVS model of the Curve Following Robot, which are
called “Full Stop”, “Idle”, “Sensing”, “Forward”, “Turn Left”, “Turn Right” and
“Stop”.
30
Figure 4.2 DEVS Model for the Operational Behavior of Curve following Robot
The initial state of the model is the “Full Stop” state. Occurring an input event,
namely receiving a “Start Command”, the model passes into the “Idle” state. In this
state, two events may occur. One of them is an input event of “Full Stop Command”,
which means that the robot receives an off signal. The other is an output event called
“Sensing Command”, which means that, after a while the robot automatically passes
to the “Sensing” sate.
While the system is in the “Sensing” state, four different input events as “Straight
Path”, “Path Turns Left”, “Path Turns Right” and “End of the Path” may come to
existence. These events could be interpreted as environmental conditions out of the
system or the produced signals due to those conditions. Hence, in accordance to these
events the system passes into a new state which can be “Go Forward”, “Turn Left”,
“Turn Right” or “Stop”. A predefined mission is carried out in any of these states and
after the mission is completed, the system goes back to the state “Sensing” as a result
of an output event “Re-Sensing”.
While the system is in the “Sensing” state an input event of “Full Stop Command”
can make the system pass to the “Full Stop” state. Otherwise the system remains in
“Sensing” state again and passes to one of the other four states according to the
information received. Curve Following Robot reaches to the end of the path if it
permanently passes between states “Sensing” and “Stop”.
31
4.1.3. Petri Net Model of the Curve Following Robot
Petri Net model for the behavior of the Curve Following Robot is developed using
ArtifexTM
software. The overall architecture for the Petri Net model of Curve
Following Robot includes six units (objects) as it is illustrated in Figure 4.3. Each
unit has its own Petri Net model which is embedded in the object, while they can
communicate with each other through the linksets.
Figure 4.3 Architecture of the Petri Net Model for Curve Following Robot
Figure 4.4 is the top level page of the Petri Net model created in ArtifexTM
environment. The model has two sensors, two motor units (or wheels), one processor
and one power source.
Figure 4.4: Top Level Page of the Petri Net Model Created in ArtifexTM
Environment
The operational behavior is described as follows; after the power source enables
other units, the two sensor units detect the path and send crude information to the
32
processor unit. Then, the processor unit sends commands to motor units after
processing the information and making decisions.
Figure 4.5 shows the Petri Net structure of the Power Source unit. The place
START_POWER includes a starting token which makes the initial enabling for the
units. The power source sends an empowering token to the units for each tour of
implementation. Each tour covers one sensing, one decision making and one
command transfer to the wheels. This means that the model needs to be supplied by
the source permanently. This is done by the place, POWER and two-sided link
through transition POWER_TERMINAL. The source empowers the model only for
one hundred tours by the action and predicate codes written in the transition
POWER_TERMINAL.
Figure 4.5 Petri Net Structure of the Power Source Unit
Figure 4.6 shows Petri Net structure of a Right Sensor Unit. The place
START_SENSE_RIGHT has a starting token and sends a token as a signal to the
processor. A random number between “0” and “1” is assigned the token which is sent
to the processor through the output place, SEND_COMMAND_RIGHT. The input
place R_S_POW should receive a token from power source, otherwise the transition
SET_SENSE2 would not be enabled. In this way, the power source empowers the
sensor.
33
The Left Sensor Unit operates similar to the Right Sensor Unit. Sensors send signals
to the processor which produces commands to motor units and the sensors start re-
sensing in the next tour. But to make this, they should receive a re-sense command.
The re-sense command is a token which comes to the input place of
RESENSE_RIGHT as well as an empowering token from power source.
The black diamond at the bottom of Figure 4.6 is the portset that connects the sensor
unit to the processor unit through a linkset.
Figure 4.6 Petri Net Structure of a Sensor Unit
Figure 4.7 is the Petri Net structure of the Processor Unit. Empowering token from
power source comes to the PROCESSOR_POWER input place of the processor and
it is propagated to the other units. Signals from sensors represented by tokens come
to input places RECEIVE_COMMAND_LEFT and
RECEIVE_COMMAND_RIGHT. These tokens are associated with a number
between “0” and “1”, through the Local Variables called SENSE1 and SENSE2.
Decision making process is done in one of the transitions STRAIGHT, STOP, LEFT
and RIGHT that fetch the token from place ENFORCE_COMMAND. This is done
in accordance with the predicates defined for these transitions as it is illustrated in
Figure 4.8.
34
Figure 4.7 Petri Net Structure of Processor Unit of the Designed Model in ArtifexTM
Environment
Double values, assigned to Local Variables SENSE_1 and SENSE_2, less than “0.5”
is considered as a digital value of “0” or “LOW” and those are higher than “0.5” is
considered as a digital value of “1” or “HIGH” by the system. So for instance if the
local variables SENSE1 and SENSE2 both have the digital value of “LOW” or in
others words their values are less than 0.5 the system decides that robot should go
straight. Therefore transition STRAIGHT fetches the token and fires. As a result of
firing the transition related command is sent to the motor units. The motor units have
three modes of STOP, FORWARD and BACKWARD.
Figure 4.8 A Predicate Window of Transition
Figure 4.9 shows a motor/wheel unit’s Petri Net structure. In the motor/wheel unit
there are four input places, one for empowering token coming from power source
35
and three for the tokens come from processor for three modes of the wheel. Firing of
the transitions FORWARD, BACKWARD and STOP results in related actions and a
token is sent back to the processor through the output place of RESENSE_RIGHT.
The processor sends a re-sense command to the sensors while the power source can
afford the empowering function.
Figure 4.9 Petri Net Structure of a Wheel/Motor Unit
4.1.4. Simulation of Petri Net Model for the Curve Following Robot
In the simulation tool of the ArtifexTM
software, representations are made by
assigned colors and numbers of the objects. Time unit is involved in the model for
performing a realistic simulation. The Virtual Time (VT) timing mode is used in the
model. While each tour takes 107 time units, Figure 4.10 illustrates a screenshot
during simulation of the Curve Following Robot at instant VT=325 unit.
During the simulation, each unit fulfills its own task. Power source counts the
number of empowering tokens that are sent, the sensors count the number of signal
tokens sent to the processor, the processor shows the decision made namely
“Straight”, “Stop”, “Left”, “Right”, motors illustrate the implemented functions,
namely “Forward”, “Backward” and “Stop”. Number and color codes are given in
Table 1.
Behavior of each unit can be followed by these codes. For example, in Figure 4.10
the model is in the 4th
tour, because the power source has sent 4 empowering tokens
and also the sensors have sent 4 signal tokens. In the 4th
tour, the processor has
36
decided to turn “Right” (Light Blue-13), due to the signal values. As a result, right
wheel is in “Backward” mode (Blue-2) and the left wheel is in “Forward” mode
(Green-3). Table 2 represents behavior of the Curve Following Robot in different
modes.
Figure 4.10 Screenshot of the Graphical Simulation of Curve Following Robot
Table 4.1 Number and Color Codes for the Curve Following Robot’s Petri Net
Model Simulation
Unit Number and Color Codes
Processor Straight Left Right Stop
Green – 11 Orange - 12 Light Blue - 13 Pink - 14
Wheels Stop Backward Forward
Red - 1 Blue - 2 Green - 3
Sensors Sensors count the number of signal tokens sent to the processor;
Black–0, Red–1, Blue–2, Green–3, Orange–4,
Light Blue–5, Pink–6, White–7
Power
Source
Power source counts the number of empowering token it sends;
Black–0, Red–1, Blue–2, Green–3, Orange–4,
Light Blue–5, Pink–6, White–7
37
Table 4.2 Behaviors of Curve Following Robot in Different Modes
Right Sensor
0 1 L
eft
Sen
sor
0
Robot stops;
wheels stopped
Robot turns right;
Right wheel turns backward,
Left wheel turns forward, 1
Robot turns left;
Right wheel turns forward,
Left wheel turns backward,
Robots goes straight;
Wheels turn forward
For this case study, three user measures are defined. They are named "left_turn_id",
"right_turn_id" and "straight_line_id". These measure instruments are designed to
obtain the rate of the robot movement on straight line and the turns to left and right.
The measure data are collected by a Batch Run with 100 runs in a total 10700 time
units. Figure 4.11 illustrates the graphs related with these measures.
Figure 4.11 Graph of Three Measures for Curve following Robot
An automated report is also created by ArtifexTM
documentation tool for this case
study. This is a detailed document about the ArtifexTM
project which includes all
features and contents of the ArtifexTM
project. The report is given in Appendix B.
4.1.5. Desk Top Design of the Curve Following Robot
As the 4th
stage of the systematic approach, desktop design of the curve following
robot is developed to implement the operational behavior modeled by the Petri Net
structure. The desktop design is produced using two DC motors, two sensors, a
processor card, a power source (battery set) as represented in Figure 4.12. Sensors
38
are CNY70 type color detection sensor and the processor is an O-BOT card which
includes a microchip PIC18F2550. Processor codes of the desktop design are given
in Appendix C. The wheels and base of the model are designed and produced using
transparent plexiglas material in a laser cutting machine.
Figure 4.12 A view of Desktop Design of Curve Following Robot
4.1.6. Form-Integrated Model (Prototype) of the Curve Following Robot
Form-Integrated Model of the Curve Following Robot is produced to maintain the
integrity of the work. Figure 4.13 depicts the Form-Integrated Model which is
composed of the same components as in the desktop model. Those components are
integrated using proper structural elements. Processor codes are the same as for the
desktop model which is given in Appendix C.
39
Figure 4.13 Form-Integrated Model of Curve Following Robot
4.2. Case Study 2: Walking Dog Robot
This case study is a work on a behavioral modeling of a bio-inspired walking dog
robot which has been produced in the Mechatronic Department of Atılım University
within an ongoing TÜBİTAK project [60].
The first and second steps of the 4-step Systematic Approach are skipped in this case
study, because the physical robot prototype has already been developed based on
experimental data. Therefore, it is decided to use the available experimental data to
develop and simulate a Petri Net model of the dog’s walking behavior. This behavior
will also be implemented on a desktop model in the future work within this thesis.
4.2.1. Technical Specifications of the Model
The aim is to model and simulate the observed behavior of a walking dog in time
domain as an early stage of conceptual design of a bio-inspired dog robot. The model
is developed based on real time data collected from an experiment in which a dog is
walking on a treadmill with a speed of 1km/h [60]. Walking period is divided into
tours. A tour is the time duration in which all legs take one complete step with 8-
states represented by UP and DOWN positions of the legs. Duration of each tour is
704 ms and Figure 4.14 represents time data for three tours. Black dots in Figure
illustrate legs’ “DOWN” position and the leg locations without dots represent legs’
“UP” position.
40
Figure 4.14 Experimentally Obtained Real Time Schedule and Leg Positions of
Walking Dog
4.2.2. Petri Net Model of the Dog Robot
In the Petri Net model architecture of Figure 4.15, five objects are used to represent
behavior of the dog's body organs that contribute its walking; these are a Brain Unit
and four leg units; a Left Foreleg, a Left Hind Leg, a Right Foreleg and a Right Hind
Leg.
Figure 4.15 Architecture for the Dog Robot Model
Each object in Figure 4.16 is modeled with an associated Petri Net. Figure 4.16
shows the top level page of the Petri Net model for the dog’s walking behaviour in
Artifex Model Editor environment. All units in the model architecture are
illustrated at this level. Linksets are used to connect the leg units in the model
architecture with the brain unit.
41
Figure 4.16: Top Level Petri Net Model of Dog’s Walking Behavior
Brain Unit shown in Figure 4.17, contains a place START_BRAIN and a transition
CONVEY alongside eight columns of components (places and transitions). The place
START_BRAIN contains an initial token which operates as a starting signal in the
brain and it is propagated through eight columns of components which represent the
brain cells. Each brain column includes two transitions, one normal place, one input
place (represented by two concentric circles) and two output places (represented as a
triangle inside a circle).
Figure 4.17 Petri Net Structure of Dog’s Brain Unit Constructed in
Artifextm
Environment
42
Input and output places have the task of communicating with other units (legs) in the
model. Each two brain columns operate as a control mechanism of one leg, one
column is for the UP position of the leg and one column is for the DOWN position.
Each position has an active period and an inactive period. It means, for instance, for
the DOWN position, the leg is on the ground during the active period and the leg is
lifted during the inactive period. DOWN and UP positions are exactly converse of
each other on time domain. Each position (DOWN or UP) has an initial delay
alongside the active and inactive durations. In the Brain Unit, initial delays are set in
the upper transitions and the active period durations are inserted in the lower
transitions while the durations for inactive periods are set in a transition in the Leg
Unit. The black diamonds at the bottom part of Figure 4.18 are portsets which are
used to connect the brain to other units (legs) through linksets. Linksets are similar to
multi-wire cables and the portsets can be considered as terminals that those cables
are connected. All the input and output places connecting the brain to legs are
defined in the related portset. This procedure is repeated in each unit as well. Similar
to the Brain Unit, Petri Net model for the Leg Units are composed of two main parts
to represent DOWN and UP positions. Figure 4.18 illustrates a Leg Unit. In Figure
4.18 the right side models DOWN and the left side models UP position of the leg.
Each part consists of three transitions, one normal place, two input places and one
output place.
Figure 4.18 Petri Net for the Left Foreleg of Walking Dog Robot
43
Inactive period duration of the leg position is set in the upper transition and the two
lower transitions have the duty of conveying the brain command to the leg during the
initial delay and during the active period. The upper transition also contains some C
codes to set the illustrating colors and states (numbers) of the model.
4.2.3. Simulation of the Petri Net Model
The simulation tool of the model has the ability of real time simulation of dog's
walking behavior by means of different colors (as blue and red) and states (numbers);
as well as the step-by-step simulation in virtual time. During the simulation, the
Brain Unit counts the number of tours and expresses that by a state (number) and
color of the related leg unit. Behavior of each leg unit is simulated in real time such
that DOWN position is represented by the number “2” and color “blue” and UP
position is represented by the number “1” and color “red”.
Figure 4.19 illustrates a screenshot from simulation environment of the software at
the instant 1848 ms in the 3rd
tour.
Figure 4.19 Screenshot of the Graphical Simulation of the Dog’s Walking
Behavior
In this case study, measurement tool of the ArtifexTM
software is also used to
evaluate the results obtained in the simulation. Four measures are defined in the
model to monitor time durations for which each leg is on the ground (DOWN
position) during the total time of walking. This is done for a specified number of
tours the dog takes. It also lets the user to observe the initial delay and final time gap
of the DOWN position of the leg. It should be noted that the initial delays are given
44
for the model only, because the model has to set the legs at the beginning and there is
no such a delay in dog’s nature. The corresponding measurement graph in ArtifexTM
is presented in Figure 4.20.
To assign a measure, one measure component has to be defined. Some local variables
should be associated with this component. During a Batch Run, this measure
component collects values of these local variables. Then two local variables can be
plotted against each other, as it is done in this case study.
Figure 4.20 Measurement Chart for a Dog’s Walking Behavior
In Figure 4.20, different durations for dog’s legs are represented as lines with
different colors and slopes in the graph. The disharmony in the dog’s walking
rhythm, which can be observed in data, presented in Figure 4.14 causes different
slopes of the lines. Table 4.3 shows total time durations that each leg is on the
ground for 10 tours. The results and data collected from these measurements provide
a more realistic and detailed viewpoint for the designer, before stepping into the
stage of designing and manufacturing desktop or prototype of a robot. In the starting
setting periods for legs, one can observe the total duration that each leg is on the
ground and the instant that a leg steps up just before the end of each run. Therefore,
these measures are used in the design and manufacturing process for checking and
modifications as well as in the processor programming at the manufacturing stage.
45
Table 4.3 Time Data for a Measurement Session
ms
Legs
Beginning End Duration
Right Foreleg 652 6988 4400
Left Foreleg 288 6624 4160
Right Hind Leg 416 6752 4520
Left Hind Leg 100 6436 3400
Tour Numbers: 10 Total Duration : 7040 (704 each tour)
4.3. Case Study 3: Climbing Cockroach Robot
The third case study is a work on the conceptual design of a bioinspired cockroach
robot. Cockroach robot has been produced in the Mechatronic Engineering
Department of Atılım University within an ongoing TÜBİTAK project [61]. The
prototype robot is designed and produced based on real behavioral data collected
from a cockroach during climbing mode.
Within this case study, a Petri Net model has been developed in ArtifexTM
environment to simulate the climbing behavior of a cockroach.
4.3.1 Technical Specifications of the Model
Climbing rhythm of the cockroach is observed and experimentally recorded within
the work clusters of an ongoing TÜBİTAK project [61]. A cockroach was analyzed
to collect morphological, functional and behavioral data. The morphological
information was collected using both observation and content analysis whereas the
information about function and behavior was gathered only by observation. While a
cockroach has several movement types, in this case study, the cockroach was
allowed to climb freely on a vertical plexiglas surface and the stepping rhythm was
recorded [61]. As a result of this study, climbing rhythm of the cockroach is
developed independent of time domain and it is represented in Figure 4.21.
46
Figure 4.21 Climbing Rhythm of the Cockroach [61]
Figure 4.21 shows a tour for the cockroach’s climbing mode. The tour includes 14
steps. The dark dots represent the corresponding leg on the ground. Legs of the
cockroach are denoted as L1, L2, L3 for left legs and R1, R2, R3 for right legs; while
in the literature the front the legs are called Prothoracic legs, middle legs are called
Mesothoracic legs and the hind ones are called Metathoracic legs [61].
4.3.2. Petri Net Model of the Cockroach Robot
Cockroach robot’s Petri Net model consists of seven units in total, one Brain Unit
and six leg units. The leg units are named LEFT_PROTHORACIC or L1,
RIGHT_PROTHORACIC (R1), LEFT_ MESOTHORACIC (L2), RIGHT_
MESOTHORACIC (R2), LEFT_ METATHORACIC (L3), RIGHT_
METATHORACIC (R3). Figure 4.22 depicts the Top Level Petri Net model of the
cockroach robot’s behavior.
The leg units are connected to the brain unit by two normal links instead of linksets.
During the operation, one token comes to the leg through the lower link connected to
the leg unit and one returns to the brain through the upper link connected. Figure
4.23 illustrates Brain Unit’s Petri Net structure. Petri Net structure of each unit is
separately developed, but they communicate with each other.
Petri Net structure of brain includes 14 transitions, named A1 to A14, that take
function for each step of the 14-step climbing mode. These transitions are connected
to six output places at the bottom that represent the legs. Each of these places is
connected to the related leg unit. Starting token comes from place START and is
transferred to the legs as a result of firing the related transition. After a token is
transferred to a leg, it returns back to the brain through the input place IN and the
brain becomes ready for a new step. The sorting between the transitions A1 to A14 is
done by C codes and in this way, the stepping rhythm is carried out in true way.
47
After the 14-step tour is completed, transition TOUR resets the model and the same
tour begins again.
Figure 4.22 Top Level Petri Net Model of the Cockroach Robot’s Climbing
Behavior
Figure 4.23 Petri Net Structure of the Cockroach’s Brain Unit
Figure 4.24 depicts a Leg Unit of the cockroach. The Petri Net structures for six legs
are identical. Figure 4.24 represents leg L1. The activation token which comes from
the brain enters the leg through the input place L1_I and returns back to the brain
from the output place L1_O. Function of the leg is carried out by C codes which are
48
written in the action part of the transition at the middle. Representation of the leg’s
function is done by color and number codes.
Figure 4.24 Petri Net Structure of the Cockroach’s Leg Unit
4.3.3. Simulation of the Petri Net Model for the Climbing Cockroach Robot
Figure 4.25 is a screenshot of the Petri Net model simulation for the representation of
the cockroach robot’s behavior. Color and number codes are used to represent
whether the leg is on the ground or it is upraised. During the simulation, the brain
counts the number of tours. For the legs, number “2” and color “Blue” shows that the
leg is on the ground, while number “1” and color “Red” shows that the leg is
upraised. The design models the climbing mode of the cockroach which is depicted
in Figure 4.21, independent of the time domain. The 14-step tour of the climbing
mode is performed step by step clicking on the execution button of the simulation
tool.
Figure 4.25 A Screenshot of the Model Simulation
49
4.4. Case Study 4: Pick Packing Automated Guided Vehicle
Pick-Packing Automated Guided Vehicle (Pick-Packing AGV or PP-AGV) is the
fourth implemented case study for which systematic approach is fully pursued [62].
The goal is considered as the design of an automated guided vehicle whose task is to
transfer some materials or packs between finite-number of stations. The pick packing
action is performed by using an arm and a gripper attached on the vehicle.
Specifically what is intended in this case study is to produce a Petri Net model for
the high level operational behavior of a PP-AGV which is able to travel between four
predefined stations and a “Start Point”, to transfer some identical packs between
those stations. It is assumed that there are finite-number of missions defined for the
PP-AGV and it is expected to accomplish them without any external interference.
Figure 4.26 illustrates a travelling map which is composed of four stations, for the
intended operational behavior of the PP-AGV. Distances given in Figure 4.26 are in
true ratio of scale.
Figure 4.26 Traveling Map of Pick Packing AGV
It should be mentioned, referring to the fact that AtrifexTM
is a C-based software, C
coding is used in Petri Net model of Pick-Packing AGV to give the model ability of
fulfilling various missions.
50
4.4.1. Functional Decomposition for PP-AGV
In the first step of the systematic approach for behavior based design the overall
function of PP-AGV is divided into three main functions; “Decision Making and
Data Processing”, “Traveling between Stations” and “Transporting Packs”. These
functions and their sub-functions are represented in Figure 4.27.
Figure 4.27 Functional Decomposition for a Pick Packing AGV
4.4.2. Discrete Event System (DEVS) Model of PP-AGV
Functional decomposition is used to develop a Discrete Event System Specification
(DEVS) model for the operational behavior of the Pick Packing AGV given in Figure
4.28. In this model, the AGV’s operational behavior is composed of five states as
“Full Stop”, “Decision Making”, “Waiting in Station”, “Transfer Packs” and “Move
between Stations”. The “Full Stop” state is defined as the initial state. When the
robot is in this state, an input event “Start” is required to activate its operation by a
transition to “Decision Making” state, which represents an initial decision making.
Two state transitions are possible from “Decision Making” state; either to “Move
between Stations” state or to “Waiting in Station” state. Behavior of the system in
“Move between Stations” state is represented by a 2nd
level DEVS model with 5
states and state transitions through output events called “!Act”, that represent
“Actions”. Similarly, “Transfer Packs” state is denoted by a DEVS model by means
of two 2nd
level states as “Pick Pack” and “Put Pack” with transitions through output
events; “!Pick” and “!Put”. The intended operation of the system is explained as
follows:
51
When the system is in its initial state “Full Stop”, a “?Start” command with a mission
number is received and this is considered as an input event (denoted by the symbol
“?”) that causes a transition from “Full Stop” state to “Decision Making” state. In
“Decision Making” state, the system decides about what it is going to be carried out.
Possible state transitions are either to “Move between Stations” state or to “Waiting
in Station” state. Both transitions result in output events (denoted by the symbol “!”)
that represent the resulting action for each case, namely “!Move” and “!Wait”.
Figure 4.28 Pick Packing AGV-DEVS Model
During the operation of this system, finite number of changes take place in three
states “Move between Stations”, “Waiting in Station” and “Transfer Packs” in order
to carry out a mission. State changes are denoted by the output events “!Move”,
“!Wait”, “!Transfer” and “!Done”. When a mission is over, the system passes to
“Full Stop” state through a state transition from “Move between Stations” and is
ready for a new input event; that is, receipt of a new “!Start” command. Description
of the 1st level states and events for the DEVS model of the pick packing AGV is
given in Table 4.
4.4.3. Technical Specifications of the Model
Getting a viewpoint from functional decomposition and the DEVS model, and
considering the functional attributes, rough technical features of the AGV’s physical
structure are described to model the operational behavior. The AGV is considered as
a car-like vehicle, which can be designed with two controllable wheels at the right
and left sides and two ball caster wheels at the front and back. A robot arm with a
52
gripper at its end would be mounted on the vehicle. For simplicity, the robot arm is
considered to turn in one degree of freedom parallel to the ground.
The gripper could grip and release the identical packs receiving commands from a
processor. The identical packs could be placed on the platforms at stations as well as
on a platform of the vehicle. The platforms at stations and the one on the vehicle
have to be of the same height. Figure 4.29 illustrates a schematic representation of
the pick packing AGV.
Table 4.4 States and Events in the DEVS Model of the Pick Packing AGV
Type Name Description
States
Full Stop The robot is not operating, it is in idle mode.
Decision Making The state stores the predefined programs and dictates what the
actuator states are going to perform.
Waiting in Station The vehicle is waiting at a station for transferring packs.
Move between Stations A state that represents travelling between stations.
Transfer Packs Transferring (putting or picking packs) operation is being
performed.
Events
Start An input event that represents a command to activate system’s
operation. It also includes the mission number.
Set An output event which represents an internal command which
resets the system after a mission comes to end.
Move An output event representing that the robot starts moving as a
result of passing from “Decision Making” or “Waiting in
Station” states into “Move between Stations” state.
Wait An output event representing that the robot switches from
“Decision Making” or “Move between Stations” states to start
“Waiting in Station”.
Transfer An output event defined to represent that the robot starts
transferring packs and the state changes from “Waiting in
Station” into “Transfer Packs”.
Done An output event that represents transferring packs is finished
and transition from “Transfer Packs” state to “Waiting in
Station” state occurs.
53
The following three missions for the AGV are defined in this study:
Mission 1: The AGV is required to distribute four packs to all stations, one
for each station, respectively from station A to D represented in Figure 4.26.
Mission 2: The AGV will collect four packs, one from each station, following
the same route as in the first mission.
Mission 3: The AGV will pick a pack from station A and will put that at
station B. In the same way, it will pick a pack from station B and will put that at
station C and process continues so forth.
Figure 4.29 Schematic Representation of the Pick Packing AGV
It should be noted that, all three missions are required to start and end at the Start
Point. In addition, durations that the AGV would need to move through the critical
points in Figure 4.26 are represented in Table 4.5. Since the travelling map is
symmetric, identical durations for travelling between different points are represented
using parenthesis in Table 4.5. Calculations are based on the assumption that a servo
motor with an operating speed of 0.1sec/60degree (4.8v) will be used in the desktop
design of the pick packing AGV. Since the main goal of this work is to model the
intended operational behavior of a demonstrative AGV, a simple design is
considered at conceptual level.
54
Table 4.5 Durations for the Pick Packing AGV’s Travelling Tasks
AGV’s Travelling Tasks Task Duration(ms)
Travel between “S” and “M” 10884
Travel between “M” and “K (O)” 20049
Travel between “K (L,N,O)” and “A (B,C,D)” 3055
Travel between “M” and “L (N)” 6682
Travel between “L (N)” and “K (O)” 13367
Turn by 90 450
Turn by 180 900
4.4.4. Petri Net Model of PP-AGV in ArtifexTM
Environment
The third step in systematic behavior based design approach is the development of a
Petri Net model used to represent and simulate the intended behavior of the pick
packing AGV. Figure 4.30 shows the Top Level behavioral model of the AGV in the
ArtifexTM
environment. The top level model consists of six objects, namely units,
which are Power Source and Processor Units, Right and Left Wheel Units, Robot
Arm Unit and Gripper Unit. All units are connected to each other by interconnecting
links that model the communication between these units. Petri Net structure of each
unit is embedded in the top level model. The detailed Petri Net structures of the
“Processor” and “Left Wheel Unit” are represented in Figure 4.31 and Figure 4.32,
respectively.
Figure 30 Top Level Behavioural Model in ArtifexTM
Environment
55
The following mechanisms are modeled in the Petri Net structure of the Processor
Unit (Figure 4.31):
a) Being empowered by Power Unit,
b) Receiving commands and detecting valid or invalid ones,
c) Declaring mission number for the actuator units,
d) Sending actuating commands to the actuator units.
Figure 4.31 Petri Net Structure of Processor Unit for PP-AGV
Similarly, the actuator units (wheels, arm and gripper) have four mechanisms
(Figure 4.32):
a) Being empowered by Power Unit,
b) Receiving mission command,
c) Actuating operation,
d) Resetting after the mission is over.
Actuating functions such as running the wheels, turning the arm and gripping, are
done by C-coding embedded in Action parts of actuate transitions. For instance,
Figure 4.33 depicts Action window of the “L” Transition in Left Wheel Unit. “L” is
an actuating transition for the left wheel.
56
The Petri Net Model of the Pick Packing AGV is simulated in two modes as “step-
by-step mode” and “real time mode” using the simulation tool of ArtifexTM
software.
A screenshot of the simulation is illustrated in Figure 4.34. After starting the
simulation, it asks for mission number and after receiving the right command, the
model begins to carry out the required mission. In the case of an invalid entry, the
system produces a warning and asks a new entry. After completing a mission, the
system asks for a new command. All the inputs/outputs of the system such as
commands, wrong entries, descriptions and actions are printed on the I/O page at the
right side of Figure 4.34. Behavioral aspects of the pick packing AGV are visualized
by number-color state codes as illustrated in Table 6.
Figure 4.32 Petri Net Structure of Left Wheel Unit
Figure 4.33 C-coding in Action part of Transition “L” in Left Wheel Unit.
57
Figure 4.34 A Screenshot of the AGV’s Petri Net Model Simulation
Table 4.6 Number-Color State Codes for PP-AGV
Unit(s) Number-Color Code Explanation
Power Source Unit
[10 – black] Empowering mode
Processor Unit Number-color state code counts
the mission number
Wheel Units [1-red]
[2-blue]
[3-green]
Forward
Backward
Stop
Robot Arm [6-pink]
[7-white]
[8-black]
Set mode
Turning toward platform on
AGV
Turning toward platform at
station
Gripper
[4-orange]
[5-light blue]
Released mode
Gripped mode
58
4.4.5. Desktop Design of PP-AGV
After developing and simulating the intended operational behavior for the Pick
Packing AGV model, next step is to construct its desktop design as the fourth step of
Systematic Approach. The desktop design is considered as a distributed physical
environment to observe the behavioral attributes of the robot under conceptual
design, independent of dynamic and/or geometric parameters. An initial version of
the pick packing AGV’s desktop design has been constructed as illustrated in Figure
4.35.
Figure 4.35 A view of Desktop Design for PP-AGV
Pick Packing AGV’s desktop design has been constructed using two wheels as left
and right wheels, an IR remote control suit, two servo motors with links attached and
a mechanical gripper. The power is supplied externally from an adjustable power
supply device. Straight motion, turning right and left are physically simulated by
means of two wheels turning forward and backward. One servo motor makes the
robot arm be able to turn parallel to the ground (considered as the X-Y plane) and
another servo motor lets the arm to move about Z-axis. The initial desktop design
includes a mechanical gripper which operates using a mini servo motor for gripping
59
and releasing packs. The system begins to operate and carry out the missions by
inserting commands using an IR remote control. Technical drawings for the
figurative body parts produced for the robot are given in the Figure 4.36 The
behaviors of the robot are same as the Petri Net model given in Tables 5 and Table 6.
The three missions defined in section 4.4.3. are carried out by the desktop design
model.
Figure 4.36 Engineering Drawings for the Figurative Parts of PP-AGV
4.5. Case Study 5: Frog-Like Robot
4.5.1. Step 1: Functional Decomposition for Frog-Like Robot
Behavior based modeling of a frog-like robot starts with a functional decomposition
that imitates the functions of a frog animal. Functional decomposition is based on the
apparent/visible functions since the main objective is to divulge a general behavior of
a frog-like robot. Therefore main functions of frog-like robot decide on “Sense”,
“Mood” and “Motion” as illustrated in Figure 4.37. “Sense” function represents
perception of environment and it is composed of sub-functions such as “Sight”,
“Hearing”, “Touch”, “Taste” and “Smell”. Another main function is “Mood” which
represents such functions related with possible emotional reactions and feelings of
the animal. These are given as “Happy”, “Angry”, “Love” and “Hungry” in Figure
4.37. The other main function “Motion” describes apparent physical functions such
as “Walking”, “Jumping”, “Swimming” and “Response Actions”. It should be noted
that there is not a priority among functions in the functional decomposition graph of
Figure 4.37.
60
Figure 4.37 Functional Decomposition of a Frog
Functional decomposition of a frog-like robot in Figure 4.37 is represented in more
detail in Figure 4.38. Functional decomposition of Frog Robot is developed
considering robotic conditions and aspects alongside inspiring the natural attributes.
As a result, a frog-like robot is represented in three main functions as “Sensing”,
“Information Processing” and “Motion”. Main functions have several sub-functions.
The categorization of main functions reflects a general rule of receiving input
signals, processing inputs and creating outputs. For a “Sensing” function in a frog-
like robot the input signals could be light beams in sense of distance, brightness and
color or the sound waves in sense of voice and noise and other interference signals
such as force, humidity, temperature and vibration which could be classified in touch
sense group.
In Figure 4.38, “Information Processing” function is divided to sub-functions
“Transferring Data to Processing Unit”, “Processing Data”, “Decided-Responded
Case” and “Store-Convey Data”.
The “Motion” function is divided in two sub-functions “Locomotion” and “Response
Actions” with more lower level sub-functions for each other as represented in Figure
61
4.38. The refined functional decomposition diagram is used as a basis for developing
a DEVS model of a frog-like robot, to describe its behaviors.
Figure 4.38 Refined Function Decomposition of Frog-Like Robot
4.5.2. Step 2: Discrete Event System Model of Frog Robot
DEVS model of the Frog Robot consists of nine states which are “Full Stop”, “Idle”,
“Sensing”, “Information Processing”, “Walking”, “Jumping”, “Angry, “Happy” and
“Frightened”.
Behavior of a frog-like robot is based on the functional decomposition. This behavior
consists of events and corresponding state transitions that are represented by a
Discrete Event System Specification (DEVS) model given in Figure 4.39.
The initial state of the model is “Full Stop” state. As a result of receiving a “Start”
command as an input event system passes to “Idle” state. In the “Idle” state the
system is empowered but there is no allowance or requirement for any motion. Along
with being a passage to “Sensing” state from “Full Stop” state, “Idle” is a state which
can be selected as a consequence of system’s decision making process. In the “Idle”
state, the model receives a command named “Sense Environmental Signals” which is
an Input Event as well and in this way, the model passes to the “Sensing” state. In the
“Sensing” state, there are three sub-states called “Sight”, “Hearing” and “Touch”.
They are independent sub-states with separate operation under the Sensing state. In
this state the system detects environmental or given signals which it is subjected to.
62
Additionally, the state has the Input Event entry of “Environmental or Given
Signals”.
By an Output Event named “Transfer Crude Data” the system passes to another state
called “Information Processing”. In this state Crude data to be selected is processed
and the system makes a decision about the next state. “Decision Making” is a sub-
state under the Information Processing state. There is another sub-state called “Store
Data” in which data generated after decision making could be stored for a later use
by the “Decision Making” state.
Figure 4.39 DEVS Model of Frog Robot
After decision making action the system will pass to either one of the actuating states
or to the “Idle” state again. Actuating states are “Jumping”, “Walking”, “Happy”,
Angry” and “Frightened”. All of them have five sub-states that represent states for
“Head”, “Eyes”, “Sound Organ”, “Forelegs” and “Hind Legs”. The sub-sates
represent the recalled robot units. These units perform specific behaviors for each
actuating state or mode. For instance at the Frightened state Head’s behavior is
described as “Fixed to Flashpoint”. In the same way the expression of Eyes’ behavior
is “Fully Open”, for the Sound it is “Scream” and both front and hind legs are in
“Guard Position”.
63
After fulfilling the operation of the selected actuating state system returns to the
“Sensing” state by an output event named “Sense Environmental Signals”. This
behavior describes an infinite loop including the “Idle” state. In order to eliminate
this problem a stop command is detected in the “Sensing” state, the Information
Processing state can produce a “Stop” command as an output event which makes the
system pass to “Full Stop” state. Therefore transition from “Information Processing”
state to “Full Stop” and the model’s operation ends.
DEVS model describes the required operation of a frog-like robot as states and state
transitions. In the third stage of the systematic behavior based design approach
DEVS model is used to develop a Petri Net model for simulation.
4.5.3. Step 3: Petri Net Model of Frog-like Robot in ArtifexTM
Environment
Development and simulation of the Petri Net model for a frog-like robot is performed
using ArtifexTM
environment. Figure 4.40 the top-level model, which consists of
eight objects or units as represents “Head”, “Sound Organ”, “Left Eye”, “Right Eye”,
“Left Front Leg”, “Right Front Leg”, “Left Hind Leg” and “Right Hind Leg”. Each
unit has its own Petri Net structure that performs the unit’s behavior.
Figure 4.40 Top Level Page of the Frog Robot’s Petri Net Model Created in Artifextm
Environment
The model receives external environmental signals by “Sight”, “Touch” and
“Hearing” sensing organs and this input data is processed in “Brain” unit of the
system, which decides about the type of behavior. Five modes are modeled in the
64
Petri Net to represent behaviors, which are “Angry”, “Frightened”, “Happy”,
“Jumping” and “Walking”.
In the model receives external environmental signal as numerical values. These
values should be given as positive integer inputs during model simulation. Decision
making on the mode of behavior is done based on predefined intervals for numerical
values of environmental signals and these intervals are listed in Table 7.
The numerical inputs are manually given to the model using ArtifexTM
Simulator
tool’s I/O page. At the beginning of the simulation, Table 7 is provided by the system
which is included by the welcome massage of the model simulation as illustrated in
Figure 4.41. The model is designed to produce warning massage in the case of
wrong entries.
Table 4.7 Intervals of Environmental Signals for Behavioral Moods of Frog Robot
Mode of Behavior Sight Sound Touch
Angry 0-40 30-80 70-100
Frightened 0-50 50-100 30-60
Happy 10-40 0-40 20-70
Jumping 60-100 0-50 0-50
Walking 55-90 0-50 60-100
After deciding on a mode, the model begins to perform the corresponding behavior.
Behavior of each organ in different modes is represented by color-number codes as it
is given in Table 8.
Behaviors of the model can be pursued from the I/O page of the software. For
example if a user inserts numerical environmental signal values “10” for sight, “0”
for sound and “20” for touch the system will select “Happy” mode to perform. In this
case, as expressed in Table 2 the legs will show green color code alongside 53 and 43
numerical codes respectively for hind and front legs. These codes represent ‘back
and forth’ behavior for the legs as printed on the right-hand screen of I/O page. In the
same way the other units reflect the behavior by color and state code as the behaviors
are printed on the I/O screen. The eyes are black with state 32, head is red with state
65
13 and sound is pink with state 23. These codes represents flashing for eyes, turning
right and left for head and happy sound for sound organ. Figure 4.42 illustrates the
simulation page and I/O screen of the ArtifexTM
software.
Figure 4.41 Welcome Massage at The Beginning of The Simulation of Frog Robot
Table 4.8 Coding For Frog Robot Organ Behaviors in Different Modes
Modes of
Behaviors
Forelegs
(color-number)
Hind Legs
(color-number)
Head
(color-number)
Eyes
(color-number)
Sound
(color-number)
Angry assault position
(red[1]-41)
assault position
(red[1]-51)
shaking
(green[3]-11)
fully open
(white[7]-31)
roaring
(orange[4]-21)
Frightened guard position
(blue[2]-42)
guard position
(blue[2]-52)
fixed to flashpoint
(orange[4]-12)
fully open
(white[7]-31)
scream
(light blue[5]-22)
Happy back and forth
(green[3]-43)
back and forth
(green[3]-53)
right and left
(red[1]-13)
flashing
(black[8]-32)
happy sound
(pink[6]-23)
Jumping Focus to maintain
balance
(orange[4]-44)
springy function
(pink[6]-54)
without motion
(black[0]-14)
fixed
(black[0]-33)
silent
(black[0]--24)
Walking stepping
(light blue[5]-45)
stepping
(light blue[5]-55)
without motion
(black[0]--14)
fixed
(black[0]--33)
silent
(black[0]-24)
66
Figure 4.42 Simulation and I/O Screen for Frog Robot
As it is mentioned previously each unit contains a Petri Net structure. Figure 4.43
depicts the Petri Net structure of Head unit. Head unit also includes two subnets
which model the brain and neck organs.
Figure 4.43 Petri Net Structure of the Head Unit of Frog Robot
“Head” unit has two sub-nets, “Brain” and “Neck”. The five-place row just below the
“Brain” conveys the tokens out of the brain to the organ units. These places are
common places that connect the “Brain” to the outer units. There are five convey
places each one is responsible of each five possible modes.
67
The transitions on the right of the convey places in Figure 4.43 propagate the tokens
to send for different organs. The lower five-place row is the common places with
neck subnet those deliver activation token to the neck.
Output places on the left of the transitions in Figure 4.43 are responsible to send
tokens to outer units. Despite internal subnets (here there is only one, the Neck)
which are able to communicate through common places, independent units (objects,
such as legs) communicate by output and input places and via linksets. There is an
eight-place row upper the page in figure 4.43. All those are input place except one on
the right. These places transit coming back tokens from organs to the brain to make it
re-sense. The place on the right is a common place with neck.
The black small squares at the bottom of Figure 4.43 are portsets which are
connection points between head and organ units. The linksets seen on the top level
page are connected to portsets.
Figure 4.44 is Petri Net structure of the brain. The whole process begins by a stating
token put in the place Start. Passing through the Welcome transition which prints the
welcome massage on I/O page, and being propagated by transition Propagate the
tokens are sent to places Sight, Sound and Touch. At transitions SENSE_SIGHT,
SENSE_SOUND and SENSE_TOUCH system asks input data by C coding written
in Action part of the transition (Figure 4.45). In this way the input data are assigned
to Local Variables SIGHT, SOUND and TOUCH. Continuing via transition
RECEIVE_DATA the token comes to place DECISION.
By the C coding written in Predicate part (Figure 4.46) of lower transitions such as
Angry or Happy the activation token flows through one of these transitions and in
this way system is decides one of the behavioral modes and activation token is let out
of the brain.
68
Figure 4.44 Petri Net Structure of the Frog Robot Brain
Figure 4.45 C Coding In Action Part of the Transition SENSE_SIGHT
Figure 4.46 C Coding in Predicate part of the Transition FRIGHTENED
69
If the input data matches with none of the lower transitions it flows via transition
UNDEFINED which leads the token to place CONVEY_START and makes system
to re-ask data entry. While passing across the transition UNDEFINED a wrong entry
massage is printed on the I/O page.
Figure 4.47 illustrates the Brain unit during simulation. It depicts the decision
making mechanism of the system. The mechanism works as an “if-else” structure in
accordance with C coding reasoning.
Figure 4.47 Screenshot of Brain’s Simulating
After this point the actuator units should perform the behavior planned for each
mode. Petri Net structures of two organs namely NECK and LEFT FRONT LEG are
shown in Figures 4.48 and 4.49, respectively Petri net structure of actuator units are
identical.
70
Figure 4.48 Petri Net Structure of the Neck
Figure 4.49 Petri Net Structure of the Front Leg
One transition is planned for each behavioral mode named Angry, Frightened,
Happy, Jumping and Walking. C codes written on the Action parts of the transitions
change the state and color of the unit (object) at each fire (figure 4.50). The behavior
transitions perform is given in table 8.
Figure 4.50 C Codes in Action Part of Actuating Transitions
The activation token comes to transition via input places seen at the top of the page,
Figure 4.49. After the activity is carried out the token flows back to the brain through
output place at the lower page. The return tokens sent back to the brain make the
71
brain re-sense and the sensing organs ask for new entries. In this way the system will
be ready to a new task.
4.5.4. Desktop Design for Frog Robot
The intended behavior of the frog robot is modeled and simulated by Petri Nets. Next
step in the systematic approach is to develop a desktop design model for the frog
robot which is illustrated in Figure 4.51.
The desktop design of the frog robot consists of a processor card, seven servomotors
and related links, infrared sensor switch, sound sensor, light sensor, digital buzzer,
force sensor, digital button, camera and two LEDs.
Same as specified in the related DEVS model (Figure 4.39) and Petri Net model
(Figure 4.40), desktop design model of Frog Robot has body organs which are head,
eyes, sound organ and legs. The model has six links to represent the legs and
technical drawing for the figurative legs of the frog robot is given in the Figure 4.52.
The links are operated by servo motors. The upper leg-shaped links in Figure 4.51
represent the right legs and the lower links represent the left legs. Hind legs consists
of two parts and the two links at middle and left represent hind leg, while the front
leg is represented by one link which is one at the right. The brain is represented by
the processor card the neck of the Frog Robot is represented by a servo motor. Eye
organ is represented by CMU camera, IR switch sensor, light sensor and LEDs. The
camera detects color and sends signals to the neck so that the neck pursues the color
of light red- orange. The two LEDs represent the eyes by going on and off in
different behavior modes. The IR switch sensor detects if something is getting close
to the robot and light sensor detects the darkness and lightness of the environment.
The force sensing resistor and button play the role of touch sensing for the Frog
Robot. The sound sensor senses any sound in the environment and plays the role of
the ear. In the DEVS model of the Frog Robot (Figure 4.39), five behavioral modes
are defined, which are “Jumping”, “Walking”, “Happy”, “Angry” and “Frightened”.
All these behavioral modes, plus one more, the “Hunting” mode are carried out by
desktop design of the Frog Robot.
72
Figure 4.51 A view of Desktop Design for Frog Robot
Figure 4.52 Engineering Drawing for the Figurative Legs of the Frog Robot
73
Table 9 gives the behaviors of the desktop design corresponding to each behavioral
mode. Note that, when no signal is detected, the desktop model is in idle mode. If the
model detects convenient signal to perform a behavioral mode will continue its
performance until the convenient condition are excited.
Table 4.9 Behaviors of Frog Robot’s Desktop Design Model
Behavioral Mode Perception Behavior
Idle No signal detected Motionless
Jumping Digital button pressed,
FSR is touched
LEDs go on,
Legs get jump position,
Legs return to Idle mode,
Legs go off
Walking IR switch sensor detected,
FSR is touched
LEDs go on,
Legs take two steps,
Legs return to Idle mode,
Legs go off
Happy Light sensor detected,
FSR is touched
Neck turns right and left two times,
Buzzer makes happy sound,
Frog stands on hind legs and shakes front legs
three times,
Buzzer make happy sound
Angry IR switch sensor detected,
Light sensor detected,
Sound sensor detected
LEDs and Buzzer go on consciously,
Neck turns right and left three times,
Legs get assault position,
Legs return to Idle position,
LEDs and Buzzer go off
Frightened Light sensor detected,
Sound sensor detected
LEDs and Buzzer go on and off for 400 ms,
Legs get guard position,
Legs return to Idle position,
LEDs and Buzzer go on and off for 400 ms,
Hunting Digital button pressed Camera detects color,
Neck tracks color,
LEDs and Buzzer flashing
74
CHAPTER 5
DISCUSSION, CONCLUSION AND FUTURE WORK
In this thesis, a systematic approach is developed for behavior based conceptual
design of educational robots as mechatronic systems. Conceptual design case studies
for educational robots are conducted for the implementation of the systematic
approach. The implementation involves conceptual structuring, computer modeling
for simulation and physical modeling of intended robot behaviors.
5.1. Discussion
In order to achieve the intended goals of implementation, five case studies are
performed within this research. Each case study is selected attentively due to specific
reasons to reach certain results and each case study has its contribution to serve the
overall goal of the research.
The first case study, namely the “Curve Following Robot”, is a well-known
educational robot type. In fact the structure, components and characteristics of a
curve following robot is well known and it can be find in many resources. Therefore,
this case study is well suited for step-by-step implementation of the suggested
systematic approach. A form-integrated prototype robot model is also produced for
this case study to practice a complete systematic behavior based design approach,
although the form-integrated prototype robot model is not included by the scope of
the research.
The second and third case studies, respectively “Dog Robot” and “Cockroach
Robot”, are selected from a Tübitak project’s design cases in the Mechatronics
Engineering Department of Atılım University. The two prototype robots has already
been produced in the Mechatronics Engineering Laboratories upon experimental data
collected from real animals. The main reason for selecting these two existing design
cases is the need for the development of their simulation models using ArtifexTM
software and imitation of their behaviors.
Another case study, the “Pick-Packing Automated Guided Vehicle (PP-AGV)” is
used for complete implementation of all steps of the systematic approach.
75
Experiments and results of the previous three case studies are used in PP-AGV.
Although characteristics and properties of the system are well known for the Curve
Following Robot, the PP-AGV case is a non-existent conceptual/behavioral design
case for which the systematic approach is successfully applied. The last case study
is the “Frog Robot” and it is particularly important due to its complexity. Desktop
designs for “Curve Following Robot”, “Pick Packing AGV” and “Frog Robot” are
also developed and physically constructed on a Desktop Design Setup. This setup is
capable of serving as an educational platform for undergraduate mechatronics
engineering design education.
5.2. Conclusion
Systematic behavior based modeling and representation in conceptual design of
mechatronics systems forms a basis for the development of future computational
techniques. In this work, a systematic framework is developed for behavior based
conceptual design of educational robots and an experimental desktop design platform
is physically constructed. Well known techniques/tools such as functional
decomposition, DEVS formalism and Petri Nets are used for this framework. Model
development and simulation of the case studies is done successfully using Artifex
software environment. Simulations are important in terms of better performance and
less time by providing the designers with greater understanding of the product’s
behavior. The original contribution of this thesis is two-sided as follows:
Development and implementation of a systematic approach for behavior
based conceptual design.
Physical construction of a desktop design platform to obtain simulated
behaviors for educational purposes.
5.3. Future Work
Engineering design methodology, particularly the conceptual design field still
remains an open area for further and innovative research. Changes in market
conditions push designers to seek new and shorter ways to catch newly set goals.
Many works have been done in classical engineering domains for the design
methodology. Since mechatronic systems integrate various engineering disciplines,
76
domain-independent systematic design methods devoted to this integration are
needed for computational conceptual design support for mechatronic products. This
research is an initial contribution in this field from behavioral modeling perspective.
The goals set for the research are achieved and based on the completed study, main
future research directions are listed below:
Computer-automation for systematic behavior based modeling approach: It
is obvious that manual transition between design process steps have the
advantage of more flexibility and more maneuver capability, but at the same
time non-automated transitions take more time and increase the human
oriented errors.
Improvement of current virtual simulation method: There is no debate that
more detailed and efficient simulation and feedback facilities will lead to
better performance in design process.
Development and implementation of behavioral evaluation techniques for
conceptual robot design: Behavioral evaluation of concept variants for
mechatronic systems is an essential task, therefore evaluation measures need
to be developed and implemented based on the systematic approach of the
present study.
77
REFERENCES
[1] Lee, C.K.M., Lau, H.C.W., Leung, B.P.K., Ho, G.T.S. and Choy, K.L., 2006,
“Enhancing Product Development through a Dynamic Information Interchange
Approach”, International Journal of Production Research, Vol.44, No.23, pp.5197-
5222.
[2] Cao, D. X., Zhu, N. H., Cui, C. X. and Tan, R. H., 2008, “An Agent-Based
Framework for Guiding Conceptual Design of Mechanical Products”, International
Journal of Production Research, Vol.46, No.9, pp.2381-2396.
[3] Cao, D.X, Fu, W. M., 2011, “A Knowledge-Based Prototype System to Support
Product Conceptual Design”, Computer-Aided Design and Applications Vol.8, No.1,
pp.129-147.
[4] Qin, S.F., Harrison, R., West, A.A., Jordanov, I.N. and Wright, D.K., 2003, “A
Framework of Web-Based Conceptual Design”, Computers in Industry Vol.50,
pp.153-164.
[5] Pahl, G. and Beitz, W., 1988, “Engineering Design - A Systematic Approach”,
The Design Council, London, UK.
[6] Ulrich, K. and Eppinger, S., 1995, “Product Design and Development”, New
York, McGraw-Hill.
[7] Andreasen, M. M., 1994, “Modelling-The Language of the Designer”, Journal of
Engineering Design, Vol.5, No.2, pp.103-115.
[8] Horvath, I., 2004, “A Treatise on Order in Engineering Design Research”,
Research in Engineering Design, Vol.15, pp.155-181.
[9] Mocko, G., Malak, R., Paredis, C. and Peak, R., 2004, “A Knowledge Repository
for Behavioural Models in Engineering Design”, In 24th
Computers and Information
Science in Engineering Conference, Salt Lake City, Utah.
[10] Erden, Z., 2010, “Behavior-Based Modeling Approach for the Conceptual
Design of Mechatronic Systems Using Discrete Event System Specification (DEVS)
Formalism”, Proceedings of the 14th
International Conference on Machine Design
and Production, Güzelyurt, Turkish Republic of Northern Cyprus.
[11] Erden, Z., 2011, "State-Based Conceptual Design in Mechatronics via Petri
Nets", Control Engineering and Applied Informatics, Vol. 13, No. 2, pp.70-75.
[12] Goodman, E.D., Seo, K., Rosenberg, R. C., Fan, Z., Hu, J. and Zhang, B., 2002,
“Automated Design Methodology for Mechatronic Systems Using Bond Graphs and
Genetic Programming”, Proc. 2002 NSF Design, Service and Manufacturing
Grantees and Research Conference, San Juan, Puerto Rico, pp.206-221.
[13] Ziegler, B. P., 1989, “DEVS representation of dynamic systems: Event-based
intelligent control”, Proceeding of the IEEE. Vol.77, No.1, pp.72-80.
78
[14] Peterson, J. L., 1977, “Petri Nets”, ACM Computing Surveys, Vol.9, pp.223-
252.
[15] Murata, T., 1989, “Petri Nets: Properties, Analysis and Applications”,
Proceedings of the IEEE, Vol.77, No4, pp.541-580.
[16] Ullman, D., 1997, “The Mechanical Design Process”, 2nd edition, New York,
McGraw-Hill.
[17] Roozenburg, N.F.M. and Eekels, J., 1995, “Product Design: Fundamentals and
Methods”, West Sussex, John Wiley and Sons.
[18] Suh, N., 1990, “The Principles of Design”, Oxford University Press.
[19] Erden, M. S., Komoto, H., Van Beek, T.J., D’Amelio, V., Echavarria, E.,
Tomiyama, T., 2008, “A Review of Function Modelling: Approaches and
Applications”, Artificial Intelligence for Engineering Design, Analysis and
Manufacturing (AIEDAM), Vol.22, pp.147-169.
[20] Deng, Y. M., Tor, S. B., Britton, G. A., 2000, “A Dual-Stage Functional
Modelling Framework with Multi-Level Design Knowledge for Conceptual
Mechanical Design”, Journal of Engineering Design, Vol.11, No.4, pp.347-375.
[21] Chandrasekaran, B. and Josephson, J. R., 2000, “Function in Device
Representation”, Engineering with Computers, Vol.16, pp.162-177.
[22] Umeda, Y., Tomiyama, T., 1997, “Functional Reasoning in Design”, IEEE
Expert, Vol.12, No.2, pp.42-48.
[23] Zhang, W. Y., Tor, S. B., Britton, G. A., Deng, Y. M., 2002, “Functional Design
of Mechanical Products based on Behavior-driven function-environment-structure
modeling framework”, Innovation in Manufacturing Systems and Technology.
[24] Zhang, W. Y., Tor, S. B., Britton, G. A., 2005, “A Graph and Matrix
Representation Scheme for Functional Design of Mechanical Products”, International
Journal of Advanced Manufacturing Technology, Vol.25, No.3-4, pp.221-232.
[25] Deng, Y. M., and Zhu, Y. W., 2009, “Function to structure/material mappings
for conceptual design synthesis and their supportive strategies”, International Journal
of Advanced Manufacturing Technology, Vol.44, pp.1063-1072.
[26] Stone, R., Wood, K., 2000, “Development of a Functional Basis for Design”,
Journal of Mechanical Design, Vol.122, pp.359-370.
[27] Hirtz, J., Stone, R. B., McAdams, D. A., Szykman, S., Wood, K. L., 2002, “A
functional basis for engineering design: Reconciling and evolving previous efforts”,
Research in Engineering Design, Vol.13, pp.65–82.
79
[28] Bohm, M. R., Stone, R. B., Szykman, S., 2005, “Enhancing Virtual Product
Representations for Advanced Design Repository System”, Journal of Computing
and Information Science in Engineering, Vol.5, No.4, pp.360-372.
[29] Nagel, R. L., Midha, P.A., Tinsley, A., Stone, R. B., McAdams, D. A., Shu,
L.H., 2007, “Exploring the Use of Functional Models as a Fundation for Biomimetic
Conceptual Design”, ASME 2007 International Design Engineering Technical
Conferences & Computers and Information in Engineering Conference, IDETC/CIE
2007, Las Vegas, Nevada, USA
[30] Bracewell, R. H., Sharpe, J. E. E., 1996, “Functional Descriptions Used in
Computer Support for Qualitative Scheme Generation-Schemebuilder”, Artificial
Intelligence for Engineering Design, Analysis and Manufacturing (AIEDAM),
Vol.10, No.4, pp.333-346.
[31] Goel, A., Rugaber, S., Vattam, S., Structure, 2009, “Behavior and Function of
Complex Systems: The SBF Modelling Language”, Artificial Intelligence for
Engineering Design, Analysis and Manufacturing (AIEDAM), Vol.23, No.1, pp.23-
35.
[32] Kurtoğlu, T., Campbell, M. I., 2009, “Automated Synthesis of
Electromechanical Design Configurations from Empirical Analysis of Function to
Form Mapping”, Journal of Engineering Design, Vol.20, No.1, pp.83-104.
[33] Kitamura, Y., Kashiwase, M., Fuse, M., Mizoguchi, R., 2004, “Deployment of
an Ontological Framework of Functional Design Knowledge”, Advanced
Engineering Informatics, Vol.18, pp.115-127.
[34] Kitamura, Y., Koji, Y., Mizoguchi, R., 2006, “An Ontological Model of Device
Function: Industrial Deployment and Lessons Learned”, Applied Ontology, Vol.1,
No.3-4, pp.237-262.
[35] Liang, V-C., Paredis, C. J. J., 2004, “A Port Ontology for Conceptual Design of
Systems”, Transactions of the ASME-Journal of Computing Information Science in
Engineering, Vol.4, pp.206-217.
[36] Buur, J., 1990, “A Theoretical Approach to Mechatronics Design”, PhD Thesis,
Institute for Engineering Design, Technical University of Denmark.
[37] Chen, K., Bankston, J., Pachal, J. H., Schaefer, D., 2009, “A Framework for
Integrated Design of Mechatronic Systems”, Collaborative Design and Planning for
Digital Manufacturing, Springer, London, pp. 37-56.
[38] Fan, Z. Wang, J., Goodman, E., 2004, “Exploring Open-Ended Design Space of
Mechatronic Systems”, International Journal of Advanced Robotic Systems, Vol.1,
No.4, pp.295-302.
[39] Isermann, R., 1996, “Modeling and Design Methodology for Mechatronic
Systems”, IEEE/ASME Transactions on Mechatronics, Vol.1, No.1, pp.16-28.
80
[40] Wang, J., Fan, Z., Terpenny, J. P., Goodman, E. D., 2008, “Cooperative Body-
Brain Coevolutionary Synthesis of Mechatronic Systems”, Artificial Intelligence for
Engineering Design, Analysis and Manufacturing (AIEDAM), Vol.22, pp.219-234.
[41] Mrozek, Z., 2003, “Computer Aided Design of Mechatronic Systems”,
International Journal of Applied Mathematics and Computer Science, Vol.13, No.2,
pp.255–267.
[42] Borutzky, W., 2010, “Bond Graph Methodology; Development and Analyses of
Multidisciplinary Dynamic System Models”, Springer, ISBN 978-1-84882-882-7
[43] Bradley, D. A., Bracewell, R. H. and Chaplin, R. V., 1993, “Engineering
Design and Mechatronics - The Schemebuilder Project”, Research in Engineering
Design, Vol. 4, No.4, pp.241-248.
[44] Otter,M., Elmqvist, H. and Cellier, F. E., 1996, “Modeling of multibody systems
with the object oriented modeling language Dymola”, Nonlinear Dynamics, Vol.9,
No.1-2, pp.91-112.
[45] www.dynasim.se, download date: 01.07.2012
[46] Fritzson P., Gunnarsson, J. and Jirstrand, M., 2002, “MathModelica-An
Extensible Modelling and Simulation Environment with Integrated Graphics and
Literate Programming”, Second International Modelica Conference, Germany.
[47] Elmqvist, H., Mattsson, S. E. and Otter, M., 1999, “Modelica-A Language for
Physical System Modelling, Visualization and Interaction”, IEEE Symposium on
Computer-Aided Control System Design (CACSD ’99), Hawaii, USA
[48] www.modelica.org, download date: 01.07.2012
[49] Fan, Z., Seo, K., Hu, J., Goodman, E.D. and Rosenberg, R. C., 2004, “A Novel
Evolutionary Engineering Design Approach for Mixed-Domain Systems”,
Engineering Optimization, Vol.36, No.2, pp.127-147.
[50] Secchi, C., Bonfe’, M., and Fantuzzi, C., 2007, “On the use of UML for
modeling mechatronic systems”, IEEE Transactions on Automation Science and
Engineering (T-ASE), Vol.4, No.1, pp.105–113.
[51] Sell, R., Tamre, M., Lehtla, M.,Rosin, A., 2008, “A Conceptual Design Method
for the General Electric Vehicle”, Estonian Journal of Engineering, Vol.14, No.1,
pp.3-16.
[52] Van der Vegte, W. F, 2006, “A Survey of Artefact Simulation Approaches from
the Perspective of Application to Use Processes of Consumer Durables”, Proceedings
of Tools and Methods for Competitive Engineering (TMCE2006), Ljubljana,
Slovenia, pp.617-632.
[53] Xu, C., Gupta, S. K., Yao, Z., Gruninger, M., Sriram, R., 2005, “Towards
Computer-Aided Design of Mechatronic Devices with Multiple Interaction-States”,
81
ASME 2005 Design Engineering Techn. Conf. and Computers and Information in
Engineering Conference (DETC/CIE 2005), Long Beach, California, USA.
[54] Van der Vegte, W. F. and Horvath, I., 2002, “Consideration and Modeling of
Use Processes in Computer-Aided Conceptual Design: A State of the Art Review”,
Transactions of the SPDS-Journal of Integrated Design and Process Science, Vol.6,
No.2, pp.25-59.
[55] Erden, Z., Erden, A. and Erkmen, A. M., 2003, “A Petri Net Approach to
Behavioral Simulation of Design Artifacts with Application to Mechatronic Design”,
Research in Engineering Design, Vol.14, pp.34-46.
[56] Erden, Z., 2010, “Representation of the Operational Behaviour of an
Educational Robot at Conceptual Design Using Petri Nets”, Proceedings of the
ASME 2010 10th Biennial Conference on Engineering Systems Design and Analysis
(ESDA 2010), Istanbul, Turkey.
[57] Wang, J., 1998, “Timed Petri Nets”, Springer, ISBN: 0-7923-8270-6.
[58] “Artifex TM
4.4 Getting Started Handbook, RSoft Design Group”, (2003, 2004),
USA
[59] “Artifex TM
4.4 User Manual handbook, RSoft Design Group”, (2003, 2004),
USA
[60] Anon, 2011, “Development of biomimetic design methodology with reverse
engineering in cognitive recognition and control of biomimetic robots”, Project
Progress Report, December 2011 (Project No: TÜBİTAK 109M379).
[61] Eroğlu-Konez, A, Güner, E., Gürel, C., Erden, Z. and Erden, A., 2012, “Design
and Manufacturing of a Cockroach Biorobot for Implementation of a Bioinspired
Conceptual Design (BICD) Methodology”, Proceedings of the 15th
International
Conference on Machine Design and Production, Pamukkale-Denizli, Turkey.
[62] Araz, M. and Erden, Z., 2012, “A Case Study on Behavior Based Modelling of
Educational Robots at Conceptual Design: Behavioral Simulation of a Pick Packing
AGV Using Petri Nets”, Proceedings of the 15th
International Conference on
Machine Design and Production, Pamukkale-Denizli, Turkey.
82
APPENDIX A
DESCRIPTION ArtifexTM
SOFTWARE
ArtifexTM
software is developed for design, simulation and evaluation of discrete event
systems utilizing Petri Net formalism. ArtifexTM
is a C/C++ based graphical tool to develop
and analyze natural and engineering systems such as network protocols, control panel
architectures and switching machines [58].
The software has the ability of C/C++ code integration with models. By this way, the software
provides additional capabilities in comparison with the classic Petri Nets. ArtifexTM
has also
the ability of automatic report and measurement.
ArtifexTM
allows validation and simulation at any stage during model development.
“ArtifexTM
Measure” tool provides the user a perfect visual representation of the models’
implementation process. “ArtifexTM
Report” competence let user to obtain a very detailed
documentation about the model while Measurement skill of the software provides a powerful
data collecting tool [58].
In this appendix, a brief knowledge about ArtifexTM
basics and its frequently used tools is
given.
Creating a New Project:
ArtifexTM
starts using Startup dialog window (Figure A.1). By the Startup window, a new
project or library could be created as well as opening already existed projects.
Figure A.1 Startup Dialog Window
83
In the case of selecting “Create new project” related window, given in Figure A.2, pops up
and the user is requred to write “Name”, “Location”, “Title” and “Description” of the new
project in the related plank spaces. Clicking on the button “Create” the window “Model
Manager” opens (Figure A.3). The user reaches to most of the important and frequently used
tools of the software from this window. Clicking on the related icons on the toolbar they can
be activated.
Figure A.2 create New Project Dialog Window
Table A.1 contains brief explanation for some of the tool icons located on the ArtifexTM
Model Manager’s tool bar [59];
Figure A.3 ArtifexTM
Model Manager Window
84
Table A.1 Explanation for some of icons on the ArtifexTM
Model Manager’s Toolbar
Icon Name Explanation
New
Project
Creates a new project
Open Opens an existing project
Open Unit Opens Model editor page which is used to design and draw the model
Update Updates the developed model and relationships between the project
units
Project
Properties
Provides a detailed list of project properties opening a dialog window
Build
Model
Creates the simulator file to validate the model of the current ArtifexTM
project
Start
Validate
Starts the Validate tool to simulate and validate the model of the
current project
Start Batch
Run
Starts the ArtifexTM
Batch Run tool to define parametric runs for the
current project to run several simulations of the same model with
different parameter values
Start
Measure
Starts the ArtifexTM
Measure tool to apply coverage and dynamic
metrics to the model of the current project
Start
Report:
Starts ArtifexTM
Report tool to detailed documentation of the current
project
Help Starts the HTML online help system
ArtifexTM
Model Editor Window
When the user double clicks on the “Toplevel: Project” icon or clicks on the “Open Unit”
button in the ArtifexTM
Model Manager window, ArtifexTM
Model Editor appears as
illustrated in Figure A.4.
85
Figure A.4 ArtifexTM
Model Editor Window
ArtifexTM
Model Editor window is composed of four main parts called “Main Tool Bar”,
“Drawing Area”, “Class-Tree Area” and “Drawing Tool Bar”, which are shown on Figure
A.4.
Before further progress defining some main notions would be useful:
ArtifexTM
Class: A class which is the main entity of an ArtifexTM
model. An ArtifexTM
class is
an abstract entity that represents a set of items (objects) sharing the same behavior. Each class
may contain C or C++ source code and is divided in two main sections: the interface and the
body, as represented in the Class-Tree Area of Figure A.4. A class consists of several parts
and includes a variety of components.
Object: An ArtifexTM
model may consists of previously created independent projects. In other
words, any previously created ArtifexTM
project may be used in a new project. Previous
projects are represented by objects in a new project. Current project may include many
objects, which means that an object is an instance of a class and it can communicate by means
of asynchronous massages (tokens) through links from output places to input places (or
Linksets between Portsets).
Portset and Linkset: A portset defines the entry point of one of the linksets connected to the
object. A portset is an ordered set of input and output places of a class. Portsets could be
considered as terminals or connectors that a multi-wire cable is bound.
86
Accordingly Linksets represents the set of links that connect two portsets in two different
objects. A Linkset could be considered as a multi-wire cable.
Subnet and Page: An ArtifexTM
project can consist of one or more subnets and each subnet
can include one or more pages. Subnets are architectural elements of the body of a class
which can be used for top-down specification of the class’ body structure. In the same way a
page represents the physical location where the icons and connections are drawn for the
implementation of a subnet.
Token and Token type: a token is an elementary information unit that follows in a model, is
processed by transition and is stored by places. Tokens may represent data that follow in the
model, events that trigger some activities or the current state of an object. A token type is a C-
struct type declaration that defines the data type of (some) tokens. If a type is not defined for a
token it is automatically assigned as NUL type.
Some major tools of an ArtifexTM
model represented by icons on Drawing Tool Bar are
explained in Table A.2.
Some other essential entities frequently used in the ArtifexTM
models could be defined as
following;
Code Sections: Code sections are C/C++ expanded code unchanged into the generated code.
Each section has a particular purpose and a unique expansion order. Code section is divided
into subparts such as functions, initial actions and final actions.
Parameters: A parameter of a class is a variable of C scalar type or string whose initial value
can be assigned to each object. Parameters are a way to characterize objects of the same class.
Local variables: A local variable of a class represents data that is visible from the initial
action, the final action and from all actions and predicates of the class. The initial value of
local variables must be set up by the class initial action.
CMN Units: The CMN units define the data structures of a class exchanged with other
classes, i.e. the token types exchanged between objects. CMN stands for "communication".
The root icon of the CMN unit structure changes according to the C/C++ language.
87
Token Types: a token type is a C-struct type declaration that defines the data type of tokens.
A given place can only store tokens of one type (the place's token type).
Table A.2 Explanation for Tool Icons on Drawing Tool Bar of ArtifexTM
Model Editor
Window
Icon Name Explanation
Selection Tool Allow to select one or more items on the drawing area
Object Tool Insets in the drawing one or more undefined objects
Subnet Tool Insert the drawing area undefined subnets
Page Reference Inserts one or more undefined page references into the drawing
area
Portset
Reference
Inserts one or more undefined portset references into the drawing
area
Place Tool Inserts place icons into the drawing area
Input Place Tool Inserts input place icons into the drawing area
Output Place
Tool
Inserts output place icons into the drawing area
Transition Tool Inserts transition icons into the drawing area
Connection
Tool:
Inserts directed connections between items.
Bidirectional
Arc Tool
Inserts bidirectional arc tools between items.
Linkset Tool Inserts Linksets between objects
Text Tool Inserts texts regions in drawing areas.
Constructing a Model
After opening the ArtifexTM
Model Editor window, user can begin to draw the model in
drawing area by clicking on the drawing tool icons such as places or transitions which could
be connected by links. An example ArtifexTM
mode is illustrated in Figure A.5.
88
Figure A.5 ArtifexTM
Model Window
Places and transition in ArtifexTM
model has a properties dialog window (Figure A.5).
A place properties dialog window consists of three sections, “Basic Attributes”, “Code
Section” and “Description”. In the basic attributes of the place properties dialog window place
name can be written or the place may be merged by another place. The “Merge” command
allows user to merge the current place with another place already drawn in another page. The
“Type” field defines the place type, i.e. the type of the tokens that can be queued into the
place.
Figure A.6 Place Properties Dialog Window
The “Starting Tokens” field defines the number of tokens that the place contains at the
beginning of execution. In the “Code Section” C codes may be wrritten for starting tokens.
The “Description” section is used to document the place. All the settings made will be used by
Artifex.Report to write a final report on the project.
Similar to places, each transition has also properties dialog window (Figure A.7) which
consists of four tabs as “Basic Attributes”,” Predicate”, “Action” and “Description”.
89
Figure A.7 Transition Properties Dialog Window
In “Basic Attributes” section the name field defines the transition name. The “Priority” field
defines the transition priority. A transition may appears in vertical or horizental position
which can be related by the related tab. This attribute does not affect transition's behavior.
“Firing Delay” option defines whether the transition should have delayed firing behavior.
“Release Delay” option defines whether the transition should have a release delay.
When the “Predicate” tab is selected a new window appears, as represented in Figure A.8.
User defines a C Boolean condition that can test the tokens queued in the transition's input
places, the local variables and the parameters.
Figure A.8 Transition Properties Dialog Window-Predicate Section
“Action” tab is used to write C/C++ statements (Figure A.9). Variables and any valid C/C++
statement may be defined here. The action of a transition can read the data stored onto the
tokens fetched from the transition's input places and it can read and write data onto the tokens
that will be released to the transition's output places.
90
Figure A.9 Transition Properties Dialog Window - Action Section
The “Description” section is used to document the transition. All the settings made will be
used by ArtifexTM
Report.
Figure A.10 Transition Parameters Dialog Window - Description Section
Validating and Simulating an ArtifexTM
Model
After constructing an ArtifexTM
model in ArtifexTM
Model Editor window it can be validated
and simulated using ArtifexTM
Validate tool. The first step is building the simulator using the
“Build Model” ( ) tool. The second is starting simulation “Start Validate” ( ). So the
ArtifexTM
Validate window appears, as shown in Figure A.11.
Validation and simulation the ArtifexTM
Model is done by ArtifexTM
Validate tool.
91
Figure A.11 ArtifexTM
Validate Window
The ArtifexTM
Validate is the tool used to verify the behavior of the models. With this tool
user can control and debug the model running a step-by-step simulation, setting breakpoints
and examining the contents of tokens and other object data. The toolbar allows user to control
the simulator execution. The Figure A.12 illustrates parts of the tool bar.
Figure A.12 ArtifexTM
Validate Toolbar
Clicking the Run button system’s Run Parameters window appears as given in Figure A.13.
With this dialog user can define some options that will be in effect for all the simulation run.
Figure A.13 Run Parameters Window
92
After choosing the current project from “Context Files”, timing options may be adjusted by
“Time Unit”. Clicking on OK button the simulator will be activated and an input/output page
is opened as represented in Figure A.14.
Figure A.14 ArtifexTM
Validate Window and I/O Page of the Simulator
At this stage the model simulation can be started and observed. The simulation can be carried
out in step-by-step and continuous modes. Also it can be in true time or virtual time modes.
ArtifexTM
Batch Run Tool
The ArtifexTM
Batch Run is the tool that manages batch simulations without using the
ArtifexTM Validate tool. Figure A.15 illustrates ArtifexTM
Batch Run window. The
simulations are only of batch type, user cannot see the model behavior during the simulation,
but measurement data can be collected to display with the ArtifexTM
Measure tool.
Figure A.15 ArtifexTM
Batch Run Tool Window
93
ArtifexTM
Measurement Tool
When the simulation is ended, one can start ArtifexTM
Measure to analyze the produced
measurements. ArtifexTM
Measure is the graphic tool that enables user to analyze results of an
ArtifexTM
model simulation.
Figure A.16 ArtifexTM
Measure Tool Window
Dynamic metrics are computed by processing measurement data files produced by ArtifexTM
Batch Run or ArtifexTM
Validate during simulation. There are three different kinds of metrics
in ArtifexTM
as follows:
User-Defined Metrics: Enables users to define custom metrics within a model, gather
variable's data during simulation and eventually plot the results
Simulation Metrics: Provides information about quantities that are directly bound to
ArtifexTM
model's elements, such as place queues lengths, transitions and objects scheduling,
and transition firing frequency
Coverage Metrics: Provide information about how much of a model has been executed in
one or more simulation runs; coverage is expressed in the form of transitions coverage that
tell the percentage of transitions that never fired in a number of simulation runs
94
Documenting
ArtifexTM
’s documenting tool is called ArtifexTM
Report, shown in Figure A.17. ArtifexTM
Report is the tool that generates the ArtifexTM
document collecting all the descriptions and the
pictures of the ArtifexTM
elements of current project.
Figure A.17 ArtifexTM
Report Window
The ArtifexTM
document embeds all (or some of) the model information, both textual and
graphical. The document is generated following the document layout and the style option
rules defined by the ArtifexTM
Report tool. It is very easy to keep the ArtifexTM
document up-
to-date, since the document is automatically generated collecting all the descriptions and the
pictures of the ArtifexTM
elements.
95
APPENDIX B
THE REPORT CREATED FOR CURVE FOLLOWING ROBOT BY
DOCUMENTATION TOOL OF ARTIFEX SOFTWARE
ATILIM UNIVERSITY
Curve Following Robot
Artifex Report
04/11/2011
Project Supervisor: Asst. Prof. Zuhal Erden
Research Assistant: Macit Araz (Majid Javadi)
Mechatronics Department
Table of Contents
Abstract
Introduction
Artifex class CURVE_FOLLOWING_ROBOT_BY_OBJECTS (interface)
Artifex class CURVE_FOLLOWING_ROBOT_BY_OBJECTS (body)
Artifex class POWER_SOURCE (interface)
Artifex class POWER_SOURCE (body)
Artifex class PROCESSOR (interface)
Artifex class PROCESSOR (body)
Artifex class LEFT_MOTOR (interface)
Artifex class LEFT_MOTOR (body)
96
Artifex class LEFT_SENSOR (interface)
Artifex class LEFT_SENSOR (body)
Artifex class RIGHT_MOTOR (interface)
Artifex class RIGHT_MOTOR (body)
Artifex class RIGHT_SENSOR (interface)
Artifex class RIGHT_SENSOR (body)
Measure Results
List of Figures
1. Object Hierarchy 2. Artifex class CURVE_FOLLOWING_ROBOT_BY_OBJECTS: Subnet Hierarchy 3. Artifex class CURVE_FOLLOWING_ROBOT_BY_OBJECTS: Page
CURVE_FOLLLOWING_ROBOT_OBJECTS 4. Artifex class POWER_SOURCE: Subnet Hierarchy 5. Artifex class POWER_SOURCE: Page POWER_SOURCE_UNIT 6. Artifex class PROCESSOR: Subnet Hierarchy 7. Artifex class PROCESSOR: Page PROCESSING_UNIT 8. Artifex class PROCESSOR: Page STATISTICS 9. Artifex class LEFT_MOTOR: Subnet Hierarchy 10. Artifex class LEFT_MOTOR: Page DC_MOTOR_LEFT 11. Artifex class LEFT_SENSOR: Subnet Hierarchy 12. Artifex class LEFT_SENSOR: Page LEFT_SENSOR 13. Artifex class RIGHT_MOTOR: Subnet Hierarchy 14. Artifex class RIGHT_MOTOR: Page DC_MOTOR_RIGHT 15. Artifex class RIGHT_SENSOR: Subnet Hierarchy 16. Artifex class RIGHT_SENSOR: Page RIGHT_SENSOR 17. Superimposed Rate Chart
Abstract
This is a Petri Net based model of an educational Curve Following Robot designed in Artifex
environment. It is tried to get close to a real robot construction using virtual mechatronic
components created in Artifex environment as separate objects aiming to observe the behavior of
real robot.
97
1 Introduction
Modeling possible behavior of an artifact in conceptual design stage is an important research field in
terms of developing product behavior simulation and computer-aided conceptual design tools.
Behavior modeling is important for multi-disciplinary product designs which utilize deduction design
approach such as mechatronic design.
From this point of view, the case study reported below, is a Behavior Based model of an educational
Curve Following Robot. Constituting Petri Net based separate Objects as the mechatronic
components such as power source, processor, motor and sensors we try to set up a robot virtually in
pro-manufacturing level to observe the behavior of the real robot. The aim is to reduce the time and
cost spent during the design process.
1.1 Units List
CURVE_FOLLOWING_ROBOT_BY_OBJECTS
Artifex class
LEFT_MOTOR
Artifex class
LEFT_SENSOR
Artifex class
POWER_SOURCE
Artifex class
PROCESSOR
Artifex class
RIGHT_MOTOR
Artifex class
RIGHT_SENSOR
Artifex class
1.2 Model Architecture
98
2 Unit
CURVE_FOLLOWING_ROBOT_BY_OBJ
ECTS
Artifex Class (Interface)
There is no Interface elements.
3 Unit
CURVE_FOLLOWING_ROBOT_BY_OBJ
ECTS
Artifex Class (Body)
This Artifex Mofdel of a Curve Following Robot consists of five objects; Power Source (Battery),
ProcessingUnit (ARDUINO) , two DC motors and two light sensors.
3.1 Object Hierarchy
3.2 Subnet Hierarchy
99
3.3 Subnet MAIN_SUBNET
Subnet priority: 0
It includes only one page named CURVE_FOLLOWING_ROBOT_OBJECTS, which contains the objects.
3.3.1 Page CURVE_FOLLLOWING_ROBOT_OBJECTS
This Page (the only page of subnet) contains six objects;
Power Source Unit,
Processor Unit,
Right and Left Sensor Units,
Right and Left (DC) Motor Units.
3.3.1.1 Object L_M
This object represents the left DC motor in the Curve Following Robot.
3.3.1.2 Object L_S
This object represents the left sensor in the Curve Following Robot.
3.3.1.3 Object P
This unit is the brain of the system wich processes data and make decisions to run the system. This
unit symbolizes the ARDUINO processing board.
3.3.1.4 Object P_S
This object represents the baterry of the robot model.
3.3.1.5 Object R_M
This object represents the right DC motor in the Curve Following Robot.
3.3.1.6 Object R_S
This object represents the right sensor in the Curve Following Robot.
3.3.1.7 Link from PROCESSOR_POWER (in P_S) to PROCESSOR_POWER (in P)
Connects the Power Source unit (battery) to the Processing Unit (ARDUINO)
3.3.1.8 Linkset between RIGHT_MOTOR (in P) and RECEIVE_PROCESSOR (in
R_M)
Connects Processing unit to Right Motor Unit.
100
3.3.1.9 Linkset between LEFT_MOTOR (in P) and RECEIVE_PROCESSOR (in L_M)
Connects Processing unit to Left Motor Unit.
3.3.1.10 Linkset between RECEIVE_PROCESSOR (in R_S) and RIGHT_SENSOR (in
P)
Connects Processing unit to Right Sensor Unit.
3.3.1.11 Linkset between RECEIVE_PROCESSOR (in L_S) and LEFT_SENSOR (in P)
Connects Processing unit to Leftt Sensor Unit.
4 Unit POWER_SOURCE
Artifex Class (Interface)
Power Source Unit contains five out put places as interface elements.
4.1 Output Places
4.1.1 PROCESSOR_POWER (?)
Processor Power output place: To empower the processor by baterry.
5 Unit POWER_SOURCE
Artifex Class (Body)
Power Source Unit consists of two places and two transitions wich supplies power for five output
places of the other system components.
Also it includes one Local variable and one line Initial Action as Body elements.
5.1 Local Variables
Name Type Description
POWER int An integer type Local Variable utilised to define a
capacity for power source (battery life).
101
5.2 Initial Actions
XX->POWER=0;
Sets the Local Variable "Power" to zero at the beginning.
5.3 Object Hierarchy
5.4 Subnet Hierarchy
5.5 Subnet MAIN_SUBNET
Subnet priority: 6
Has only one page named POWER_SOURCE_UNIT.
5.5.1 Page POWER_SOURCE_UNIT
Power Source Unit consists of two places and two transitions wich supplies power for five output
places of the other system components.
5.5.1.1 Place POWER
After receiving the starting token from Start Power place sends that to Power Terminal transition
trough a bidirectional arc and as a result receives an other one again.
5.5.1.2 Place START_POWER
Provides the Power Source Unit with an initial token
102
properties
It has 1 starting tokens
5.5.1.3 Transition FIRE_POWER
Sends the stating token to Power place from Start Power place.
action
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
5.5.1.4 Transition POWER_TERMNAL
This transition sends tokens to other componets of the system to empower them. It has a limited
capacity to send tokens and after a while its capacity runs out (wich is determined by Local Variable
Power)
properties
It has Firing Delay: initial value is 107 (relative)
predicate
XX->POWER<99
action
++(XX->POWER);
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
6 Unit PROCESSOR
Artifex Class (Interface)
Processor Unit's Interface elements are;
Five input places,
Twelve output places,
Four portsets,
Three User Measure elements.
6.1 Input Places
103
6.1.1 PROCESSOR_POWER (?)
Input place to the Processing unit from Power Source unit used to empower the other units.
6.1.2 RECEIVE_COMMAND_LEFT (?)
Receives input data (token) from Left Sensor .
6.1.3 RECEIVE_COMMAND_RIGHT (?)
Receives input data (token) from Right Sensor.
6.1.4 RESENSE_LEFT_IN (?)
To receive the command to start the resinsing action after a turn of motor's working time.
6.1.5 RESENSE_RIGHT_IN (?)
To receive the command to start the resinsing action after a turn of motor's working time.
6.2 Output Places
6.2.1 LEFT_M_BACK (?)
Left Motor Backward output place: Is connected to LEFT_M_BACK input place in Left Motor through
linkset.
6.2.2 LEFT_M_FORE (?)
Left Motor Forward output place: Is connected to LEFT_M_FORE input place in Left Motor through
linkset.
6.2.3 LEFT_M_STOP (?)
Left Motor Stop output place: Is connected to LEFT_M_STOP input place in Left Motor through
linkset.
6.2.4 L_M_POW (?)
The output place to send the empowering token to the Left Motor.
6.2.5 L_S_POW (?)
The output place to send the empowering token to the Left Sensor.
6.2.6 RESENSE_LEFT_OUT (?)
104
Sends resensing command to sensor.
6.2.7 RESENSE_RIGHT_OUT (?)
Sends resensing command to sensor.
6.2.8 RIGHT_M_BACK (?)
Right Motort Backward output place: Is connected to RIGHT_M_BACK input place in right motor
through linkset.
6.2.9 RIGHT_M_FORE (?)
Right Motor Forward output place: Is connected to RIGHT_M_FORE input place in right motor
through linkset.
6.2.10 RIGHT_M_STOP (?)
Right Motor Stop output place: Is connected to RIGHT_M_STOP input place in right motor through
linkset.
6.2.11 R_M_POW (?)
The output place to send the empowering token to the Right Motor.
6.2.12 R_S_POW (?)
The output place to send the empowering token to the Right Sensor.
6.3 Portsets
6.3.1 LEFT_MOTOR
Includes four output and one input places. Is used to connect the Left Motor to the processor
through a linkset.
(Output) LEFT_M_FORE:?
(Output) LEFT_M_BACK:?
(Output) LEFT_M_STOP:?
(Output) L_M_POW:?
(Input ) RESENSE_LEFT_IN:?
6.3.2 LEFT_SENSOR
Includes two output and one input places. Is used to connect the Left Senor to the processor through
a linkset.
105
(Output) L_S_POW:?
(Input ) RECEIVE_COMMAND_LEFT:?
(Output) RESENSE_LEFT_OUT:?
6.3.3 RIGHT_MOTOR
Includes four output and one input places. Is used to connect the Right Motor to the processor
through a linkset.
(Output) RIGHT_M_FORE:?
(Output) RIGHT_M_BACK:?
(Output) RIGHT_M_STOP:?
(Output) R_M_POW:?
(Input ) RESENSE_RIGHT_IN:?
6.3.4 RIGHT_SENSOR
Includes two output and one input places. Is used to connect the Right Sensor to the processor
through a linkset.
(Output) R_S_POW:?
(Input ) RECEIVE_COMMAND_RIGHT:?
(Output) RESENSE_RIGHT_OUT:?
6.4 Measures
Name Attributes Description
left_turn_id LEFT TURN A User Measure instrument used to obtain the
rate of the which robot turns left.
right_turn_id RIGHT TURN A User Measure instrument used to obtain the
rate of the which robot turns right.
straight_line_id STRAIGHT LINE A User Measure instrument used to obtain the
rate of the which robot goes straight.
7 Unit PROCESSOR
Artifex Class (Body)
Processor Unit: Consists mainly of five transitions and one place alongside three input and six output
places.
106
Additionally there are six Local Variables and Initial Conditions.
7.1 Local Variables
Name Type Description
LEFT double A Double type Local Variable utilised in User
Measure element of "left_turn_id".
RIGHT double A Double type Local Variable utilised in User
Measure element of "right_turn_id".
SENSE1 double A Double type Local Variable utilised in decision
making for the robot behaviour.
SENSE2 double A Double type Local Variable utilised in decision
making for the robot behaviour.
STRAIGHT double A Double type Local Variable utilised in User
Measure element of "stright_line_id".
TOTAL double A Double type Local Variable utilised in all three
User Measure elements.
7.2 Initial Actions
XX->TOTAL=0.0;
XX->STRAIGHT=0.0;
XX->RIGHT=0.0;
XX->LEFT=0.0;
Resets the four Local Variabels used in User Measures to zero.
7.3 Object Hierarchy
7.4 Subnet Hierarchy
7.5 Subnet MAIN_SUBNET
107
Subnet priority: 1
Includes two pages;
PROCESSOR page and STATISTICS page.
7.5.1 Page PROCESSING_UNIT
Symbolise the processing unit (ARDUINO) of Curve Following Unit. It can decide if the robot must
turn left or right, stop or go straight according to the signals received from sensors.
7.5.1.1 Place ENFORCE_COMMAND
This place convey the received tokens and enables the transitions which decide about the behavour
of motors.
7.5.1.2 Place POWER_IN
Processors power input place.
7.5.1.3 Transition EMPOWER
To send tokens to system components to empower them.
properties
108
It has Release Delay: initial value is 1 (relative)
7.5.1.4 Transition LEFT
According to the Predicates written this transition decides if the robot must turn leftt and sends such
a command to motors. It take place when variable SENSE2 is lower than 0.5 (which represents puls 0)
and SENSE1 is highr than 0.5 (which represents puls 1).
In the Action section this transition also adds 1 to the value of variable LEFT which is used in User
Measure of "left_turn_id". In the same time it stes the two variables of SENSE1 and SENSE2 to zero
after the decision is made.
properties
It has Release Delay: initial value is 1 (relative)
predicate
XX->SENSE1>0.5 & XX->SENSE2<0.5
action
XX->SENSE1=0.0;
XX->SENSE2=0.0;
++(XX->LEFT);
7.5.1.5 Transition RECEIVE_COMMAND
This transition is fired after receiving tokens from Power Source and the sensors.
It is incuding also some Actions to increase the value of variable TOTAL, which is used in User
Measures, and to assign random values (between 0 and 1 ) to variables SENSE1 and SENSE2. It lso
inculdes some Actions to change the State and Color of the Object Processor in the Main Page.
properties
It has Release Delay: initial value is 1 (relative)
action
XX->SENSE1=xu_RndDouble();
XX->SENSE2=xu_RndDouble();
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
++(XX->TOTAL);
109
7.5.1.6 Transition RESENSE_LEFT
Processes resensing command to sensor.
properties
It has Release Delay: initial value is 1 (relative)
7.5.1.7 Transition RESENSE_RIGHT
Processes resensing command to sensor.
properties
It has Release Delay: initial value is 1 (relative)
7.5.1.8 Transition RIGHT
According to the Predicates written this transition decides if the robot must turn right and sends such
a command to motors. It take place when variable SENSE1 is lower than 0.5 (which represents puls 0)
and SENSE2 is highr than 0.5 (which represents puls 1). In the Action section this transition also adds
1 to the value of variable RIGHT which is used in User Measure of "right_turn_id". In the same time it
stes the two variables of SENSE1 and SENSE2 to zero after the decision is made.
properties
It has Release Delay: initial value is 1 (relative)
predicate
XX->SENSE1<0.5 & XX->SENSE2>0.5
action
XX->SENSE1=0.0;
XX->SENSE2=0.0;
++(XX->RIGHT);
7.5.1.9 Transition STOP
According to the Predicates written this transition decides if the robot must stop and sends such a
command to motors. It take place when the two variables of SENSE1 and SENSE2 are highr than 0.5
(which represents puls 1).
In the same time it stes the two variables of SENSE1 and SENSE2 to zero after the decision is made.
110
properties
It has Release Delay: initial value is 1 (relative)
predicate
XX->SENSE1>0.5 & XX->SENSE2>0.5
action
XX->SENSE1=0.0;
XX->SENSE2=0.0;
7.5.1.10 Transition STRAIGHT
According to the Predicates written this transition decides if the robot must goes straight and sends
such a command to motors. It take place when the two variables of SENSE1 and SENSE2 are lower
than 0.5 (which represents puls 0).
In the Action section this transition also adds 1 to the value of variable STRAIGHT which is used in
User Measure of "straight_turn_id". In the same time it stes the two variables of SENSE1 and SENSE2
to zero after the decision is made.
properties
It has Release Delay: initial value is 1 (relative)
predicate
XX->SENSE1<0.5 & XX->SENSE2<0.5
action
XX->SENSE1=0.0;
XX->SENSE2=0.0;
++(XX->STRAIGHT);
7.5.2 Page STATISTICS
111
A Subnet page for User Measure instruments. Includes three User Measure nets.
7.5.2.1 Place START1
A place utilised in User Measure instrument "straight_line_id". Includes one starting token.
properties
It has 1 starting tokens
7.5.2.2 Place START2
A place utilised in User Measure instrument "right_turn_id". Includes one starting token.
properties
It has 1 starting tokens
7.5.2.3 Place START3
A place utilised in User Measure instrument "left_turn_id". Includes one starting token.
properties
It has 1 starting tokens
7.5.2.4 Transition STATISTICS_LEFT
A transition utilised in User Measure instrument "left_turn_id". Includes some Actions to calculate
the rate of which the robot turns left.
properties
It has Firing Delay: initial value is 107 (relative)
112
action
double ratio_left;
if ((XX->TOTAL) !=0)
{
ratio_left=(XX->LEFT/XX->TOTAL)*100;
xx_writesample_d(XX->left_turn_id, ratio_left);
}
7.5.2.5 Transition STATISTICS_RIGHT
A transition utilised in User Measure instrument "right_turn_id". Includes some Actions to calculate
the rate of which the robot turns right.
properties
It has Firing Delay: initial value is 107 (relative)
action
double ratio_right;
if ((XX->TOTAL) !=0)
{
ratio_right=(XX->RIGHT/XX->TOTAL)*100;
xx_writesample_d(XX->right_turn_id, ratio_right);
}
7.5.2.6 Transition STATISTICS_STRAIGHT
A transition utilised in User Measure instrument "straight_line_id". Includes some Actions to
calculate the rate of which the robot goes on straight line.
properties
It has Firing Delay: initial value is 107 (relative)
action
double ratio_straight;
if ((XX->TOTAL) !=0)
{
ratio_straight=(XX->STRAIGHT/XX->TOTAL)*100;
xx_writesample_d(XX->straight_line_id, ratio_straight);
}
113
8 Unit LEFT_MOTOR
Artifex Class (Interface)
Includes one portset, four input places and one output place as Interface element.
8.1 Input Places
8.1.1 LEFT_M_BACK (?)
An input place, symbolizing backward mode of DC motor.
8.1.2 LEFT_M_FORE (?)
An input place, symbolizing forward mode of DC motor.
8.1.3 LEFT_M_STOP (?)
An input place, symbolizing Stop mode of DC motor.
8.1.4 L_M_POW (?)
An input place, takes rol as power input.
8.2 Output Places
8.2.1 RESENSE_LEFT (?)
An output place to let the token flow out the motor.
8.3 Portsets
8.3.1 RECEIVE_PROCESSOR
Includes three input places. Is used to connect the Processor to Left Motor through a linkset.
(Input ) LEFT_M_FORE:?
(Input ) LEFT_M_BACK:?
(Input ) LEFT_M_STOP:?
(Input ) L_M_POW:?
(Output) RESENSE_LEFT:?
114
9 Unit LEFT_MOTOR
Artifex Class (Body)
A Petri Net which symbolise a DC motor which has three functions as forward, backward and stop
modes and also an power input pin. In addition it has a output place to let the token flow.
9.1 Object Hierarchy
9.2 Subnet Hierarchy
9.3 Subnet MAIN_SUBNET
Subnet priority: 2
Contains one page named DC_MOTOR_LEFT.
9.3.1 Page DC_MOTOR_LEFT
Symbolizes a DC motor. Consists of four input places, one output place and three transitions.
9.3.1.1 Transition LMBC
A transition to symbolize backward mode of DC motor.
It lso inculdes some Actions to change the State and Color of the Object Right Motor in the Main
Page.
115
properties
It has Release Delay: initial value is 100 (relative)
action
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
9.3.1.2 Transition LMFC
A transition to symbolize forward mode of DC motor.
It lso inculdes some Actions to change the State and Color of the Object Right Motor in the Main
Page.
properties
It has Release Delay: initial value is 100 (relative)
action
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
9.3.1.3 Transition LMSC
A transition to symbolize stop mode of DC motor.
It lso inculdes some Actions to change the State and Color of the Object Right Motor in the Main
Page.
properties
It has Release Delay: initial value is 100 (relative)
action
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
10 Unit LEFT_SENSOR
Artifex Class (Interface)
Includes two input and one output places.
116
10.1 Input Places
10.1.1 L_S_POW (?)
Connects the Power Source to the Sensor. Sensor work depends on the token comes through this
input place from battery.
10.1.2 RESENSE_LEFT (?)
An input place to receive token and enable the resensing circuit.
10.2 Output Places
10.2.1 SEND_COMMAND_LEFT (?)
Connects the Sensor to the Processor.
10.3 Portsets
10.3.1 RECEIVE_PROCESSOR
(Input ) L_S_POW:?
(Output) SEND_COMMAND_LEFT:?
(Input ) RESENSE_LEFT:?
11 Unit LEFT_SENSOR
Artifex Class (Body)
A Petri Net which symbolise a light sensor which has the ability of distinguishing white and black
colors.
11.1 Local Variables
Name Type Description
SENSE1 double A Double type Local Variable utilised in decision
making for the robot behaviour.
SENSE2 double A Double type Local Variable utilised in decision
making for the robot behaviour.
117
11.2 Object Hierarchy
11.3 Subnet Hierarchy
11.4 Subnet MAIN_SUBNET
Subnet priority: 4
Includes one page named LEFT_SENSOR.
11.4.1 Page LEFT_SENSOR
Symlolize a light sensor wich distinguishes white and black and sends "0" or "1"pulses accordingly.
This model consists of two places and two transitions alongside two input and one output places.
11.4.1.1 Place LOOP_LEFT_SENSOR
Internal place of the resensing circuit.
11.4.1.2 Place START_SENSE_LEFT
A place that contains an initial token which represents the initial detection of the sensor. This Place
starts the detecting process.
properties
It has 1 starting tokens
118
11.4.1.3 Transition RESET_SENSE1
Provides a resensing circuit and resets SENSE2 to zero.
properties
It has Release Delay: initial value is 1 (relative)
action
XX->SENSE1=0.0;
11.4.1.4 Transition SET_SENSE1
The transition which conveys the initial token to the processor and also to the resensing loop net. It is
enabled also with the token received from power source.
properties
It has Release Delay: initial value is 1 (relative)
action
XX->SENSE1=xu_RndDouble();
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
12 Unit RIGHT_MOTOR
Artifex Class (Interface)
Includes one portset, four input places and one output place as Interface element.
12.1 Input Places
12.1.1 RIGHT_M_BACK (?)
An input place, symbolizing backward mode of DC motor.
12.1.2 RIGHT_M_FORE (?)
An input place, symbolizing forward mode of DC motor.
12.1.3 RIGHT_M_STOP (?)
119
An input place, symbolizing Stop mode of DC motor.
12.1.4 R_M_POW (?)
An input place, takes rol as power input.
12.2 Output Places
12.2.1 RESENSE_RIGHT (?)
An output place to let the token flow out the motor.
12.3 Portsets
12.3.1 RECEIVE_PROCESSOR
Includes three input places. Is used to connect the Processor to Right Motor through a linkset.
(Input ) RIGHT_M_FORE:?
(Input ) RIGHT_M_BACK:?
(Input ) RIGHT_M_STOP:?
(Input ) R_M_POW:?
(Output) RESENSE_RIGHT:?
13 Unit RIGHT_MOTOR
Artifex Class (Body)
A Petri Net which symbolise a DC motor which has three functions as forward, backward and stop
modes and also an power input pin. In addition it has a output place to let the token flow.
13.1 Object Hierarchy
13.2 Subnet Hierarchy
13.3 Subnet MAIN_SUBNET
Subnet priority: 3
Contains one page named DC_MOTOR_RIGHT.
120
13.3.1 Page DC_MOTOR_RIGHT
Symbolizes a DC motor. Consists of four input places one output place and three transitions.
13.3.1.1 Transition RMBC
A transition to symbolize backward mode of DC motor.
It lso inculdes some Actions to change the State and Color of the Object Right Motor in the Main
Page.
properties
It has Release Delay: initial value is 100 (relative)
action
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
13.3.1.2 Transition RMFC
A transition to symbolize forward mode of DC motor.
It lso inculdes some Actions to change the State and Color of the Object Right Motor in the Main
Page.
properties
It has Release Delay: initial value is 100 (relative)
action
121
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
13.3.1.3 Transition RMSC
A transition to symbolize stop mode of DC motor.
It lso inculdes some Actions to change the State and Color of the Object Right Motor in the Main
Page.
properties
It has Release Delay: initial value is 100 (relative)
action
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
14 Unit RIGHT_SENSOR
Artifex Class (Interface)
Includes two input and one output places.
14.1 Input Places
14.1.1 RESENSE_RIGHT (?)
An input place to receive and enable the resensing circuit.
14.1.2 R_S_POW (?)
Connects the Power Source to the Sensorsor. Sensor work depends on the token comes through this
input place from battery.
14.2 Output Places
14.2.1 SEND_COMMAND_RIGHT (?)
Connects the Sensor to the Processor.
14.3 Portsets
14.3.1 RECEIVE_PROCESSOR
122
(Input ) R_S_POW:?
(Output) SEND_COMMAND_RIGHT:?
(Input ) RESENSE_RIGHT:?
15 Unit RIGHT_SENSOR
Artifex Class (Body)
A Petri Net which symbolise a light sensor which has the ability of distinguishing white and black
colors.
15.1 Local Variables
Name Type Description
SENSE1 double A Double type Local Variable utilised in decision
making for the robot behaviour.
SENSE2 double A Double type Local Variable utilised in decision
making for the robot behaviour.
15.2 Object Hierarchy
15.3 Subnet Hierarchy
15.4 Subnet MAIN_SUBNET
Subnet priority: 5
Includes one page named RIGHT_SENSOR.
15.4.1 Page RIGHT_SENSOR
123
Symlolize a light sensor wich distinguishes white and black and sends "0" or "1"pulses accordingly.
This model consists of two places and two transitions alongside two input and one output places.
15.4.1.1 Place LOOP_RIGHT_SENSOR
Internal place of the resensing circuit.
15.4.1.2 Place START_SENSE_RIGHT
A place that contains an initial token which represents the initial detection of the sensor. This Place
starts the detecting process.
properties
It has 1 starting tokens
15.4.1.3 Transition RESET_SENSE2
Provides a resensing circuit and resets SENSE2 to zero.
properties
It has Release Delay: initial value is 1 (relative)
action
XX->SENSE2=0.0;
15.4.1.4 Transition SET_SENSE2
124
The transition which conveys the initial token to the processor and also to the resensing loop net. It is
enabled also with the token received from power source.
properties
It has Release Delay: initial value is 1 (relative)
action
XX->SENSE2=xu_RndDouble();
xx_setstate(xx_getstate()+1);
xx_setcolor(xx_getcolor()+1);
16 Measure Results
For this project three kinds of User Measures are defined. They are "left_turn_id", "right_turn_id"
and "straight_line_id". These User Measure instruments are designed to obtain the rate of the robot
movement on straight line to left and right.
Also a Place "POWER" in Power Unit is engaged to the measure tool which observes its behavior and
properties.
16.1 Superimposed Rate Chart
125
APPENDIX C
PROCESSOR CODES
1. Curve Following Robot
pause 2000 'Robot waits for 2 seconds before move
sensor: 'Check sensors
if pin2=0 and pin3=0 then ileri 'If the sensors are on white ground go straight.
if pin2=1 and pin3=0 then soladon 'If left sensor is on black ground and right sensor is on white ground then turn left.
if pin2=0 and pin3=1 then sagadon 'If left sensor is on white ground and right sensor is on black ground then turn right.
if pin2=1 and pin3=1 then dur 'If both sensors are on black ground then stop.
goto sensor 'Check sensors again.
ileri: 'To go satraight
forward a 'Turn motor a forward.
forward b 'Turn motor b forward.
pause 10 'Wait for 10 ms.
goto sensor 'Check sensors again.
soladon: To turn left
backward a 'Turn motor a backward.
forward b 'Turn motor b forward.
pause 10 'Wait for 10 ms.
126
goto sensor 'Check sensors again.
sagadon: To turn left
forward a 'Turn motor a forward.
backward b 'Turn motor b backward.
pause 10 'Wait for 10 ms.
goto sensor 'Check sensors again.
dur: 'To stop
halt a 'Stop motor a.
halt b 'Stop motor b.
pause 10 'Wait for 10 ms.
goto sensor 'Check sensors again.
end 'End of the program.
2. Pick Packing Automated Guided Vehicle
#include <Servo.h>
#include <IRremote.h>
127
// - - - IR kit - - -
int RECV_PIN=11; //kumanda
IRrecv irrecv(RECV_PIN);
decode_results results;
int cmnd=0;
// - - - Degrees - - -
int rwfor = 0; int rwbak = 180; int lwfor = 180; int lwbak = 0; int wstp = 94;
int grpopn = 100; int grpcls = 132;
int armup = 140; int armdwn = 100; int armvec = 33; int armset = 105; int armplt = 180;
// - - - Servos - - -
Servo rw; Servo lw; Servo arm1; Servo arm2; Servo grp;
//-------------------------------------------------------
void setup() {
Serial.begin(9600);
irrecv.enableIRIn();
rw.attach(5); lw.attach(6); arm1.attach(7); arm2.attach(8); grp.attach(9);
}
//------------------------------------------------------
128
void loop() {
cammand();
if (cmnd==0)
{OFF();}
if (cmnd==1)
{mission1();}
if (cmnd==2)
{mission2();}
if (cmnd==3)
{mission3();}
if (cmnd==4)
{test();}
}
// ********************************* Functions*************************************
// - - - Missions - - -
void OFF()
{rw.detach(); lw.detach(); arm1.write(armset); arm2.write(armdwn); grp.write(grpcls);}
void mission1()
{rw.attach(5); lw.attach(6);
//-----
STRAIGHT_A();
129
TURN_LEFT();
STRAIGHT_B();
TURN_RIGHT();
STRAIGHT_C();
STOP_VEC();
// station 1
Pick_Part_From_Platform_And_Put_On_Vehicle();
FULL_TURN();
STRAIGHT_C();
TURN_LEFT();
STRAIGHT_E();
TURN_LEFT();
STRAIGHT_C();
STOP_VEC();
// station 2
Pick_Part_From_Platform_And_Put_On_Vehicle();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
TURN_LEFT();
STRAIGHT_E();
TURN_LEFT();
STRAIGHT_C();
130
STOP_VEC();
// station 3
Pick_Part_From_Platform_And_Put_On_Vehicle();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
TURN_LEFT();
STRAIGHT_E();
TURN_LEFT();
STRAIGHT_C();
STOP_VEC();
// station 4
Pick_Part_From_Platform_And_Put_On_Vehicle();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
TURN_RIGHT();
STRAIGHT_B();
TURN_LEFT();
STRAIGHT_A();
FULL_TURN();
//-----
cmnd =0;
131
}
void mission2()
{rw.attach(5);lw.attach(6);
//-----
STRAIGHT_A();
TURN_LEFT();
STRAIGHT_B();
TURN_RIGHT();
STRAIGHT_C();
STOP_VEC();
// station 1
Pick_Part_From_Vehicle_And_Put_On_Platform();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
TURN_LEFT();
STRAIGHT_E();
TURN_LEFT();
STRAIGHT_C();
STOP_VEC();
// station 2
Pick_Part_From_Vehicle_And_Put_On_Platform();
132
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
TURN_LEFT();
STRAIGHT_E();
TURN_LEFT();
STRAIGHT_C();
STOP_VEC();
// station 3
Pick_Part_From_Vehicle_And_Put_On_Platform();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
TURN_LEFT();
STRAIGHT_E();
TURN_LEFT();
STRAIGHT_C();
STOP_VEC();
// station 4
Pick_Part_From_Vehicle_And_Put_On_Platform();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
133
TURN_RIGHT();
STRAIGHT_B();
TURN_LEFT();
STRAIGHT_A();
FULL_TURN();
//-----
cmnd =0;
}
void mission3()
{rw.attach(5);lw.attach(6);
//-----
STRAIGHT_A();
TURN_LEFT();
STRAIGHT_B();
TURN_RIGHT();
STRAIGHT_C();
STOP_VEC();
// station 1
Pick_Part_From_Platform_And_Put_On_Vehicle();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
134
TURN_LEFT();
STRAIGHT_E();
TURN_LEFT();
STRAIGHT_C();
STOP_VEC();
// station 2
Pick_Part_From_Vehicle_And_Put_On_Platform();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
TURN_LEFT();
STRAIGHT_E();
TURN_LEFT();
STRAIGHT_C();
STOP_VEC();
// station 3
Pick_Part_From_Platform_And_Put_On_Vehicle();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
TURN_LEFT();
STRAIGHT_E();
TURN_LEFT();
135
STRAIGHT_C();
STOP_VEC();
// station 4
Pick_Part_From_Vehicle_And_Put_On_Platform();
STOP_VEC();
FULL_TURN();
STRAIGHT_C();
TURN_RIGHT();
STRAIGHT_B();
TURN_LEFT();
STRAIGHT_A();
FULL_TURN();
//-----
cmnd =0;
}
void test ()
{rw.attach(5);lw.attach(6);
//-----
STRAIGHT_A();
STOP_VEC();
delay (3000);
136
STRAIGHT_B();
STOP_VEC();
delay (3000);
STRAIGHT_C();
STOP_VEC();
delay (3000);
STRAIGHT_D();
STOP_VEC();
delay (3000);
STRAIGHT_E();
STOP_VEC();
delay (3000);
TURN_LEFT();
STOP_VEC();
delay (3000);
TURN_RIGHT();
STOP_VEC();
137
delay (3000);
FULL_TURN();
STOP_VEC();
delay (3000);
Pick_Part_From_Platform_And_Put_On_Vehicle();
STOP_VEC();
delay (3000);
Pick_Part_From_Vehicle_And_Put_On_Platform();
STOP_VEC();
delay (3000);
//-----
cmnd =0;
}
// - - - Subfunctions - - -
//--> Wheels
void STRAIGHT_A ()
{rw.write(rwfor); lw.write(lwfor); delay (10900);}
void STRAIGHT_B ()
138
{rw.write(rwfor); lw.write(lwfor);delay (20050);}
void STRAIGHT_C ()
{rw.write(rwfor); lw.write(lwfor); delay (3050);}
void STRAIGHT_D ()
{rw.write(rwfor); lw.write(lwfor); delay (6700);}
void STRAIGHT_E ()
{rw.write(rwfor); lw.write(lwfor); delay (13350);}
void TURN_LEFT ()
{rw.write(rwfor); lw.write(lwbak); delay (1000);}
void TURN_RIGHT ()
{rw.write(rwbak); lw.write(lwfor); delay (1000);}
void FULL_TURN ()
{rw.write(rwfor); lw.write(lwbak); delay (2000);}
void STOP_VEC ()
{rw.write(wstp); lw.write(wstp); delay (1000);}
139
//--> Part Transfer
void Pick_Part_From_Vehicle_And_Put_On_Platform()
{
ARM_UP();
OPEN();
ARM_VEC();
ARM_DOWN();
GRIP();
ARM_UP();
ARM_PLATFORM();
ARM_DOWN();
OPEN();
ARM_UP();
GRIP();
ARM_SET();
ARM_DOWN();
}
void Pick_Part_From_Platform_And_Put_On_Vehicle()
{
ARM_UP();
OPEN();
ARM_PLATFORM();
140
ARM_DOWN();
GRIP();
ARM_UP();
ARM_VEC();
ARM_DOWN();
OPEN();
ARM_UP();
GRIP();
ARM_SET();
ARM_DOWN();
}
//--> Sub - Part Transfer
void ARM_UP ()
{arm2.write(armup); delay(750);}
void ARM_DOWN ()
{arm2.write(armdwn); delay(750);}
void ARM_VEC ()
{arm1.write(armvec); delay(750);}
void ARM_PLATFORM ()
141
{arm1.write(armplt); delay(750);}
void ARM_SET ()
{arm1.write(armset); delay (750);}
//--> Gripper
void GRIP ()
{grp.write(grpcls); delay (750);}
void OPEN ()
{grp.write(grpopn); delay (750);}
// - - - IR Function - - -
void cammand()
{
if(irrecv.decode(&results))
{
Serial.println(results.value, HEX);
irrecv.resume();
delay(100);
if (results.value==0xFD00FF)
{cmnd=0;}
142
if (results.value==0xFD08F7)
{cmnd=1;}
if (results.value==0xFD8877)
{cmnd=2;}
if (results.value==0xFD48B7)
{cmnd=3;}
if (results.value==0xFD28D7)
{cmnd=4;}
}
}
3. Frog Robot
#include <Servo.h>
// - - - CMUcam - - - -
Servo neck; char inByte,value;int counter; char received[40]; int point[2];
int i; int x,y; int angle=90; int adim = 5;
// - - - Servos - - - -
Servo Rforeleg; Servo Rhindlegupper; Servo Rhindleglower;
143
Servo Lforeleg; Servo Lhindlegupper; Servo Lhindleglower;
// - - - - - - - - - - -
int buttonvalue=0; int IRvalue; int LightSensorValue = 0; int SoundSensorValue = 0; int FSRvalue=0;int buzcount=0;
int button=7; int buzzer = 8; int IR = 9; int LED=A0; int light = A1; int sound = A2; int FSR= A3;
void setup()
{
// - - - CMUcam - - - -
neck.attach(11); Serial.begin(9600); neck.write(angle); initCam();
// - - - SERVOS - - -
Rforeleg.attach(2); Rhindlegupper.attach(4); Rhindleglower.attach(3);
Lforeleg.attach(10); Lhindlegupper.attach(12); Lhindleglower.attach(6);
pinMode(buzzer, OUTPUT); pinMode(IR, INPUT); pinMode(button, INPUT);
pinMode(LED, OUTPUT);
}
void loop()
{
buttonvalue = digitalRead(button); IRvalue = digitalRead(IR);
LightSensorValue = analogRead(light); SoundSensorValue = analogRead(sound); FSRvalue = analogRead(FSR);
Serial.print("LightSensorValue=");Serial.println(LightSensorValue);
Serial.print("SoundSensorValue=");Serial.println(SoundSensorValue);
Serial.print("FSRvalue=");Serial.println(FSRvalue);
144
if (buttonvalue == HIGH && IRvalue == HIGH && FSRvalue<100 && LightSensorValue < 500 && SoundSensorValue < 30)
{idle();}
if (buttonvalue == LOW && IRvalue == HIGH && FSRvalue<100 && LightSensorValue < 500 && SoundSensorValue < 30)
{hunt();}
if (buttonvalue == LOW && IRvalue == HIGH && FSRvalue>100 && LightSensorValue < 500 && SoundSensorValue < 30)
{jump();}
if (buttonvalue == HIGH && IRvalue == LOW && FSRvalue>100 && LightSensorValue < 500 && SoundSensorValue < 30)
{walk();}
if (buttonvalue == HIGH && IRvalue == HIGH && FSRvalue>100 && LightSensorValue > 500 && SoundSensorValue < 30)
{happy();}
if (buttonvalue == HIGH && IRvalue == HIGH && FSRvalue<100 && LightSensorValue > 500 && SoundSensorValue > 30)
{frightened();}
if (buttonvalue == HIGH && IRvalue == LOW && FSRvalue<100 && LightSensorValue > 500 && SoundSensorValue > 30)
{angry();}
}
// - - - Missions - - -
void idle()
{
Serial.println("IDLE MODE");
digitalWrite(buzzer, LOW); digitalWrite(LED, LOW);
Rhindlegupper.write(0); Rhindleglower.write(135);Rforeleg.write(45);
Lhindlegupper.write(0); Lhindleglower.write(135);Lforeleg.write(45);
neck.write(90);
145
delay (1000);
}
void jump()
{
Serial.println("JUMP MODE");
digitalWrite(LED, HIGH);
Rhindlegupper.write(135); Rhindleglower.write(170);Rforeleg.write(135);
Lhindlegupper.write(135); Lhindleglower.write(170);Lforeleg.write(135);
delay(1000);
Rhindlegupper.write(0); Rhindleglower.write(135);Rforeleg.write(45);
Lhindlegupper.write(0); Lhindleglower.write(135);Lforeleg.write(45);
digitalWrite(LED, LOW);
delay(2000);
}
void walk()
{
Serial.println("WALK MODE");
digitalWrite(LED, HIGH);
Lhindlegupper.write(0);Lhindleglower.write(135);Lforeleg.write(90);
Rhindlegupper.write(45);Rhindleglower.write(90);Rforeleg.write(45);
delay(1000);
Lhindlegupper.write(45);Lhindleglower.write(90);Lforeleg.write(45);
Rhindlegupper.write(0);Rhindleglower.write(135);Rforeleg.write(90);
146
digitalWrite(LED, HIGH);
delay(1000);
}
void frightened()
{
Serial.println("FRIGHTENED MODE");
digitalWrite(buzzer, HIGH); digitalWrite(LED, HIGH);
delay (400);
digitalWrite(buzzer, LOW); digitalWrite(LED, LOW);
Lhindlegupper.write(45);Lhindleglower.write(45);Lforeleg.write(0);
Rhindlegupper.write(45);Rhindleglower.write(45);Rforeleg.write(0);
delay(1000);
Rhindlegupper.write(0); Rhindleglower.write(135);Rforeleg.write(45);
Lhindlegupper.write(0); Lhindleglower.write(135);Lforeleg.write(45);
digitalWrite(buzzer, HIGH); digitalWrite(LED, HIGH);
delay (400);
digitalWrite(buzzer, LOW); digitalWrite(LED, LOW);
delay (1500);
}
void angry()
{
Serial.println("ANGRY MODE");
147
digitalWrite(buzzer, HIGH); digitalWrite(LED, HIGH);
neck.write(45); delay (500); neck.write(135); delay (500); neck.write(45);delay (500); neck.write(135); delay (500);
neck.write(90);
Lhindlegupper.write(90);Lhindleglower.write(0);Lforeleg.write(45);
Rhindlegupper.write(90);Rhindleglower.write(0);Rforeleg.write(45);
delay(1000);
Rhindlegupper.write(0); Rhindleglower.write(135);Rforeleg.write(45);
Lhindlegupper.write(0); Lhindleglower.write(135);Lforeleg.write(45);
digitalWrite(buzzer, LOW); digitalWrite(LED, LOW);
delay(2500);
}
void happy()
{
Serial.println("HAPPY MODE");
neck.write(45);delay (500); neck.write(135); delay (500); neck.write(90);
while (buzcount < 10)
{
digitalWrite(buzzer, HIGH); digitalWrite(LED, HIGH);
delay (15);
digitalWrite(buzzer, LOW); digitalWrite(LED, LOW);
delay (15);
buzcount++;
148
}
buzcount=0;
Lhindlegupper.write(90);Lhindleglower.write(0);Rhindlegupper.write(90);Rhindleglower.write(0);
Lforeleg.write(0);Rforeleg.write(30); delay (500); Lforeleg.write(30);Rforeleg.write(0); delay (500);
Lforeleg.write(0);Rforeleg.write(30); delay (500); Lforeleg.write(30);Rforeleg.write(0); delay (500);
Lforeleg.write(0);Rforeleg.write(30); delay (500); Lforeleg.write(30);Rforeleg.write(0); delay (500);
Rhindlegupper.write(0); Rhindleglower.write(135);Rforeleg.write(45);
Lhindlegupper.write(0); Lhindleglower.write(135);Lforeleg.write(45);
while (buzcount < 10)
{
digitalWrite(buzzer, HIGH); digitalWrite(LED, HIGH);
delay (15);
digitalWrite(buzzer, LOW); digitalWrite(LED, LOW);
delay (15);
buzcount++;
}
buzcount=0;delay (2000);
}
void hunt()
{
149
Serial.println("HUNT MODE");
track_delay(10);
while (buzcount < 3)
{
digitalWrite(buzzer, HIGH); digitalWrite(LED, HIGH);
delay (45);
digitalWrite(buzzer, LOW); digitalWrite(LED, LOW);
delay (45);
buzcount++;
}
buzcount=0;
track_delay(10);
}
void track_delay(int hmilisecond)
{
int i;
for (i=0;i<hmilisecond;i++)
{
delay(100); trackColor(); x = point[0]; y = point[1];
if (x>0 && y>0)
{
trackCamera();
150
break;
}
}
}
void initCam()
{
delay(2000); delay(500);
Serial.write("TC 200 255 0 30 0 30\r");
}
void trackCamera()
{
int count_zero=0;
while (1)
{
trackColor(); x = point[0]; y = point[1];
if (x>0)
{
if (x>40) angle += adim;
else if (x<40) angle -= adim;
if (angle > 180) angle = 180;
151
else if (angle < 0) angle = 0;
neck.write(angle); count_zero = 0;
}
else count_zero++;
if (count_zero > 10)
break;
}
}
void trackColor()
{
counter=0; inByte = ':';
while(inByte !='M')
{
if (Serial.available() > 0)
{
inByte = Serial.read(); received[counter] = inByte; counter++;
}
}
char *p = received; char *str; counter = 0;
while((str = strtok_r(p," ",&p)) != NULL)
{
point[counter] = atoi(str); counter++;
152
if (counter>1)
break;
}
}