Переглянути джерело

Merge branch 'iss8/feature_definition' into 'master'

Iss8/feature definition

Closes #8, #9, #10, and #11

See merge request horlingsw/mahd!3
master
Wouter Horlings 5 роки тому
джерело
коміт
7b100c3765
15 змінених файлів з 400 додано та 0 видалено
  1. +3
    -0
      .gitignore
  2. +23
    -0
      .gitlab-ci.yml
  3. +3
    -0
      .gitmodules
  4. +38
    -0
      features/Makefile
  5. +1
    -0
      features/common
  6. BIN
      features/content/Feature_separation.ods
  7. +24
    -0
      features/content/definition.tex
  8. +108
    -0
      features/content/introduction.tex
  9. +91
    -0
      features/content/separation.tex
  10. +2
    -0
      features/content/specification.tex
  11. +29
    -0
      features/feature_definition.tex
  12. +24
    -0
      features/graphics/char.tex
  13. +16
    -0
      features/graphics/reach.tex
  14. +38
    -0
      features/graphics/robmosys.tex
  15. BIN
      features/robmosys.dia

+ 3
- 0
.gitignore Переглянути файл

@@ -1,2 +1,5 @@
specifications/system/document.pdf
specifications/system/preamble.tex
features/feature_definition.pdf
features/graphics/*.pdf
*.rro

+ 23
- 0
.gitlab-ci.yml Переглянути файл

@@ -3,6 +3,10 @@
stages:
- typeset

variables:
GIT_SUBMODULE_STRATEGY: recursive


design_specifications:
stage: typeset
image: registry.gitlab.com/silkeh/latex:latest
@@ -41,3 +45,22 @@ initial_design:
- tags
changes:
- initial_design/*

feature_definition:
stage: typeset
image: registry.gitlab.com/silkeh/latex:latest
script:
- apk update; apk add make
- cd features/
- make
- mv feature_definition.pdf ../feature_definition.pdf
artifacts:
paths:
- feature_definition.pdf
only:
refs:
- web
- branches
- tags
changes:
- features/*

+ 3
- 0
.gitmodules Переглянути файл

@@ -0,0 +1,3 @@
[submodule "features/common"]
path = features/common
url = ../mac.git

+ 38
- 0
features/Makefile Переглянути файл

@@ -0,0 +1,38 @@
SOURCE ?= feature_definition.tex
TARGET ?= $(subst .tex,.pdf,$(SOURCE))
GRPH_DIR ?= graphics
GRPH_SOURCE ?= $(wildcard $(GRPH_DIR)/*.tex)
GRPH_TARGET ?= $(subst .tex,.pdf,$(GRPH_SOURCE))

JOBNAME = $(subst .pdf,,$(TARGET))

# build configuration

LATEXMK ?= latexmk
# for pdflatex: LATEXMK_TARGET = -pdf
# for latex -> dvi -> pdf: LATEXMK_TARGET = -pdfdvi
LATEXMK_TARGET += -xelatex
LATEXMK_OPTS += -recorder -use-make -latexoption="-interaction=nonstopmode -synctex=1"
LATEXMK_ARTIFACTS += *.bbl
LATEXMK_ARTIFACTS += *.synctex.gz
LATEXMK_ARTIFACTS += *-converted-to.pdf
LATEXMK_ARTIFACTS += *.synctex.gz\(busy\)
LATEXMK_ARTIFACTS += *.rro
LATEXMK_ARTIFACTS += *.aux
LATEXMK_ARTIFACTS += *.run.xml

$(TARGET): $(SOURCE) $(GRPH_TARGET)
$(LATEXMK) $(LATEXMK_OPTS) $(LATEXMK_TARGET) $<

$(GRPH_DIR)/%.pdf: $(GRPH_DIR)/%.tex
$(LATEXMK) -lualatex -outdir=$(GRPH_DIR) $(LATEXMK_OPTS) $<

.PHONY: clean Clean
clean:
$(LATEXMK) $(SOURCE) -c

Clean:
$(LATEXMK) $(SOURCE) -C
$(LATEXMK) -outdir=$(GRPH_DIR) $(GRPH_SOURCE) -C
rm -f $(LATEXMK_ARTIFACTS)


+ 1
- 0
features/common

@@ -0,0 +1 @@
Subproject commit 9824d626fd1bf2cdc4d03c4109500629ffe16a20

BIN
features/content/Feature_separation.ods Переглянути файл


+ 24
- 0
features/content/definition.tex Переглянути файл

@@ -0,0 +1,24 @@
\chapter{Definition}


In the initial design step we decided on combining two motion systems.
One is the suspended cable system, this can easily cover the large board.
However it lacks precision and this is where a small SCARA comes in to action.
This arm provides speed and accuracy.
And if the next bit of whiteboard is out of reach, the cable bot will move the arm to a new position.

These two features are easy to define.
Thus we have the SCARA and the cable system.
So at this point we would just attach a marker to the arm and write on the board.
However, now we cannot wipe text of the board.
So another feature would be some toolchanger that can switch to the wiper.
And, offcourse, later back to the marker, posibly with a different color.


This brings us to the following features:
\begin{itemize}
\item SCARA
\item Cable system
\item Toolchange
\item Wiper
\end{itemize}

+ 108
- 0
features/content/introduction.tex Переглянути файл

@@ -0,0 +1,108 @@
\chapter{Introduction}
This document will describe the feature and test specification step.
The original plan was to specify features and give these features there own specifications.
Together these feature specifications have to ensure that the system specifications are met.
And eventually for each feature a set of tests is designed so that the feature specifications can be monitored.

However, during this step it became clear that this method was not feasible in the limited amount of time.
Spending more time on this step would not result in a better test of the method.
It might even have a negative effect as other steps would be overshadowed by this step.
Eventhough the step has not been finished we still managed to learn some valuable lessons.

One of the lessons was to use RobMoSys for the feature specifications.
This will be explained in \autoref{chap:robmosys}.
The feature specifications were very difficult as it turned out that a lot of this depended on the level of detail in the system specifications.
We will explain this part in \autoref{chap:specifications}.

\chapter{RobMoSys}
\label{chap:robmosys}
The original method was to just look at the features of the system and describe them.
This turned out to be impossible as there are a lot of features at different levels with different dependencies.
For example \textcite{broenink_variable_2018} defines three features on his segway.
However, the hardware already exist.
Therefore, features like wheels, motors, sensors, powerpack, etc. do not have to be considered.
We underestimated the amount of features if you do not have pre-existing hardware.
A problem was that, for example, a motor did not fit in our original idea of feature.
However, taking a high-level feature defeated the purpose of this method with multiple steps of implementation.
As this high-level feature would then include motors, control, sensors etc.

Eventually we used RobMoSys to separate the features in a way that made sense.
We started with a mission, which is in this case the 'tweet on a whiteboard' and broke it up in to tasks.
So what tasks are required to fulfill the mission.
These tasks required certain skills, which required then functions.
\autoref{fig:robmosys} shows the resulting graph of the separation into different levels.
The figure also shows our fifth layer as subsystem.
A full Robmosys would even separate this in to 4 additional layers but we decided on keeping it simpler.
The simplification was done as this was mainly in middle- and software which was not the focus of this thesis.
Furthermore, because we did not see any additional value but it would cost a lot of extra time.

\begin{figure*}
\centering
\includegraphics[width=0.8\paperwidth]{graphics/robmosys.pdf}
\caption{Separation of the mission into tasks, skills, functions and subsystems based on a simplification of RobMoSys.}
\label{fig:robmosys}
\end{figure*}

In the end the graph gives us a lot of sub-features.
We will not implement every single node as a feature because 15 small features would only create loads of overhead.
But what we can do is group sub-features.
This also brings another advantage because we include a higher-level feature that can be used as test.
For example, the SCARA can be tested by successfully moving the marker on the board.

In the later step where we will select one of the features we will use this graph as a basis.
We can group features from this graph such that they can be implemented in about a week.
This way we reduce the overhead of implementation and keep an eye on the progress.

\chapter{Specifications}
\label{chap:specifications}
The following step was to distribute the system specifications between the features.
The problem we ran in to is that neither the system specification nor the RobMoSys was implemented with enough detail that they could work together.
Parts of the specifications lacked in detail, even with the use the EARS-method \autocite{mavin_easy_2009}.
This resulted that some specification where valid for all sub-features as the specifications where to broad.
However, improving the specifications would sometimes result in that it did not fit on one of the sub-features.
This is because the RobMoSys misses sub-features which would specifically implement the control system.

While we were working on this step we updated the system specifications.
This was done because we found that some of the specification did not make any sense in for this research.
While others were really easy to expand.
Therefore, these following list represents the updated specifications:
\begin{itemize}
\item The Writer shall be able to write at least 50 characters per line.
\item The Writer shall be able to write at least 5 lines of text.
\item The Writer shall plot characters with a size that is readable from 4 meters for a person with good eyesight.
\item The Writer shall plot in a regular used font with corresponding character spacing.
\item When a new tweet is send to the Writer, the Writer, shall wipe the existing tweet and write down a new tweet.
\item If the Writer is not wiping or writing then the Writer shall not obstruct the view of the whiteboard.
\item While writing, the Writer shall have a writing speed of at least 1 character per second.
\item If the Writer is tasked to wipe the tweet, the Writer shall wipe the tweet within 60 seconds
\item When a reset-signal is send to the Writer, the Writer shall re-calibrate its position on the board.
\item When a wipe-signal is send to the Writer, the Writer shall wipe the board clean.
\item The Writer shall not damage itself.
\item While writing, the SCARA shall have a writing speed of at least 1.5 characters per second.
\item When the Carriage/base of the SCARA is at a static position, the SCARA shall be able to write at least 3 characters at that position.
\item When the SCARA finished writing at their current position, the Carriage shall move the SCARA to it's next position where it can write the subsequent characters.
\item When the SCARA has to be moved to a new position, the Carriage shall perform this movement within 1 second.
\end{itemize}

\chapter{Decision}
In the end we decided that a it was better to stop the current step.
We have some specific points that require improvement in a follow up.
The steps system specifications, initial design, feature separation and feature specifications have to be merged in to a kind of spiral model.
Where the process would start with a global description of the system and some initial designs.
This initial design can then be expanded with some course system specifications.
This would be followed by a RobMoSys-type of analysis.
The RobMoSys gives a brief interpretation of the different subsystems required.
For each subsystems we have to assign specifications, if it seems that this is difficult we can choose to review the specifications.
We can add more detail to the specifications for example, or split them in to multiple separate specifications.

For now, we have enough information to test the next steps.
At the beginning of each feature-implementation we will write the test specifications.
And during the selection we have to keep the list of specifications in mind.
We think that this is possible as the list of specifications and the set of systems is manageable.








+ 91
- 0
features/content/separation.tex Переглянути файл

@@ -0,0 +1,91 @@
\chapter{Separation of Concerns}
\label{chap:separation}
We have an initial design and in this step we will define features and subsystems.
To structure this process we will use a tiny bit of the RobMoSys approach.
With that we will define the mission, tasks, skills, functions and subsystems.
The subsystem combines some layers of RobMoSys as they are to specific for the scope of this thesis.

\section{RobMoSys}
The mission is clear and has already been stated before.
The system shall be able to write a tweet on a whiteboard.
\autoref{fig:robmosys} shows how the mission organized.
This separation is not created to be the most optimal as it is based on our initial design.
The three skills of move marker, move wiper and move carriage are redundant as they all have movement in the same plane.
One could say that this overcomplicates the design.
However, we chose for some complexity in the design, which creates dependency between subsystems, such that the design method can be tested.

\begin{figure*}
\centering
\includegraphics[width=0.8\paperwidth]{graphics/robmosys.pdf}
\caption{Separation of the mission into tasks, skills, functions and subsystems based on a simplification of RobMoSys.}
\label{fig:robmosys}
\end{figure*}

RobMoSys creates a top-down approach which results in the different subsystems.
The design method specifies that we want to implement feature by feature.
From \autoref{fig:robmosys} we can conclude that each step in the graph represents a sub-feature.
It might be a piece of hardware, control law or interface, they can all be classified as features of some sort.
Furthermore, it automatically generates the dependency tree as well.
As we cannot write a character somewhere on the board if we cannot move the marker.

\section{Feature Definition and Dependencies}
In the previous section we discussed that we have loads of sub-features.
We could implement all these features one by one.
But as some of them have single dependencies they could be combined.
The function 'Move wiper on board' is directly linked to the skill 'Wipe area' and could easily combined.
Especially as the skill is a direct test case for the function and as test cases are already required this is a valid optimization.

\section{Feature specifications}
The specifications that are listed in the system specifications document have to be distributed among the features.
We have grouped some specifications as they influence the same feature-group.

\subsection{Reach}
The first grouping is for the reach of the robot.
From the specifications document we find three specifications which influence the possible position of the carriage:
\begin{itemize}
\item The Writer shall be able to write at least 50 characters per line.
\item The Writer shall be able to write at least 5 lines of text.
\item If the Writer is not wiping or writing then the Writer shall not obstruct the view of the whiteboard.
\end{itemize}
The first two specify the minimum reach of the carriage.
The third specifies that the carriage has to move out of the way.

\autoref{fig:reach} shows the sub-features that cover the behavior of the carriage.
We have to take these three into account when we will develop these sub-features.

\begin{marginfigure}
\includegraphics[width=0.8\linewidth]{graphics/reach.pdf}
\caption{Sub-features that are responsible for reach related specifications}
\label{fig:reach}
\end{marginfigure}

\subsection{Character Writing}
The sub-systems shown in \autoref{fig:char} are responsible for getting the characters on the board.
The character writing specifications are given as:
\begin{itemize}
\item The Writer shall plot characters with a size that is readable from 4 meters for a person with good eyesight.
\item The Writer shall plot in a regular used font with corresponding character spacing.
\item While writing, the Writer shall have a writing speed of at least 1 character per second.
\end{itemize}
The later one covers the writing speed.
The speed does not only depend on the time required for a single char.
It also depends on moving to the position of the next character.
This is overlaps with the grouping for the reach specification as described in the previous subsection and can be seen in \autoref{fig:reach}
So we will split this into the following sub-specifications:
\begin{itemize}
\item While writing, the SCARA shall have a writing speed of at least 1.5 characters per second.
\item When the Carriage/base of the SCARA is at a static position, the SCARA shall be able to write at least 3 characters at that position.
\item When the SCARA finished writing at their current position, the Carriage shall move the SCARA to it's next position where it can write the subsequent characters.
\item When the SCARA has to be moved to a new position, the Carriage shall perform this movement within 1 second.
\end{itemize}

\begin{marginfigure}
\includegraphics[width=0.8\linewidth]{graphics/char.pdf}
\caption{Sub-features that are responisible for character writing specifications}
\label{fig:char}
\end{marginfigure}

\subsection{Tooling}
For the system to be able to switch from writing to wiping, there must be some toolchanging.
The general idea is that the end-effector can hold a tool and for a marker it shall be able to press it on the board.


+ 2
- 0
features/content/specification.tex Переглянути файл

@@ -0,0 +1,2 @@
\chapter{Specifications}
This chapter will specify each feature more precisely

+ 29
- 0
features/feature_definition.tex Переглянути файл

@@ -0,0 +1,29 @@
\documentclass[final,english,titlepage,nomath]{siltex-report}
\include{common/texfiles/preamble}

\title{Feature Definition}
%\subtitle{Thesis Proposal}
\course{}
\faculty{\large Electrical Engineering, Mathematics and Computer Science}
%\supervisor{%
% Dr. ir. J.F. Broenink \\
% Ir. T.G. Broenink
%}
\author{%
Wouter Horlings
}

\begin{document}
\maketitle
\makerro

\tableofcontents

\include{common/texfiles/acronyms}

\include{introduction}
%\include{separation}
%\include{definition}

\printbibliography
\end{document}

+ 24
- 0
features/graphics/char.tex Переглянути файл

@@ -0,0 +1,24 @@
\documentclass{standalone}
\usepackage{tikz}
\usetikzlibrary {arrows.meta,graphs,graphdrawing} \usegdlibrary {layered}

\begin{document}

\begin{tikzpicture}[nodes={text height=.7em, text width=1.8cm, align=center,
draw=black!20, thick, fill=white, font=\footnotesize},
>={Stealth[round,sep]}, rounded corners, semithick]

\graph [layered layout, level distance=1.5cm, sibling sep=.5em, sibling distance=1.5cm, sweep crossing minimization] {

"Write a char at position" -> { "Move marker on board", "Lift Marker" };
{"Lift Marker", "Move marker on board"} -> "SCARA";
};

% \graph [layered layout] {
% 1 -> 2 -> 3 -> 4;
% };



\end{tikzpicture}
\end{document}

+ 16
- 0
features/graphics/reach.tex Переглянути файл

@@ -0,0 +1,16 @@
\documentclass{standalone}
\usepackage{tikz}
\usetikzlibrary {arrows.meta,graphs,graphdrawing} \usegdlibrary {layered}

\begin{document}

\begin{tikzpicture}[nodes={text height=.7em, text width=2.5cm, align=center,
draw=black!20, thick, fill=white, font=\footnotesize},
>={Stealth[round,sep]}, rounded corners, semithick]

\graph [layered layout, level distance=1.5cm, sibling sep=.5em, sibling distance=1.5cm, sweep crossing minimization] {
"Move to position" -> "Move carriage" -> "Carriage";
};

\end{tikzpicture}
\end{document}

+ 38
- 0
features/graphics/robmosys.tex Переглянути файл

@@ -0,0 +1,38 @@
\documentclass{standalone}
\usepackage{tikz}
\usetikzlibrary {arrows.meta,graphs,graphdrawing} \usegdlibrary {layered}

\begin{document}

\begin{tikzpicture}[nodes={text height=.7em, text width=1.8cm, align=center,
draw=black!20, thick, fill=white, font=\footnotesize},
>={Stealth[round,sep]}, rounded corners, semithick]

\graph [layered layout, level distance=1.5cm, sibling sep=.5em, sibling distance=1.5cm, sweep crossing minimization] {
"Mission" -> "Task" -> "Skill" -> "Function" -> "Subsystem";

"Draw a tweet on a board" -> "Writing";
"Writing" -> { "Write a char at position", "Hold Marker", "Move to position" };
"Write a char at position" -> { "Move marker on board", "Lift Marker" };
"Hold Marker" -> "Switch Tools";
"Move marker on board" -> "SCARA";
"Lift Marker" -> "End-effector";

"Draw a tweet on a board" -> "Wiping";
"Wiping" -> { "Wipe Area", "Hold Wiper", "Move to position" };
"Hold Wiper" -> "Switch Tools";
"Move Wiper on Board" -> SCARA;
"Wipe Area" -> "Move Wiper on Board";

"Move to position" -> "Move carriage" -> "Carriage";
"Switch Tools" -> {"End-effector", "SCARA"};
};

% \graph [layered layout] {
% 1 -> 2 -> 3 -> 4;
% };



\end{tikzpicture}
\end{document}

BIN
features/robmosys.dia Переглянути файл


Завантаження…
Відмінити
Зберегти