Iss8/feature definition Closes #8, #9, #10, and #11 See merge request horlingsw/mahd!3master
| @@ -1,2 +1,5 @@ | |||||
| specifications/system/document.pdf | specifications/system/document.pdf | ||||
| specifications/system/preamble.tex | specifications/system/preamble.tex | ||||
| features/feature_definition.pdf | |||||
| features/graphics/*.pdf | |||||
| *.rro | |||||
| @@ -3,6 +3,10 @@ | |||||
| stages: | stages: | ||||
| - typeset | - typeset | ||||
| variables: | |||||
| GIT_SUBMODULE_STRATEGY: recursive | |||||
| design_specifications: | design_specifications: | ||||
| stage: typeset | stage: typeset | ||||
| image: registry.gitlab.com/silkeh/latex:latest | image: registry.gitlab.com/silkeh/latex:latest | ||||
| @@ -41,3 +45,22 @@ initial_design: | |||||
| - tags | - tags | ||||
| changes: | changes: | ||||
| - initial_design/* | - 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/* | |||||
| @@ -0,0 +1,3 @@ | |||||
| [submodule "features/common"] | |||||
| path = features/common | |||||
| url = ../mac.git | |||||
| @@ -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) | |||||
| @@ -0,0 +1 @@ | |||||
| Subproject commit 9824d626fd1bf2cdc4d03c4109500629ffe16a20 | |||||
| @@ -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} | |||||
| @@ -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. | |||||
| @@ -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. | |||||
| @@ -0,0 +1,2 @@ | |||||
| \chapter{Specifications} | |||||
| This chapter will specify each feature more precisely | |||||
| @@ -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} | |||||
| @@ -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} | |||||
| @@ -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} | |||||
| @@ -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} | |||||