Joystick for Marine Maneuvering Master’s thesis in Product Development HANNAH-MARIA ELFVING HANNES WINBLAD Department of Industrial and Materials Science CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2020 Master’s thesis 2020 Joystick for marine maneuvering HANNAH-MARIA ELFVING HANNES WINBLAD DF Department of Industrial and Materials Science Division of Product Development Chalmers University of Technology Gothenburg, Sweden 2020 Joystick for marine maneuvering HANNAH-MARIA ELFVING HANNES WINBLAD © HANNAH-MARIA ELFVING & HANNES WINBLAD, 2020. Supervisor: Lars Almefelt, Department of Industrial and Materials Science, Chalmers University of Technology Sofia Ekman, CPAC Systems David Nydahl, CPAC Systems Examiner: Lars Almefelt, Department of Industrial and Materials Science, Chalmers University of Technology Master’s Thesis 2020 Department of Industrial and Materials Science Division of Product Development Chalmers University of Technology SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: The test bench that was developed during the project. Typeset in LATEX, template by David Frisk Printed by Chalmers Reproservice Gothenburg, Sweden 2020 iv Joystick for marine maneuvering HANNAH-MARIA ELFVING HANNES WINBLAD Department of Industrial and Materials Science Chalmers University of Technology Abstract A big part of our modern lives evolves around interpreting feedback sent to us from different devices. Is your phone vibrating and the screen flashing? Odds are someone is trying to call you. Is the light on your stove turned on? Odds are it is activated and hot. To minimize the risk of misunderstandings and accidents, this feedback needs to be clear and self-evident. One way to ensure this, is to develop a product based on user experience. This ensures that the user understands the product, and use it in the way the developer intended. This project aimed to develop a joystick test bench that could test different kinds of feedback and activation methods. The test bench consisted of both a physical joystick prototype which the user could interact with, as well as a simulator which the physical prototype could be tested on. User studies were performed on the pro- totype. The results from the user studies point towards that users would like more feedback on function activation than just visual. The test bench itself can be further developed and used in future studies. Keywords: joystick, user experience , test bench, simulator, feedback, activation methods, user studies v Acknowledgements This report comprises a Master’s Thesis in Product Development at the depart- ment of Industrial and Material Science carried out from January until June 2020 at Chalmers University of Technology. We would like to give a warm thank you to our supervisor Lars Almefelt for his inspiration, motivation and engagement during this project. We would also like to thank Sofia Ekman & David Nydahl, our company supervisors from CPAC Systems for their insight, guidance and expertise that greatly assisted the research. This thesis demanded a big amount of work, dedication and commitment. Still, it could not have been done without the support of several people. Therefore we would like to also direct our sincere gratitude to everyone who has contributed to making this project a success. Hannah-Maria Elfving & Hannes Winblad, Gothenburg, June 2020 vii Contents 1 Introduction 1 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Scope & delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.5 Question formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6 Reading guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Theoretical frame of reference 5 2.1 What user experience is . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Why user experience is important . . . . . . . . . . . . . . . . 5 2.1.2 Implementation of human-centred design . . . . . . . . . . . . 6 2.1.3 The interactive system . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Theory of user studies & data collection . . . . . . . . . . . . . . . . 6 2.2.1 Usability test . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Exploratory & confirmatory user studies . . . . . . . . . . . . 7 2.2.3 The structure of the user study . . . . . . . . . . . . . . . . . 7 2.2.4 Question-based & observation-based studies . . . . . . . . . . 7 2.2.4.1 Question-based studies . . . . . . . . . . . . . . . . . 7 2.2.4.2 Observation-based studies . . . . . . . . . . . . . . . 7 2.2.5 Participator demographics in qualitative studies . . . . . . . . 8 2.3 Product development theory . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1 Theory about the Kesselring matrix . . . . . . . . . . . . . . . 8 2.3.2 Node-based workflows & processes . . . . . . . . . . . . . . . 8 2.3.3 Theory on prototyping . . . . . . . . . . . . . . . . . . . . . . 9 2.3.4 Design-build-test cycle . . . . . . . . . . . . . . . . . . . . . . 9 2.3.5 Modular design theory . . . . . . . . . . . . . . . . . . . . . . 10 2.3.6 Design for assembly theory . . . . . . . . . . . . . . . . . . . . 10 2.3.7 Theory of Additive manufacturing . . . . . . . . . . . . . . . . 11 2.4 Theory of technical components . . . . . . . . . . . . . . . . . . . . . 11 2.4.1 Micro controllers . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.1.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.1.2 Seeeduino . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.2 Theory about CAN data . . . . . . . . . . . . . . . . . . . . . 12 2.5 The current design of the product . . . . . . . . . . . . . . . . . . . . 12 2.6 Market analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 ix Contents 2.6.1 Competing products . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.1.1 Seastar Optimus 360 . . . . . . . . . . . . . . . . . . 14 2.6.1.2 Mercury marines Axius . . . . . . . . . . . . . . . . 14 2.6.1.3 Xenta joystick . . . . . . . . . . . . . . . . . . . . . 15 2.6.1.4 JCS by Yacht control systems . . . . . . . . . . . . . 15 2.6.1.5 Joystick maneuvering system (JMS) by ZF . . . . . . 16 2.6.1.6 Yanmar JC10/20 . . . . . . . . . . . . . . . . . . . . 16 2.6.1.7 Cummins joystick . . . . . . . . . . . . . . . . . . . . 17 2.6.2 Similar products with other use areas . . . . . . . . . . . . . . 17 2.6.2.1 Control stick JAS Gripen . . . . . . . . . . . . . . . 18 2.6.2.2 Media control unit in cars . . . . . . . . . . . . . . . 18 2.6.2.3 Construction equipment control stick . . . . . . . . . 19 2.6.2.4 Game Controller . . . . . . . . . . . . . . . . . . . . 20 3 Methodology 21 3.1 Product development process overview . . . . . . . . . . . . . . . . . 21 3.2 The process of understanding the product . . . . . . . . . . . . . . . 22 3.3 The process of defining areas of improvement . . . . . . . . . . . . . . 22 3.4 Defining the means . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4.1 Visual feedback to the user . . . . . . . . . . . . . . . . . . . . 23 3.4.1.1 Hypotheses on the strengths and limitations of LED’s 23 3.4.1.2 Hypotheses on the strengths and limitations of touch- screens . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.2 Auditive feedback to the user . . . . . . . . . . . . . . . . . . 24 3.4.2.1 Hypotheses on the strengths and limitations of speak- ers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.3 Haptic feedback to the user . . . . . . . . . . . . . . . . . . . 24 3.4.3.1 Hypotheses on the strengths and limitations of vi- bration motors . . . . . . . . . . . . . . . . . . . . . 24 3.4.3.2 Hypotheses on the strengths and limitations of a joy- stick with haptic force feedback . . . . . . . . . . . . 25 3.4.4 Haptic communication from the user to the joystick . . . . . . 25 3.4.4.1 Hypotheses on the strengths and limitations of tac- tile buttons . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.4.2 Hypotheses on the strengths and limitations of IR/- capacitance sensor . . . . . . . . . . . . . . . . . . . 25 3.4.5 Auditive and haptic communication from user to the joystick . 25 3.4.5.1 Hypotheses on the strengths and limitations of voice and visual command . . . . . . . . . . . . . . . . . . 26 3.4.6 Conclusion on defining the means . . . . . . . . . . . . . . . . 26 3.5 Understanding the product in use and defining the different user sce- narios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.5.1 User scenario 1 - Low speed in crammed spaces . . . . . . . . 27 3.5.2 User scenario 2 - Freedom for the developers . . . . . . . . . . 27 3.5.3 User scenario 3 - High speed driving, with a lot of function activation/deactivation . . . . . . . . . . . . . . . . . . . . . . 27 x Contents 3.6 Test bench methodology . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6.1 Test bench overview . . . . . . . . . . . . . . . . . . . . . . . 28 3.6.2 Test bench development workflow . . . . . . . . . . . . . . . . 28 3.6.3 Test bench - The making of the communication with the elec- trical components . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6.3.1 Test bench - Electrical components overview . . . . . 29 3.6.3.2 User-input . . . . . . . . . . . . . . . . . . . . . . . . 31 3.6.3.3 User-input communication . . . . . . . . . . . . . . . 33 3.6.3.4 Visual feedback - LED’s . . . . . . . . . . . . . . . . 34 3.6.3.5 Visual feedback - touchscreen . . . . . . . . . . . . . 35 3.6.3.6 Auditive feedback - Speakers . . . . . . . . . . . . . 35 3.6.3.7 Haptic feedback - Vibration motor . . . . . . . . . . 36 3.6.4 Test bench - Creating the mechanical design . . . . . . . . . . 37 3.6.4.1 Creating the overall design . . . . . . . . . . . . . . . 38 3.6.4.2 Making the test bench modular . . . . . . . . . . . . 40 3.6.4.3 Deciding where to place the electrical components . . 43 3.6.4.4 Designing the test bench with assembly in mind . . . 45 3.6.4.5 Designing the test bench with usability in mind . . . 46 3.6.4.6 Designing the test bench with manufacturing in mind 47 3.6.4.7 Conclusion of the mechanical design . . . . . . . . . 48 3.6.5 Developing the simulator . . . . . . . . . . . . . . . . . . . . . 49 3.6.5.1 Simulator overview . . . . . . . . . . . . . . . . . . . 49 3.6.5.2 Simulator functionality . . . . . . . . . . . . . . . . . 49 3.6.5.3 User-input processing in Unity . . . . . . . . . . . . 50 3.6.5.4 Joystick data processing in Unity . . . . . . . . . . . 51 3.6.5.5 Simulation of boat movement . . . . . . . . . . . . . 52 3.6.5.6 LED ring communication . . . . . . . . . . . . . . . 54 3.7 User studies methodology . . . . . . . . . . . . . . . . . . . . . . . . 55 3.7.1 User studies setup . . . . . . . . . . . . . . . . . . . . . . . . 56 3.7.2 User study - Observations . . . . . . . . . . . . . . . . . . . . 57 3.7.3 User study - Interviews . . . . . . . . . . . . . . . . . . . . . . 58 3.8 Comparing the remaining concepts to each other using kesselring ma- trices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.9 Conclusion of methodology . . . . . . . . . . . . . . . . . . . . . . . . 59 4 Results 61 4.1 Final test bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.1.1 Modularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.1.2 Replaceability . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.3 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.2 Results from the user studies . . . . . . . . . . . . . . . . . . . . . . . 63 4.2.1 Tactile buttons, placed on the joystick base . . . . . . . . . . . 64 4.2.1.1 Tactile buttons, placed on the joystick base, with visual feedback . . . . . . . . . . . . . . . . . . . . . 65 4.2.1.2 Tactile buttons, placed on the joystick base, with visual and haptic feedback . . . . . . . . . . . . . . . 65 xi Contents 4.2.1.3 Tactile buttons, placed on the joystick base, with visual and auditive feedback . . . . . . . . . . . . . . 65 4.2.1.4 Tactile buttons, placed on the joystick base, with visual, haptic and auditive feedback . . . . . . . . . 65 4.2.2 Touch sensor buttons, placed on the joystick base . . . . . . . 66 4.2.2.1 Touch sensor buttons, placed on the joystick base, with visual feedback . . . . . . . . . . . . . . . . . . 67 4.2.2.2 Touch sensor buttons, placed on the joystick base, with visual and haptic feedback . . . . . . . . . . . . 67 4.2.2.3 Touch sensor buttons, placed on the joystick base, with visual and auditive feedback . . . . . . . . . . . 67 4.2.2.4 Touch sensor buttons, placed on the joystick base, with visual, haptic and auditive feedback . . . . . . . 67 4.2.3 Touchscreen, placed on the joystick base . . . . . . . . . . . . 68 4.2.3.1 Touchscreen, placed on the joystick base, with visual feedback . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2.4 Tactile push buttons, placed in the joystick handle . . . . . . 69 4.2.4.1 Tactile push buttons, placed in the joystick handle, with visual feedback . . . . . . . . . . . . . . . . . . 70 4.2.4.2 Tactile push buttons, placed in the joystick handle, with visual and haptic feedback . . . . . . . . . . . . 71 4.2.4.3 Tactile push buttons, placed in the joystick handle, with visual and auditive feedback . . . . . . . . . . . 71 4.2.4.4 Tactile push buttons, placed in the joystick handle, with visual, haptic and auditive feedback . . . . . . . 71 4.2.5 LED ring, placed in the joystick base . . . . . . . . . . . . . . 71 4.3 Presentation of the strongest concept for each user scenario . . . . . . 73 4.3.1 User scenario 1 - Low speed in crammed spaces . . . . . . . . 73 4.3.2 User scenario 2 - Freedom for the developers . . . . . . . . . . 75 4.3.3 User scenario 3 - High speed driving, with a lot of function activation/deactivation . . . . . . . . . . . . . . . . . . . . . . 77 5 Recommendations 81 5.1 Plan for further development regarding the user studies . . . . . . . . 81 5.1.1 Recommendation on quantitative studies . . . . . . . . . . . . 81 5.1.2 Recommendations on further qualitative studies . . . . . . . . 81 5.2 Future development recommendations in regards to the test bench . . 81 5.2.1 The phone app . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.2.2 Active haptic feedback in joystick movement . . . . . . . . . . 82 5.2.3 Feedback of function status separated from the joystick . . . . 83 5.2.4 Button placement in joystick handle . . . . . . . . . . . . . . 83 6 Discussion 85 6.1 Discussion on user studies . . . . . . . . . . . . . . . . . . . . . . . . 85 6.1.1 Discussion on user base . . . . . . . . . . . . . . . . . . . . . . 85 6.1.2 Discussion on user study environment . . . . . . . . . . . . . . 86 6.1.3 Discussion on the tests of the Penta Joystick in the user studies 86 xii Contents 6.1.4 Discussion of possible symbiosis of solutions . . . . . . . . . . 86 6.1.5 Discussion of the placement of the activation components . . . 86 6.1.6 Discussion on the use of kesselring matrices . . . . . . . . . . 87 6.1.7 Dynamics of actual boats . . . . . . . . . . . . . . . . . . . . 87 6.2 Discussion on the test bench . . . . . . . . . . . . . . . . . . . . . . . 87 6.2.1 Discussion on the simulator . . . . . . . . . . . . . . . . . . . 88 6.2.2 Discussion on the big focus on creating the test bench and simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.2.3 Discussion on the choice of making the test bench modular . . 89 6.2.4 Ethical considerations . . . . . . . . . . . . . . . . . . . . . . 89 6.3 Learning outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7 Conclusion 93 Bibliography 95 References 95 A Requirements specification I B Transcripts from the user studies III xiii Contents xiv 1 Introduction This chapter presents the background, scope and objectives of the project. 1.1 Background In 2005 Volvo Penta launched their new Inboard Performance System (IPS) engines. IPS engines possess the ability to rotate and hence change the direction of the thrust. This makes it possible to translate the boat in one particular direction,(see figure.1). This technology facilitates navigation in cramped places like marinas. In order to take advantage of this new technology, CPAC systems developed a joystick (CPAC, 2020). Since 2005, the joystick has gone through one major re-design, during which new features were integrated and the design updated. Because of the emergence of new features, and the risk of these increasing the complexity of the current interface, another redesign is now needed in order to improve the user experience. Figure 1.1: Translation of boat 1 1. Introduction 1.2 Purpose The purpose of this project is to develop a new design concept of the existing joy- stick focused on user experience and the human machine interaction. The new design should integrate new and future functions without raising the level of complexity of the product, whilst still being able to carry out the same functions as its predecessor. Different kinds of feedback and activation methods will be evaluated. In addition, a test bench and a simulator should be developed, which will allow for future creative and innovative concept generation and exploration. 1.3 Objectives This project will evaluate the existing joystick and its functionality, and propose a new design concept. Furthermore, a test bench will be constructed with the objec- tive to perform user studies, compare the design concept to the current design and also to present the concept. The objective of the design concept is to facilitate the usage for novel users without compromising the experience for seasoned users. The following subjects will first be investigated in regards to the existing joystick, with the objective of evaluating the current situation, and secondly in order to verify the re-design. • Intuity How easy is it for a new user to understand the interface and usage of the product? • Integration of new functions How to integrate activation methods for new and future functions, e.g. As- sisted maneuvering, without increasing the complexity of the product? Furthermore, regarding the test bench, the following subject will be investigated; • Test bench How to construct a test bench that is easy to use for both developers and user studies? 1.4 Scope & delimitations The project comprises 1600 man hours, the equivalence of 60 credits. It proceeds until the beginning of June, 2020. The scope of the project needs to be limited due 2 1. Introduction to the time frame, therefore, there are some delimitations to the process; • Aesthetics and color choices will not be considered. • Manufacturing techniques and material choices are also outside the scope of the project. • No predefined internal development process nor design for environment pro- tocols at CPAC will have to be followed. • The final concept will not be evaluated for other segments than the marine. • As illustrated in figure 1.2, the main focus, marked with green, will be put on the joystick. Furthermore, the human-machine interface between the user and the navigation system, marked with blue, will be observed. The electronic vessel control system, the engines, hull and environment is outside the system boundary of this project. • The physical ergonomics of the joystick will not be investigated. Figure 1.2: Overview of system 1.5 Question formulation The question formulation is a more detailed description of the objectives. The following questions will be answered during the process; • Benchmarking – How is the product being used today and who are the users? – What does the market look like, is there similar solutions? 3 1. Introduction • Intuity – How easy is it for a novel user to understand the interface and usage of the product? – How does the haptic, visual and auditory feedback work today, and how can it be improved? After having looked into these questions, the following can be answered, • New conceptual design – Is there a need to update the joystick, and if so, how? – Test bench How should a test bench be constructed with the objective of it being easy to use for both developers and user studies? 1.6 Reading guide Each chapter is introduced with a short introduction and explanation of how the chapter is built up. The contents of chapter 2, theoretical frame of reference, act as a basis on which the rest of the report stands. It is meant to be read when referenced in the rest of the report. Each subsection will not be connected to its predecessor, and principles will be presented broadly in chapter 2. In chapter 3, Methodology, the process of the project is explained. Both how the test bench was developed, as well as the reasoning behind it, is explained here. In chapter 4 the results of the project are presented. Both in regards to the user studies and the test bench itself. No methods, theory of back ground of anything will be presented here, only the actual results. The fifth chapter consist of recommendations based on knowledge gained as well as results. In the sixth chapter, discussions on all the prior chapters is carried out. The last chapter of the report is a conclusion of the project. 4 2 Theoretical frame of reference In order to create a solid basis from which to develop the new design of the joystick, a theoretical frame of reference needs to be identified. This is done by first defining what is meant by user experience. This is followed by theory about user studies and data collection followed by product development theory and theory of technical components. Lastly, an identification of the current design of the product and a market analysis is presented. 2.1 What user experience is At its very core, (International Organization for standardization, 2019) defines user experience as, "user’s perceptions and responses that result from the use and/or anticipated use of a system, product or service" The term is further developed upon by the use of the term Usability. According to (International Organization for stan- dardization, 2019) usability deal with not only the satisfaction the user experience by using the product but also, with what level of "effectiveness, efficiency" it is carried out. In regards to developing a new version of a product this is especially interesting, as a raised level of both effectiveness and efficiency lowers the amount of resources involved in using the project whilst raising the level of accuracy with which it can be carried out. (International Organization for standardization, 2019). 2.1.1 Why user experience is important Alben(1996) describes that user experience, if carried out correctly, will create a value for the customer. This value in its turn may be the deciding factor that makes a user choose a product over another. An example of the importance of the user experience comes from the car industry, where research has been going on for years to identify what constitutes a preferable sound when closing a car door. As explained by Parizet, Guyader, and Nosulenko (2008), not only does the car door communicate that the door is closed to the user, but it also greatly impacts the over all impression of the car, which affect the customer purchase behaviour. Therefore it is important to research and understand this. One way to increase the user experience and usability is to adopt what is called a human-centered design. 5 2. Theoretical frame of reference 2.1.2 Implementation of human-centred design According to (International Organization for standardization, 2019) Human-centered design is described as, "approach to systems design and development that aims to make interactive systems more usable by focusing on the use of the system and applying human factors/ergonomics and usability knowledge and techniques". In- teractive systems in this context is described as that which the user interact with to realize a specific goal. This could for example be a car through which one can be transported from point A to B. The main principles of human centred design are according to International Organization for standardization (2019) the following, • Design based on an understanding of users tasks and environment • Users are involved throughout design and development • Design driven and refined by user-centered evaluation • iterative process • Design addresses the whole user experience • the design team includes multidisciplinary skills and perspectives 2.1.3 The interactive system The interactive system described in section 2.1.2, is supposed to be interacted with by a user through what is called a user interface. The user interface is supposed to be "an interactive system that provides information and controls for the user to accomplish specific tasks". (International Organization for standardization, 2019). In regards to a car, the user interface would be the steering wheel, dashboard and pedals. 2.2 Theory of user studies & data collection Below, theory of user studies and data collection being used in this project is pre- sented. 2.2.1 Usability test A usability test is an interaction analysis involving a test person and a proposed de- sign. The participant do realistic tasks using a proposed design represented by either a fully functioning prototype or a simple paper prototype. The test is observed and the data are analyzed, recommendations on improvements are then made. The data collected in the usability test can be quantitative and/or qualitative. Quantitative data can be e.g. time, number of clicks or errors. Qualitative data encourages the participants to think aloud about e.g. likes or dislikes. The test is often documented through video or audio recording.(Bligård, 2018). The strength of usability testing lies in the possibility to observe the interaction between a user and a product, also it is easy to re-design. The limitations lies in it is heavily resource expensive and the risk of context affects due to un-realistic work 6 2. Theoretical frame of reference environment. (Bligård, 2018). "Usability test is often the best interaction analysis method, but the fare most expensive method." (Bligård, 2018) 2.2.2 Exploratory & confirmatory user studies User studies are often initiated through exploratory methods. Exploratory methods has the goal of generating new ideas and uses most qualitative research. Confirma- tory research, as the name implies, has the objective of confirming user requirements discovered during the exploratory phase and does this mainly through quantitative research. (F. McQuarrie, 2006).Qualitative research may involve interviews and focus groups while quantitative research involves surveys(Malmqvist, 2019). 2.2.3 The structure of the user study Both observations and interviews can be either structured, semi-structured or un- structured. Structured studies means the questions or items for observation, and the order, are pre-defined. In un-structured studies some questions are predefined to make sure they are covered, but if other topics arise, these can be discussed or observed as well. Un-structured studies means no questions or items of investigation are predefined and the researchers role is more passive than in the previous two. (Wallgren, 2019). 2.2.4 Question-based & observation-based studies There are two main categories of data collection methods; question-based and observation- based (Wallgren, 2019). 2.2.4.1 Question-based studies Question based studies means you interact with the studied user. Question-based studies can be in the shape of e.g. interviews, focus groups or surveys. Question based studies has it’s strengths in; it is fairly time-effective and is really value adding in the exploration of a development phase. (Hvas Mortensen, 2020). According to Hvas Mortensen(2020), interviews are a great way to empathize and give you an in- depth understanding of their values, perceptions, and experiences. Interviews allow you to ask specific questions, while remaining open to exploring your participants’ points of view. 2.2.4.2 Observation-based studies Observation-based studies means you do not interact with the studied user. Ob- servations are an effective way to study situations where you can detect user re- quirements in the shape of comparisons, assumptions, compensating behaviours, actions, and solutions.(Wallgren, 2019). Observation-based studies can be divided 7 2. Theoretical frame of reference into natural or constructed observation. Natural observations are usually unstruc- tured and the researchers study spontaneous behaviour in a natural environment. Constructed observation means the researchers decide which users should partici- pate, where and when the study should take place and also the structure of the observation. The strengths of using natural observation is the opportunity to gener- ate new ideas.(Mcleod, 2015). According to Mcleod(2015), the benefits from using constructed studies is it is easy to replicate and it is usually less time-consuming. Observation-based studies is specifically useful because users do not always want to or can describe their problems and requirements. Also they may not even be aware of them and has started to a compensating behaviour. Furthermore, users can sometimes blame themselves for e.g. not understanding the product rather than blaming the design.(Wallgren, 2019). 2.2.5 Participator demographics in qualitative studies When conducting qualitative user studies, the user demographics are important to consider since the choice of participants will have a great impact on the gathered information. Often, you choose participants with a particular property, e.g. age, gender, product use experience. It is important the participants are part of the identified user group and they need to have experience of the product or the problem. (Wallgren, 2019). 2.3 Product development theory Below, the product development theory implemented in this project is presented. 2.3.1 Theory about the Kesselring matrix The kesselring matrix is a concept scoring method. In this matrix, the concepts are evaluated against each other on how well they fulfill the requirements. In addition, the requirements are weighted. The score that each concept gets on the fulfillment of the requirement is multiplied with the weighting of that certain requirement. This method is quite time consuming but provides precision to the assessment, compared to other concept scoring methods. (Almefelt, L., 2019). 2.3.2 Node-based workflows & processes In order to visualize workflows in a product developing process, black box models can be used. The black box model consists of three parts, a node in which an unknown process takes place, an input of known contents into the box, as well as an measurable output. In computer science this same concept is applied on the concept of nodes, where the node itself consist of the process carried out, whilst being connected to other nodes by inputs and outputs (Fundamentals, 2020). 8 2. Theoretical frame of reference 2.3.3 Theory on prototyping A functional prototype is close to the full functionality of the end product, e.g. a prototype with a user interface that works for the test data but is not well-designed enough to be integrated in the entire system.(Spacey, 2016). According to (Steven C. Wheelwright, 1992), prototyping is a key management tool for guiding development projects, and not a technical tool as traditionally viewed. Prototypes answer several questions, e.g. customer reactions and can take many forms. They argue that prototyping is a key to improve effectiveness and efficiency of the development process by contributing with learning about the product and the user. Furthermore, it is stated; prototypes play an important role in the testing and progress of the development project by providing insight in the design and it’s ability to meet customer requirements. 2.3.4 Design-build-test cycle Product development is a learning process, this is the basis of the design-build-test cycle methodology. "No matter how much an engineer, a marketer, or a manufacturer may know about a given problem, there are always unique aspects of any new system that must be understood before an effective design may be developed."(Steven C. Wheelwright, 1992) In order to fully understand the problem at hand, designers must go through several iterations, learning a little more at each cycle. The design-build-test cycle is built up on the phases; design, build and test. Figure 2.1: The Design-build-test cycle (Steven C. Wheelwright, 1992) In the design phase the problem is framed, this is crucial, since problems, gaps and 9 2. Theoretical frame of reference customer requirements are often underlying and hard to observe and characterize. When the problem is framed, alternatives for physical models, with the objective of closing the gap between design parameters and specific customer attributes, are generated. During the build phase, functioning prototypes of the ideas are created. The aim of these prototypes is to allow for testing. In the test phase, the prototypes are tested. Depending on the objective of the design, either a complete product or a sub-system may be tested. It is crucial to have a well thought through test plan and skilled execution in order to get good information from this phase, even though it may seem pretty straight forward. If the prototypes or models that are tested do not reflect the design intent, there is a risk of an unnecessary amount of iterations need to be conducted. Conducting a single cycle generates insight and information on the connection be- tween specific design parameters and customer attributes. The next cycle is then built on this as basis, this is repeated until a solution that meets the requirements is generated. (Steven C. Wheelwright, 1992). 2.3.5 Modular design theory Modular design is a design approach where a product is made out of modules with standardized interfaces. The objective of this design approach is to be able to change singular elements without replacing the entire assembly. Since the inter- faces is standardized, new modules can be made to accommodate new requirements, making modular products sustainable over time.(Ramalhete, R, 2017). Furthermore, modular design enables different designers to work on the same product simultane- ously, reducing the development time. However, the first phase in modular design methodology may take longer than an integrated design if a design is to be split up in modules and the interface defined.(Fast Product Development, 2020). 2.3.6 Design for assembly theory When designing a product, it is important to keep the assembly process in mind, this design evaluation method is called Design for Assembly(DFA) and was pio- neered by Boothroyd and Dewhurst at the University of Rhode Island (Kent, 2017). The principles of assembly include minimizing part count and designing parts with self-locating and self-fastening features. Furthermore, the design is encouraged to be modular and have a base part to locate other components. (Stienstra, D, 2019). Kent(2016) describes how DFA enables designers to reduce both the number of parts in an assembly, and also the assembly labour and time. Furthermore, it enables easier manual or automatic handling in assembly. 10 2. Theoretical frame of reference 2.3.7 Theory of Additive manufacturing Additive manufacturing(AM) or 3D printing is widely used to manufacture physical prototypes. The most popular used AM technique is material extrusion printing. Material extrusion means material is selectively dispensed from a nozzle which is typically heated (Hryha, E., 2019). When designing for Material extrusion printing, the following restrictions need to be met; First, the sides of the part may not have a smaller inclination than 40°, secondly, no circular holes may have a diameter bigger than 8mm, lastly, the design may not have overhanging features. If the design is preceding these limitations, support structure will need to be added to the print. (Hammar, L., 2019). Support structure can be made of either the same material as the main part, or a softer material that can be manually removed, or the support can be made of a material that is chemically or thermally removed, usually wax(Hryha, E., 2019). 2.4 Theory of technical components In this section, the theory of the technical components integrated in the test bench is described. 2.4.1 Micro controllers In order to be able to build custom human interfaces, one can user programmable microprocessors. These can both process inputs and send data to an external com- ponent. 2.4.1.1 Arduino The Arduino UNO is a micro controller with 13 digital pins that can be used to read the status of buttons or sensors. It also has the ability to send information to an external device over USB. 2.4.1.2 Seeeduino Similar to the Arduino, the Seeeduino has 13 digital pins which also can be used to read the status of different components, but it differs in the sense that it also has 12 extension ports on the front to which components can be connected. 11 2. Theoretical frame of reference Figure 2.2: The Arduino micro controller(elektor, 2020). Figure 2.3: The Seeeduino micro con- troller (elfa, 2020). 2.4.2 Theory about CAN data CAN, or Controller Area Network, is a communication protocol characterized mainly by the ability to assign priority to messages (Di Natale, 2008). CAN data is com- monly used in electronic systems to enable components to communicate with each other over what is called a CAN bus. The Penta joystick communicates with the rest of the EVC system over a CAN bus. 2.5 The current design of the product In 2005, Penta launched their IPS engines that has forward facing, rotating propeller pods, which can be positioned separately. In order to maneuver the propellers, an electronic vessel control system (EVC) was used. With the introduction of electronic control of the IPS-engines, it was realized that a vessel now could perform complex movements as rotations around one point and translation along vectors, as can be seen in figure 2.4 and figure 2.5. These move- ments could intuitively be translated into joystick movement, where translations would be mapped to x-y movements and rotations could be mapped to rotations of the top part of the joystick. The movement of the IPS-engines could be controlled in the background by a system, whilst the user could focus on their surroundings and using the joystick. 12 2. Theoretical frame of reference Figure 2.4: Force vectors from IPS- engines Figure 2.5: Resulting movement of boat depending on engine force vector In 2005, the Volvo Penta Joystick was launched with the main objective of maneu- vering the boat in low speeds, facilitating the docking procedure. The procedure could be carried out in two different speeds, the default speed and the high mode, where the latter was used in case of high lateral currents or wind. In 2009, the joy- stick went through a major re-design. The shape was updated to go in line with the updated throttle lever and the dynamic positioning system(DPS) was introduced and integrated into the joystick. The DPS works as a digital anchor where the boat is positioned with the aid of the engines and a GPS module. In 2009, also the joystick driving function was integrated, this makes it possible to use the joystick in full speed together with the autopilot, where the speed is controlled using the throttle lever and the direction using the joystick. Figure 2.6: Current design of the Volvo Penta Joystick (Volvo Penta, 2020) Figure 2.7: Previous design of the Volvo Penta Joystick (BoatDiesel, 2020) 13 2. Theoretical frame of reference 2.6 Market analysis In this section, similar products currently on the market are presented. The joysticks are bought as add-ons to the steering system, and are mounted by professional boat builders, i.e. it is not an over the counter product which the users can install themselves. The price of the product include installation. 2.6.1 Competing products The following products exist in the same marine segment as the Volvo Penta joystick. 2.6.1.1 Seastar Optimus 360 The Seastar Optimus 360 is a control device developed by Seastar solutions. The device in combination with an electric control system is made to be retrofitted into existing outboard motor solutions. It enables the vessel to rotate, and translate independently. This movement is achieved by using actuators to manipulate the engine position, and a component to change the rpm of the motor. This product does not offer the DPS, nor joystick driving function. Figure 2.8: The Seastar Optimus 360 joystick (Boating Magazine, 2020) 2.6.1.2 Mercury marines Axius The mercury marines axius is a control device developed by Mercury Marine. The device can be used in combination with both Mercury Marine inboard motors, as Zeus, and outboard motors, as Verado. The device enables the user to independently decide the rotation and translation of a vessel. It also offers the skyhook feature which has the same function as volvo’s DPS. In order to execute the sideways move- ment with the Mercury joystick. There are no mentions of any joystick drivinging functionality. 14 2. Theoretical frame of reference Figure 2.9: The Mercury marines Axius (Mercury Marines, 2020) 2.6.1.3 Xenta joystick The Xenta joystick can be used to steer larger yachts by retrofitting its control system onto an existing system. The device is developed by the Italian company Xenta and is used on larger vessels with inboard engines. The system rely on stern thrusters in order to facilitate movements both in translation and rotation. The joystick does not offer a DPS, nor joystick driving function. Figure 2.10: The Xenta joystick (Aqua Marine, 2020) 2.6.1.4 JCS by Yacht control systems Is a control device that can be used on boats equipped with inboard motors and bow thrusters. The device enables the boat to carry out complex rotation and translation movements during use. The JCS is developed by Yacht controller. The joystick does not offer the joystick driving function, nor the DPS. Figure 2.11: The JCS (Boat Mag International, 2020) 15 2. Theoretical frame of reference 2.6.1.5 Joystick maneuvering system (JMS) by ZF The JMS is developed by the company ZF, and can be used on both Pod-engines, similar to the IPS, and traditional shaft line propulsion systems. Bow thrusters need to be integrated in the systems for joystick functionality. In order to use the joystick, the system needs to have either ZF-Pod engines or ZF shaft line propulsion systems. This limits the use of the JMS to ZF products. It can aid the user with executing complicated translation and rotation movements when at sea. The functionality of the JMS relies on using a bow thruster in combination with the main engines. Figure 2.12: The Joystick Maneuvering system (ZF, 2020) 2.6.1.6 Yanmar JC10/20 The Yanmar JC10 and JC20 are control devices developed by Yanmar Marine. The JC10 is meant to be used in combination with Yanmar stern drive ZT370, and JC20 in combination with Yanmar shaft drive 8LV. JC10 does not demand a bow thruster while the JC20 does. It facilitates the ability to independently rotate and translate the vessel. A third party autopilot system can be integrated with the Yanmar JC10/20, but there is no mention of any joystick driving functionality. There is a positioning system similar to the DPS called Position keeping system. 16 2. Theoretical frame of reference Figure 2.13: The Yanmar JC10/20 (Yanmar Marine, 2020) 2.6.1.7 Cummins joystick Cummins has two different types of joysticks. One joystick works with the Mercury marine Zeus system and the other with their own inboard engines together with a bow thruster. The one compatible with Zeus offer the same functions as the MerCruiser Axius. The latter mentioned only works in low speed and is solely used for docking. Figure 2.14: The Cummins joystick (Båtliv, 2020) 2.6.2 Similar products with other use areas As mentioned above, further solutions used to control systems outside the marine segment has also been looked into. 17 2. Theoretical frame of reference 2.6.2.1 Control stick JAS Gripen The JAS Gripen control stick is used to control the movement of the fighter jet JAS Gripen. Since the device is supposed to be operated by a highly knowledgeable operator, lots of functions can be integrated into the design in the form of buttons. A user unaware of what these buttons do would probably find it difficult to use the device. Figure 2.15: The Jas Gripen Control stick (x plane, 2020) 2.6.2.2 Media control unit in cars The media control unit used in most cars with media center integration employ the same function integration, but may differ in design. In difference to the JAS control stick, this device is supposed to be used by a user with no prior knowledge about its use. It therefore needs to be intuitive and easy to understand. Hence, every button is named. 18 2. Theoretical frame of reference Figure 2.16: A Car Media Control unit (Xotic Tech, 2020) 2.6.2.3 Construction equipment control stick The construction equipment control stick is designed with the knowledge in mind that the user will work with it during long periods of time, and therefore it needs to be ergonomic. On the other hand, there are lots of buttons, which may result in an inexperienced user having a hard time using it, whereas a seasoned veteran would operate it with ease. Figure 2.17: A Construction joystick (Curtis-Wright, 2014) 19 2. Theoretical frame of reference 2.6.2.4 Game Controller When using one joystick to control both the rotation and translation of a vessel, it is apparent that the ability to rotate will have to be integrated in the design. On the Volvo Penta joystick, this is integrated into the rotation of the shaft. The game controller design on the other hand has divided the function of rotating and translating into two separate joysticks. One controls the translation and the other one the rotation. This may seem complex for the first time user as it needs the simultaneous use of both hands independently, but for someone who have used it a lot, it is very versatile. Figure 2.18: A Sony PlayStation DS3 (Sony, 2020) 20 3 Methodology In this chapter, the product development process applies in the project is first ex- plained. This is followed by a presentation on the methodology on understanding the product, defining areas and improvement and defining the means. After this, the process of understanding the use of the product and defining the use scenarios in explored. This is followed by the user study methodology, and lastly, the methodol- ogy for concepts comparison is presented. The principles of human-centered design, presented in section 2.1.2, is applied throughout the developemnt process. 3.1 Product development process overview The product development process used is visually described in figure 3.1. The pro- cess started off by understanding the user needs, during which a deeper under- standing of the product was gained, and a requirements specification was created. After this a function means matrix was generated, based on the understanding of the product and literature studies. A morphological matrix was after this created, which in turn was used to generate different concepts that needed to be tested in a test bench. I order to test the concepts, user studies were carried out, followed by elim- ination of concepts and kesselring matrices. Several kesselring matrices were made, based in different scenarios and different weightings. Recommendations depending on scenarios could after this be given. Figure 3.1: An overview of the process workflow 21 3. Methodology 3.2 The process of understanding the product In order to understand the product, a rigid study on its technicality, function and users had to be carried out. Understanding the product is also the first principle of human-centred design, and enables the developer to identify the context of use for the product. A study of how the product was being used was conducted by reading literature, watching videos, talking to experts, watching the product being used and using the product. A big part of this study consisted of understanding the joysticks part in the whole system, and also understanding the system. In short, the context in which the product is used. Furthermore, the kind of boats where the joystick could be used was mapped. To fully understand the functionality of the joystick, tests of the product in its actual use environment were conducted by trying it out in a boat. Observations of users interacting with the joystick while driving an actual boat was carried out with the aim to understand how the customer use the product. In this stage the users were also analyzed. To understand the technology and logic behind the system, meetings were held with employees at CPAC, with deep knowl- edge within the maritime segment of Volvo Penta. Knowledge from this stage was used to formulate the requirements for the product as well as the context of use. Furthermore, based on the findings in this stage, different user scenarios were identified. 3.3 The process of defining areas of improvement In order to know what functionality the test bench should have, first the possible areas of improvement had to be investigated. At its most basic, a new version of a product will need to be able to carry out the same functionalities as its precursor. Not in the sense of specific functions, but rather over all functionality. If this is not met, there may be customers that would prefer the older version. In order to make sure this requirement was met, the functionality of the joystick was mapped as described in section 3.1. To understand the areas of possible improvement, first employees at CPAC was asked about their opinion on the joystick, secondly this was complemented by reading reviews on the product, and lastly the product was tested and analyzed. When the users and the joystick had been analyzed and experts had been inter- viewed, the requirements on the joystick could be concluded in a requirement spec- ification, see Appendix A. All concepts generated fulfill the basic requirements pre- sented in the requirements specification. Further on, the wishes will be referred to as requirements. 22 3. Methodology 3.4 Defining the means As described in 2.2, user experience is based in that users has to interact with a product using the human senses. In regards to a joystick users use touch to interact with the joystick, and it in turn interacts with the user by using visuals, haptics and sounds. From this, a conclusion could be drawn that one needed to look at the means to two different problems; • How can the joystick communicate with the user • How can the user communicate with the joystick? From the market benchmark it was found out that most joysticks on the market uses LED’s or external screens to indicate what functions are activate at a certain time, as is the case with the current Penta joystick. In the case of the Game con- troller presented in 2.7.2.4, haptics is also used to convey information to the user. Furthermore, sounds were used to indicate the activation of both the joystick and sometimes also functions on the joystick. In order to activate different functions, users press tactile buttons on most joysticks. Based on these findings it was decided that looking into both visual, haptic and auditive feedback was interesting in regards to the feedback the user receives from the joystick. It was also decided to look into visuals, audio and haptics in regards to how the user interacted with the product. With this reasoning as a background, literature studies were carried out with the aim to find what sort of components that existed on the market that could carry out the haptics, audio and visuals. Below, each of the identified means are described together with hypotheses on their strengths and limitations. 3.4.1 Visual feedback to the user The most common way to communicate the status of a function to a user is through LED’s. LED’s are easy to connect to a microcontroller or a custom chip which in turn can turn them on when required. A special type of LED is an LED ring, that can be placed around the joystick base, see figure 2.9. In some applications, as with a computer, touchscreens are used to communicate what functions are activated or not to a user. 3.4.1.1 Hypotheses on the strengths and limitations of LED’s LED’s are used in many applications in our everyday life to indicate what functions on a certain product that are activated. This is also the case with the existing Penta joystick. Users will probably understand that the activation of a LED is connected to the state of a function, especially if a sticker or similar with a symbol indicating function is situated next to the LED. 23 3. Methodology 3.4.1.2 Hypotheses on the strengths and limitations of touchscreens There are two main hypothesis behind usability of a touch LCD. Firstly, since a big part of the worlds population has a phone, it is believed that users will have no trouble understanding how to activate functions on the display. Secondly, as there is no haptic feedback in a touchscreen to indicate that a function has been activated, the user will need to look at the screen a lot, which may be dangerous if driving fast at sea. Furthermore, touchscreens may loose their functionality in wet conditions. It may also be hard for the user to operate a touchscreen if wearing gloves. 3.4.2 Auditive feedback to the user In order to communicate information auditively, speakers of some sort are most of- ten used. These speakers can vary greatly in size, sound quality and strength. 3.4.2.1 Hypotheses on the strengths and limitations of speakers Lots of products use speakers to indicate function activation, therefore users would probably understand that a sound signal is associated with function activation, and not have to look at the joystick to understand if a function was activated. If speakers are used as auditive feedback, it has to be used to indicate the activation of a function, as with a short sound signal, and not that a function is activated. If a auditive signal is activated during the time a function is activated, it will irritate and distract the users. 3.4.3 Haptic feedback to the user Vibration motors, often called rumble motors, are widely used to haptically com- municate information to users. Several game controllers use vibration motors to communicate for example when a player drives on a rough gravel road in a driving game. Joysticks with haptic force feedback on the movement has since long existed in the flight simulator community. It has been used to simulate the feeling of flying an actual plane. Another way of giving haptic feedback to the user is by altering the resistance, opposite the movement, of the joystick. 3.4.3.1 Hypotheses on the strengths and limitations of vibration motors As is the case with speakers, lots of products use vibrations to indicate the activation of functions. This in turn mean that users would have to look a lot less at the joystick to verify if a function was activated, as vibrations indicate this. 24 3. Methodology 3.4.3.2 Hypotheses on the strengths and limitations of a joystick with haptic force feedback An active force feedback in the joystick movement could be used to indicate extra information about the boats movement to the user without them having to look at the joystick. Most users are not used to this kind of feedback and would therefore probably have to take some time to understand it. Because this technology was not at hand during the course of this project it could not be evaluated, see chapter 5 & 6. 3.4.4 Haptic communication from the user to the joystick As mentioned earlier, it was found through the benchmarking that most joysticks used tactile buttons in order to let the user communicate with the joystick. As is the case with the existing Penta joystick. In the literature study it was found that several more ways of letting the user communicate with the joystick could be implemented. In some TV’s there exist touch sensors that detect if a user press a certain surface in the border of the screen, and turn on the screen if a press is detected. IR sensors have also been used for these kinds of applications, where they detect if an object is close enough to the sensor and if so send a signal to an external component. touchscreens are an example of a combination of both a visual feedback and way for a user to haptically communicate with a product. A common example of this is the screens built into phones which can both show the user relevant information whilst enabling them to communicate with the phone through touch. 3.4.4.1 Hypotheses on the strengths and limitations of tactile buttons Tactile buttons are used on the current joystick, and will act as a reference through- out the study. As is believed with the touchscreen, users will probably have to look at the button in order to determine their position and status. 3.4.4.2 Hypotheses on the strengths and limitations of IR/capacitance sensor Both a capacitive touch sensor and an IR sensor could be implemented in similar manner, and therefore they have the same hypothesis. Firstly, there may be prob- lems with both IR and touch sensors being covered in some manner, which may impact the viability of the sensor. Secondly, as the user will have no way of deter- mine where the activation surfaces are situated, as the sensors are mounted under the surface, they will probably have to look at the joystick a lot when activating functions. Furthermore, nor capacitive touch or IR sensors work in wet conditions. 3.4.5 Auditive and haptic communication from user to the joystick Both the users voice and vision can be used for activation of functions. In some products voice recognition is used to let the user for example call people, as in the 25 3. Methodology case with a phone. The users eye position can also be used to evaluate where they are looking, and thereby activating functions. 3.4.5.1 Hypotheses on the strengths and limitations of voice and visual command Both voice and visual command are hard to use when driving a boat since there is lot of background noise and you need to keep your eyes on the sea. Because of this, it was decided that both these technologies were too complicated to evaluate and too inaccurate, and therefore they were discontinued. 3.4.6 Conclusion on defining the means In order to evaluate which components that needed to be included in the test bench, it was concluded that an evaluations of what functionalities to activate and how to give feedback about this should be carried out. A matrix containing all functionali- ties, as well as the means through which they can be carried out, was constructed. This matrix can be seen in figure 3.3. This matrix lay basis for what components to include in a test bench. Figure 3.2: An overview of functions and means After having identified the means, these could be combined into concepts that should be tested in the user studies. Beyond solely combining the means, it was also decided to have both one concept where the tactile buttons were placed on the base, and also one where the buttons were placed in the handle. Furthermore, because of technical limitations, the touchscreen could not be combined with audio or haptic feedback. The concepts that were generated are presented below. Figure 3.3: The concepts generated to be tested in the user study 26 3. Methodology In addition to the concepts presented in figure 3.3, also a concept with an LED ring was studied on the users. This concept was chosen to go through with since it was fairly easy to integrate into the design of the test bench, and also the simulator code. As this concept is a special variation on the led concept, it is presented outside of the other concepts in order to not confuse it with the led concept. 3.5 Understanding the product in use and defin- ing the different user scenarios After having identified and analyzed the different users, it was concluded that they differ a lot from each other. Furthermore, the future use area of the joystick is un- certain. This made it hard to determine which user requirement to rank higher than another. With this in mind, it was determined that different concept evaluations should be carried out, for different user scenarios. Below, the different scenarios are described. 3.5.1 User scenario 1 - Low speed in crammed spaces This is similar to how the joystick is being used today. In this scenario, the joystick mostly is mostly used for docking in low speeds in crammed spaces. It is hence of utter importance that the user do not mistakenly activate a function since this could risk e.g. a collision. Because of this, in this scenario, it is important to be able to differentiate buttons from each other visually and haptically.It is also important to have robust technology since you should be able to locate the joystick in an outdoor environment. The robustness of the design is more important than the ability to easily push new updates of the joystick. 3.5.2 User scenario 2 - Freedom for the developers In this scenario it is of great importance for the developers to be able to push updates of the functionality and the software of the joystick. Also, the designer values the fact of not having too many design constraints when constructing the joystick. In this scenario, the joystick is mostly located indoors or the touchscreen technology has advanced and is now fit for outdoor environments. 3.5.3 User scenario 3 - High speed driving, with a lot of function activation/deactivation In this scenario, the user activates functions several times per trip, taking away the importance of being able to visually locate the buttons. In this scenario, the joystick is not used in crammed spaces making it of less importance to not activate the wrong function. Furthermore, because the user is travelling at high speeds, it is deemed important that the user does not loose visual focus on what is going on around them. 27 3. Methodology 3.6 Test bench methodology In a user study, both a test bench with concepts to be tested, and a use case in which to test it is needed. In this project, these components are presented in the shape of a physical test bench the user can interact with, and a simulator that simulates the experience of driving a boat. 3.6.1 Test bench overview In order to simplify the explanation of how the test bench is both physically and digitally connected, figure 3.4 was created. The dotted arrows mean digital commu- nication, and the filled in arrows represent physical contact between components. The colors represent different sub-systems that will be further presented below. Figure 3.4: An overview of the test bench components 3.6.2 Test bench development workflow With modern tools as CAD software, it is possible to assemble a product virtually before manufacturing. This to make sure that everything fits and can be mounted. When this is verified, manufacturing can begin. Since the test bench is supposed to facilitate the testing of different components by users, its important to always 28 3. Methodology take the principles of human-centred design into consideration. The main design requirement is always that a user should be able to operate the test bench. By utilizing this development workflow, it could be ensure that the final test bench can be manufactured and assembled without having to do too many revisions. 3.6.3 Test bench - The making of the communication with the electrical components The need for developing a test bench was based in the reasoning that a user needs to interact with something when carrying out the user studies. This something needed to be able to communicate the visual, haptic and auditive feedback to the user whilst processing the user input, and making modifications to the simulation. In order to present the test bench in an comprehensive way, each function it needs to be able to carry out will be presented followed by the software and electronics that makes it work. 3.6.3.1 Test bench - Electrical components overview The test bench exists for two reasons, to communicate stimuli to the user, and to communicate user-input to the simulation. Below, each function is described fol- lowed by the software and hardware that makes it run. The core of the test bench consist of the metallux joystick base, an Arduino uno rev3, a Seeeduino cortex M+ as well as an powered USB-hub. The arduino and seee- duino facilitates the feedback to the user and button-statuses, whereas the metallux- joystick facilitates the user-input on the joystick. In essence, there are two parts of the physical test bench. One part concerns the reading of CAN-data, figure 3.6, and the other, figure 5.1the processing of user button inputs and user feedback communication. Both parts are connected to a computer over USB. 29 3. Methodology Figure 3.5: The connection of the seeeduino and arduino to pc over USB 30 3. Methodology Figure 3.6: The connection of the metallux joystick to pc over CAN bus and USB 3.6.3.2 User-input The user needs to be able to communicate what functions to activate, and what to deactivate to the simulation. It also needs to communicate this information in a manner that does not slow down the simulation too much. In order to realize this, the subsystem presented in figure 3.7 was created. 31 3. Methodology Figure 3.7: An overview of the test bench components As explained above, the test bench is based on the metallux joystick as well as one seeeduino and one arduino uno rev3. The Seeeduino can be used to detect button presses, and also communicated this to the simulation, whereas the arduino is used as the base for a touch LCD screen. By use of the arduino IDE, code was developed that every time the seeeduino runs the void loop() function reads the status of each button and checks if it differs from the last status. For example, if a user was to press a button the seeeduino would register a change of status on the button circuit and communicate the status of each button to the simulation. This circuit is visualized in figure 3.8 This logic behind the collection of user inputs could also be used when reading data from IR- and touch sensors. Since both sensors communicate either HIGH or LOW to the Seeeduino depending on if they measure and object nearby, nothing needs to be changed in the code when switching between sensors and buttons. Each sensor has a female Seeeduino connection, to which a male connector needs to be connected. Each connector is built up of four inputs as in figure 3.9. By connecting GND of all sensors together and to a common ground on the seee- duino, as well as connecting 3v3 of all sensors to the same 3v3 pin on the seeeduino, the sensors could be connected to the board with eases. The Nc connector did not need to be connected to anything, and the SIG of each sensor was connected up to a digital pin on the seeeduino. 32 3. Methodology Figure 3.8: The connection of buttons to the Seeeduino Figure 3.9: The four connectors on the Seeeduino cable This enabled the reading of status of each sensor. 3.6.3.3 User-input communication When the button status has been read, it needs to be communicated to the simula- tion. In order to not slow down the simulation to much, components needed only to communicate their status when their status change. For example, if a button was pressed and thereby a circuit closed, there was only need to communicate that the circuit has been closed, not that it was closed. The same for when the circuit was opened. This communication was made over usb using the SerialUSB.write() function on the seeduino. A simple function, called sendData(), facilitating communication, was called each time the seeeduino detected a button status change was also written. 1 void sendData () { 2 SerialUSB .write("<"); 33 3. Methodology Figure 3.10: Four sensors connected to the seeeduino 3 SerialUSB .write( buttonState1 ); 4 SerialUSB .write( buttonState2 ); 5 SerialUSB .write( buttonState3 ); 6 SerialUSB .write( buttonState4 ); 7 SerialUSB .flush (); 8 } Listing 3.1: sendData function Each time a change in button status was detected, the sendData() function was called upon and the data was sent to the simulation. 3.6.3.4 Visual feedback - LED’s One way for the user to understand what functions are activated, is to let the test bench communicate this through turning on LED’s in accordance with what functions are activated. In figure 3.38 the simple circuit used for turning on LED’s can be seen, here digital ports D8-D11 are initialized and used as outputs for turning on or off the LED’s. 1 const int ledPin1 = 8; 2 const int ledPin2 = 9; 3 const int ledPin3 = 10; 4 const int ledPin4 = 11; 5 void Start () { 6 pinMode (ledPin1 , OUTPUT ); 7 pinMode (ledPin2 , OUTPUT ); 8 pinMode (ledPin3 , OUTPUT ); 34 3. Methodology Figure 3.11: The connection of LED’s to the Seeeduino 9 pinMode (ledPin4 , OUTPUT ); 10 } Listing 3.2: Assigning LED values 3.6.3.5 Visual feedback - touchscreen In order to implement a touchscreencomponent in the test bench, a arduino with spe- cialized touchscreensoftware was used. To the arduino a touchscreenwas connected. This touchscreencould then display virtual buttons whilst constantly checking for finger presses. When a press is detected, the software checks if the press was inside any of the areas on the display where a button is displayed. If so, it logs what button was pressed and communicates with Unity on a computer over USB. This is done in the same manner as the user input communication presented in the code in figure 3.1. 3.6.3.6 Auditive feedback - Speakers By connecting a speaker to the Seeeduino in accordance with figure 3.38, it is possible to have full control over when the speaker fires and what sound it makes. This opens up the possibility of putting in sounds in the main void loop() of the seeeduino code. A function called sound() was created and called on each time the seeeduino registered a button press. The function starts of checking the status of a Boolean value called speakerStatus, which if false prohibits the speaker to emit sound, and thereby enables the user to completely turning of the sound buy changing one value in the code. The main body of the function was based on code available from Seeed Technology Co.,Ltd (2020a). 1 void sound( uint8_t note_index , int arr []) 2 { 35 3. Methodology 3 if ( speakerStatus ){ 4 for(int i=0;i <15;i++) 5 { 6 digitalWrite (SPEAKER ,HIGH); 7 delayMicroseconds (arr[ note_index ]); 8 digitalWrite (SPEAKER ,LOW); 9 delayMicroseconds (arr[ note_index ]); 10 } 11 } Listing 3.3: LED function Figure 3.12: The connection of a speaker to the Seeeduino 3.6.3.7 Haptic feedback - Vibration motor As well as using sound to indicate feedback about the state of a function, one can utilize vibrations. There exist a simple but usable vibration motor available from Seeedstudios, the grove vibration motor. By connecting this motor to ground as well as 3v3 and a digital pin, data can be written to the motor that makes it turn when nessecary. As with the speaker, there exist some main code from Seeed Technology Co.,Ltd (2020b) which can be utilized. The code in listing 3.4 is based on the code from Seeed Technology Co.,Ltd (2020b). 1 void vibrateMotorOn () 2 { 3 if ( vibration ) 4 { 5 digitalWrite (vibrPin , HIGH); 6 } 7 else {} 8 } 9 void vibrateMotorOff () 10 { 11 if ( vibration ){ 12 digitalWrite (vibrPin , LOW); 13 } 14 else {} 15 } Listing 3.4: Vibrationmotorfunction 36 3. Methodology Each time the motor should start vibrateMotorOn() is called upon, when it is to stop, vibrateMotorOff is called upon. This means these two functions can be in- cluded in void loop() and thereby when a button press is recognised, the motor vibrates. As wait() does not work when used inside a function, vibrateMotor() had to be divided into vibrateMotorOn() and vibrateMotorOff(). These two could then be called upon in the main loop, loop(), with a wait() inbetween them. Figure 3.13: The connection of a vibration motor to the Seeeduino 3.6.4 Test bench - Creating the mechanical design In order to for the user to interact with the sensors and electronics there had to be a physical interface between the two. This interface was created in the shape of a plug and play test bench where different modules can be altered depending on the desired analysis. This way, only one test bench has to be developed onto which different components can be connected. 37 3. Methodology 3.6.4.1 Creating the overall design Figure 3.14: The complete assembly of the test bench In order to develop the test bench, an idea generation was carried out. The idea generation phase was based in an exploitative session where several concepts were visualized both in drawings and in CAD software. Several concepts were created with the basic requirement of being comparable to the existing Penta joystick, and also to accommodate the electrical components identified in the previous step. An overview of the components that needed to be physically connected to each other, can be found below in figure 3.15. Each arrow represents a physical connection. 38 3. Methodology Figure 3.15: An overview of the physical connections between components First of all, it was decided that the handle would need to be bigger than the Penta joystick since it was going to hold buttons and chords. Also, when having buttons on the joystick, it was decided that it needed to be ergonomically fit. As mentioned earlier, the most important thing is that the user should be able to operate the test bench. A literature study on the size of an average hand palm was conducted. With this data as basis, the handle was designed to be about 85mm high and a diameter of 40mm (Söderström, 2019). Also the handle should not have any sharp corners or edges and should sit comfortably in your hand. The handle was created using CAD, making it possible to import a manikin and see how it fit in the hand, see 3.16. Furthermore, the base of the test bench was decided to be similar to the size of the Penta joystick but at the same time it needed to hold all the additional electronics. 39 3. Methodology Figure 3.16: By inserting a manikin into CATIA, the shape and size of the handle could be tested. 3.6.4.2 Making the test bench modular In order to accommodate the swapping of components during testing it was dis- covered that the test bench would need to be modular. Furthermore, this made it possible to test other electrical components, that are not included in this project. As can be seen in 3.17 & 3.18, the base of the test bench consists of of one center piece that houses the metallux joystick and circuit board, to this piece you can add different modules depending on where you want your electrical component to sit. The different modules are, in turn, also modular in the sense that you can change the electrical component module because they all have the same dimensions, see figure 3.21. In the same way, you can swap the handle depending on which component, e.g. tactile buttons or IR sensors, you wish to try. An overview of the handles can be seen in figure 3.20. 40 3. Methodology Figure 3.17: The metallux joystick. Figure 3.18: The metallux joystick placed in the centerpiece of the mod- ular test bench design. Figure 3.19: The test bench with the metallux joystick, centerpiece, handle and a module. 41 3. Methodology Figure 3.20: Some of the different handles that were developed. Figure 3.21: Some of the different modules that were developed. 42 3. Methodology Figure 3.22: The plates that were to house the different activation components were made to be the same size as the touchscreen. 3.6.4.3 Deciding where to place the electrical components A further question discovered during these sessions was, where on the joystick the different components presented in section 3.4 should be placed. A new session, with the objective of deciding this, was carried out. From this session, it was concluded that; • Activation surfaces can be placed everywhere on the joystick handle as long as it is not in the way of the users hand. • Activation surfaces can be placed on three main areas of the joystick body, on the front, on the left side and on the back. The right side of the joystick is turned away from the user and will therefore not be suitable for button placement. This can be seen in figure 3.23, figure 3.24 and figure 3.25 below. 43 3. Methodology Figure 3.23: The centerpiece with a module in the front Figure 3.24: The centerpiece with a module on the left side Figure 3.25: The centerpiece with a module in the back During this session, further questions regarding how a component could be placed on each area on the joystick base were raised. It was concluded that the angle of the components were interesting to look into, because of this the modules were design to have three different angles; 0°, 45° and 90°. These modules can be seen below in figure 3.26, figure 3.27 and figure 3.28. A module with a 135° angle, see figure 3.29, was also designed. This could be mounted on the back of the main body of the joystick. 44 3. Methodology Figure 3.26: 0° module Figure 3.27: 45° module Figure 3.28: 90° module Figure 3.29: 135° module 3.6.4.4 Designing the test bench with assembly in mind As described in 2.3.8, a lot of time can be saved if designing a product with assem- bly in mind. In order to realize the ideas from the work shops, CAD models were created in CATIA V5. In addition, all third party electrical components were also modelled in CATIA. Each one on the models were assembled digitally into concepts to ensure that no errors regarding the physical interface between the components were made. Furthermore, since each module was to be mounted onto the center piece, it was necessary to make sure that a small screwdriver could fit into each module to fasten it. This can be seen below in 3.30 & 3.31 where the opening on the side is big enough for a screwdriver to fit. Bolt holes placed in areas where it was deemed hard to reach was equipped with a counterbore where the nuts could be glued on. 45 3. Methodology Figure 3.30: Attachment of a module to the centerpiece using a bolt and a glued nut. Figure 3.31: The modules are designed in such a way that a screwdriver can be used. 3.6.4.5 Designing the test bench with usability in mind Since the test bench was also supposed to be used by a user, it was important that it was strong enough to withstand use. Areas that were more likely to withstand a greater force were therefore designed to be a bit thicker in order to carry a greater load. 46 3. Methodology Figure 3.32: The drawer underneath the test bench with the purpose of hiding away components and enabling hot switching. It was decided that users should not be distracted by the cords and electrical com- ponents that built up the internals of the joystick. With this in mind, a drawer was placed underneath the joystick, which in turn could be pulled out when hot swapping components during testing. This drawer can be seen in 3.32 & 3.31. Fur- thermore, the chords that needed had to be connected to a power supply or to the computer was drawn through a hole in the back of the drawer. 3.6.4.6 Designing the test bench with manufacturing in mind In order to manufacture the test bench in a fast and reliable way, it was decided to look into the possibility of using Additive Manufacturing(AM), or 3D printing which is the common name for it. As declared in section 2.3.7, AM puts several constraints on the design of the models. Because of this, models were designed with a certain printing direction in mind, leaving it with little to no need of support structures. The model in figure 3.33 only need support structures in the holes. If the part had been printed in any other direction it would have resulted in more support structures and therefore more post production fixes. 47 3. Methodology Figure 3.33: The direction of the print. 3.6.4.7 Conclusion of the mechanical design A lot of time and effort was put into making the mechanical design of the test bench. Because the assembly, use and manufacturing was considered in each step of the process, only one setup of the test bench had to be printed. Figure 3.34: Overview of all 3D models. 48 3. Methodology 3.6.5 Developing the simulator In order to evaluate a test bench its is necessary to create an environment in which it can be tested. The ideal environment would be in the scenario where the actual joystick is used on a boat. When developing a test bench there is a possibility that components and code stop working or work in an unintended way. This in combination with a sharp situation at sea may result in disaster. With this reasoning as a basis it was decided that a simulation could be used as environment. This comes with the drawbacks that some factors of the real environment may not be able to be conveyed to the user, which could result in faulty or poor data. 3.6.5.1 Simulator overview The simulator has three main objectives. To read and process user input, To read and process joystick data from the metallux joystick, and the simulation of a boats movement on water. there are many ways to realize this, the only important part is that a user needs to be able to manipulate the position and rotation of the boat by the use of the test bench, whilst activating/deactivating functions. One could build a simulation engine from the bottom up with all relevant components for the simulation to work, or one could utilize an existing game engine. A good compro- mise of both is a game engine as Unity or Unreal Engine, where one can utilize the game engine to manage the rendering of each frame whilst still having control over user input and what to render. Unity utilizes scripts written in C# to control the user input and the manipulation of sprites, whilst Unreal uses C++. Unreal is also mainly focused on 3D rendering and applications, where as Unity can be used for both 2D and 3D. As the main part of the project is to research user feedback and not to develop a simulator, it was decided that a 2D simulation in unity would be sufficient enough. The Simulation should be able to communicate with both the metallux joystick, Arduino and Seeeduino, as can be seen in figure 3.35. The USB- hub in this figure, represents the data coming from the Seeeduino and Arduino, as it has to travel through the hub to reach the simulation. 3.6.5.2 Simulator functionality There exist four main functions the user should be able to activate in Unity, Func- tion1, Function2, Function3 and Function4. These are essential to mimic the actual use case for the test bench. In order to activate each of the functions, there are checks in the main Unity C# code that identifies if a button was pressed or not. Each check is built in the same way, as the code in listing 3.5. 1 if ( Button1Pressed ) //If a buttonpress is identified ButtonPress = true. 2 { 3 if ( Function1 ) // bool that respresent the current status of the function 4 { 5 // Functionspecific code for activated function 49 3. Methodology Figure 3.35: An overview of the in-data to Unity 6 Function1 = false; 7 } 8 else 9 { 10 // Functionspecific code for deactivated function 11 Function1 = true; 12 } 13 } Listing 3.5: Button press functionality Each of the four functions utilizes this same check with their own buttonxState and Functionx status. The drawback with using this kind of check is that if a button consistently gives a value of true when activated, the function will flicker on and of time and time again. To avoid this further button-logic needs to be implemented that only sets the value of button1Pressed to true the frame the button is pressed, and then reset it to false the next frame. 3.6.5.3 User-input processing in Unity As the application developed in unity calls on void Update() when drawing each frame, every instruction within the function will be carried out before each frame. This means that it is possible to check buttons statuses or check if there is any input from an external device before each frame. This comes with the possible pitfall that if an external device constantly sends data to unity ,the speed of the simulation may be severely crippled. This was observed several times when trying to read data from the metallux-joystick base whilst simultaneously reading data from the seeeduino. A workaround for this problem is to make a check of the length of the data from the seeeduino before reading it. If the length is zero, then there is no point in trying to read it. The seeeduino, as mentioned earlier, only send data if there is a status 50 3. Methodology change on any of the buttons. As the seeeduino send data according to the function described in the code in listing 3.1, Unity also needs to read the data in the same manner. To do this, a C# script was written that first checks weather there is any data coming from the seeeduino, then it checks is the data is the symbol <, if that is the case, it reads the following four values from the seeeduino in as the status of each of the four buttons. This code can be viewed in listing 3.6 1 void Update () 2 { 3 buffer_length = sp. BytesToRead ; 4 if ( buffer_length != 0) 5 //If the length of data not equal to 0 6 { 7 if (sp. ReadByte () == 60) // int 60 to str = "<" 8 // Check if seeeduino sent "<" 9 { 10 //If true , read next 4 as status of each button . Either 0 or 1 11 knapp1 = sp. ReadByte (); 12 knapp2 = sp. ReadByte (); 13 knapp3 = sp. ReadByte (); 14 knapp4 = sp. ReadByte (); 15 } 16 } 17 } Listing 3.6: Button status reading in Unity 3.6.5.4 Joystick data processing in Unity As the Metallux-joystick communicates over a CAN bus, as can be seen in 3.36 be- low, there is need of either building a device able to read this information or utilizing an existing device. 51 3. Methodology [ xdata, xdata, ydata, ydata, zrotation, zrotation, buttonStatus, frameCounter ] Figure 3.37: CAN-data Figure 3.36: An in detail overview of what is connected to the metallux joystick At CPAC there was the possibility of borrowing a PCAN-USB which could be connected to a break out box (BOB) over serial communication. A power source in the form of a power supply was connected to the BOB to drive the joystick. This in turn meant that the CAN-data on the buss could be read into the computer directly over USB when combined with a PCAN-USB driver on the computer. In order to read the data into unity, there was also the need of using a API developed by PCAN to communicate with the PCAN-driver in the computer. This API and a .dll was available from PCAN in C# which meant that the data could be read straight into Unity through a C# script . The CAN-data read from the Joystick through the API comes in the form of an TPCANMsg object, which has the method DATA which in its turn is an array with 8 elements. This array consists of, It was found out that the metallux joystick used in the test bench did not always send the data expected on the bus. Sometimes the data would include instances where the DATA array would consist of only zeros for each element. These in- stances of zeros were ignored. 3.6.5.5 Simulation of boat movement In Unity image files can be imported as sprites which can be manipulated and rendered each frame. 52 3. Methodology Figure 3.38: .PNG of a boat, imported to Unity to be used as sprite In order to simulate the movement of a boat at sea, a sprite of a boat was used. In order to control the sprite, a 2DRigidbody was introduced as described in (Unity Technologies, 2020). This 2DRigidbody object then has lots of interesting properties that will be used later. This sprite could then be controlled in Unity through data from external devices such as the Metallux joystick, by the use of a c# script. The CAN data DATA array presented in figure 3.37, includes x-,y-, and z-vales which can be used to control the sprite. The values range from 0-31 depending on the position of the joystick. For making it easier to translate the joystick into a movement of the boat sprite, the range of the data was changed to instead be from -15 to 16. To simulate a somewhat realistic behaviour of the boat sprite when it travels through the water, simple fluid-dynamic equations were used. From fluid dynamics we know, Fd = 1/2ρv2CdA (3.1) which can be heavily simplified as, Fd = v2C (3.2) This simplification is based in that we no longer take the geometry of the boat into consideration when it is translating throughout the water in different directions. We have simplified 1/2ρ ∗A to C. This is not physically correct as A would change depending on what direction the boat translates, but it still works well enough the 53 3. Methodology simulate the slow down of a boat in this application. Since Fd in the simplified equation still depends on the speed of the boat v2, a gradual slow down will take place, and the magnitude of C can be used to decide how fast the slow down should be. As the boat sprite has the 2DRigidbody, 2DRIgidbody.AddForce(x,y) can be used to add a force in a certain direction and of a certain magnitude each frame. This is used throughout the code to update the position of the boat. The engines will put a certain force on the boat in the direction calculated from the CAN data, which will result in the boat moving through the water at a certain speed. Fd will meanwhile be applied in the opposite direction of the boats movement. This results in that, when the user stops manipulating the position of the boat through the joystick, the boat will slow down as if the force of Fd was continuously counteracting its movement. 3.6.5.6 LED ring communication After having understood the product, in section 3.2, as well as defined the means, in section 3.4, it was established that there could be of interest to communicate what direction the boat has compared to the direction the user moves the joystick and therefore tries to make the boat move to. As a boat on water has the aforemen- tioned behaviour of inertia, presented in section 3.6.5.5, the boat may move in one direction during a short time whilst a counteracting force slows it down and changes the direction of movement in accordance with the joystick position. In Unity each Rigidbody2D has a velocity property, Rigidbody2D.velocity() which according to the Unity manual (Unity Technologies, 2020) consists of a Vector2 with x- and y-values representing both the direction and magnitude of the velocity. As the vector from the joystick also comes in the form of a x- and y-value, one can do a simple check on the angle between each vector to determine weather the user is applying force in the direction of movement or in the opposite direction of movement. According to the Unity documentation one can calculate the angle between two vectors using Vector2.Angle(new Vector2, new Vector2). By using this function, with the first Vector2 as the velocity of the boat rigidbody, and the second the x- and y-values of the joystick data, the check can be performed and it can be determined if the user is pointing the joystick in the direction of velocity or not. This information can then be sent in the form of an integer to the Seeeduino, which displays the correct colour and direction on the LED ring. The LED ring consists of 24 individually addressable LED’s, where both color and brightness can be manipulated. It was decided that red color should be used for the case where the user is not pointing in the direction of movement, and green color should be used when the user is pointing in the direction of movement. To simplify the process of identifying directions and communicating data, the LED ring was divided into four quadrants with seven LED’s in each. The Unity code starts of by checking the direction of the joystick compered to the velocity of the boat, as explained above, if the angle is bigger than 90°, it is determined that the user is pointing the joystick away from the movement of the boat. A second check is done to determine if the angle is between, 0-45°, 45-135° or 135-180°, compared to a vector that always point forward from the boat. This in turn decides the direction the light should point. These two checks combined result in eight cases that can be sent to the Seeeduino. 54 3. Methodology Case one to four, the LED’s turn on with red color and in all directions as can be seen in figure 3.39. Figure 3.39: The different directions the LED ring can light up red. In case five to eight, the LED’s light up green in the four different directions, as can be seen in figure 3.40. Figure 3.40: The different directions the LED ring can light up red. As mentioned, each case is represented by a number from zero to eight. When Unity has decided what case should be activated, by use of the methods described above, the number of the decided case is sent in the form of a string to the seeeduino. The seeeduino then checks what number has been sent, and activated one of the cases presented in figure 3.39 and figure 3.40. In summary, Unity calculated what direction and color the LED’s should light up with, and send the information forward to the seeeduino. The seeduino in turn activates LED’s in accordance with the case that has been transmitted, both in regards to what LED’s to activate and what colour they should have. This is done every time the user changes direction of the joystick, or when the direction of the boats velocity change direction. 3.7 User studies methodology To be able to draw conclusions regarding activation types and different types of feedback, it was decided that user studies were to be carried out. The user studies 55 3. Methodology consisted of two parts, a test during which users operated the boat in the simulation described in section 3.6.5 whilst being observed, and a interview part where they evaluated the test bench in different regards. In order for the tests to not take too much time, it was decided that no combination of activation types would be tested at the same time. Three test users got to participate in the studies. Each one of the concepts described in section 3.4 were individually tested by the users. 3.7.1 User studies setup The user studies were carried out in an apartment with the test bench connected to a computer and the computer connected to a TV over HDMI. The user was placed in front of the TV with the test bench mounted on a separate chair in a height and placement as if it had been situated in the armrest of a chair, as can be seen in 4.3. Each user would also be filmed during the test in order to ease the user data collection. These recordings were later evaluated to retrieve the test data. 56 3. Methodology Figure 3.41: A test person during performing a user study. 3.7.2 User study - Observations As mentioned, the first part of the user study consisted of observing the user whilst taking notes. In addition, the user studies were performed in a constructed manner, as described in 2.3.4. As the studies aim to verify or reject hypothesis it is impor- tant that they are easy to replicate and carried out several times in the same manner. The route marked in 3.42 was used in each one of the user studies. The users were during the study asked to activate functions on the concept at hand whilst traversing the route. The numbers in figure 3.42 stands for the approximate position the users were told to activated a function. The functions were activated in the following order; 57 3. Methodology 1. Start the joystick 2. Activate Function 1 3. Activate High mode 4. Activate Joystick driving 5. Deactivate Joystick driving 6. Activate High mode 7. Deactivate High mode 8. Activate DPS Variations of what functions to activate at what time were carried out in order to change things up and keep the user concentrated and focused. Function 1 act as a template for an undisclosed functionality. Figure 3.42: The route that the users in the study were asked to drive. 3.7.3 User study - Interviews After each route, users were asked a set of questions which were the same for each user and each concept. The questions were as follows; • What did you think about the possibility of finding the correct activation surface? • What did you think about the possibility to activate the correct function? • What did you think about the possibility to determine if a function was acti- vated/deactivated? • What did you think about the possibility to determine what functions that currently are activated? • What was your over all impression? 58 3. Methodology 3.8 Comparing the remaining concepts to each other using kesselring matrices The interviews were followed by a comparison between the concepts using a kessel- ring matrix. Before this, it was concluded that not every concept needed to be evaluated in the kesselring matrices. Because the user scenarios varied a lot, not one activation type were deemed better than another in the user studies. Because of this, one concept for each activation type went through to the kesselring matrices. The concept that went through had both visual, auditive and haptic feedback. There were two excep- tions, both the touchscreen and the Penta joystick had only visual feedback, because of technical limitations. As explained in section 3.5, the user scenarios varied a lot. Because of this one kesselring matrix were done for each scenario. The factor that varied between the matrices were the weight of the different requirements. These different weighting will be presented in chapter 4. The result from the kesselring matrices was one winning concept for each user sce- nario. 3.9 Conclusion of methodology For this section it can be concluded that, a test bench has been developed in accor- dance with the product development process presented in figure 3.1. Furthermore, an explorative user study has been carried out. In addition, a framework for user studies as well as scenarios through which the data can be evaluated has also been developed. With this as a basis further user studies and analysis of the results can be carried out. 59 3. Methodology 60 4 Results In this chapter, the results from the project is presented. The chapter is commenced by a presentation of the test bench, after this, the results from the qualitative user studies are presented. The chapter is concluded by a presentation of the strongest concept for each user scenario. 4.1 Final test bench On of the main results from this project is the test bench test bench that has been developed and used in the user studies. Figure 4.1: A 3D model of the test bench. 61 4. Results Figure 4.2: The test bench. In difference to the existing test benches at CPAC, this test bench only incorporate the joystick, not the entire boat electronics, and is small and portable. If future development is d