Project reflection

Introduction

As mentioned earlier about halfway through the project a paradigm shift occurred in which the goal of the project switched from designing a prototype to obtaining a more in-depth knowledge about the dynamics and parameters of the reforestation process such that the need for a robotic solution could indeed be confirmed. After this confirmation, the group worked on developing a user interface which can be used to control the robots and specify the desired reforestation parameters. This page gives further details about the pitfalls we encountered during the first stage of the project and lead to this paradigm shift. Furthermore, an identification of errors in judgment which were made during the project is described such that they can be avoided during future projects

The general information about the project can be found in PRE2017 4 Groep6.

Old formulation of the project

Old planning

Table 4: Preliminary planning for the project

Week number	Task	Person*
1
	Choose definitive subject	Collaborative effort of all members
	Define problem statement and objectives	David
	Define users	Adine
	Obtain user requirements	Gerben
	Work out typical use cases	Luc
	Define the milestones and deliverables	Maikel
	Define the approach of the problem	Collaborative effort of all members
	Search for relevant state-of-the-art (SotA) sources, categories: Modularity (Semi-) Autonomous cars Sensors for prospecting/evaluating ground Drilling/plowing/seeding mechanism Current Forestation combat methods	All divided into the subcategories: Maikel David Luc Gerben Adine
	Make project planning	Collaborative effort of all members
2
	Review user requirements and use cases	Collaborative effort of all members
	Finish collecting SotA articles and write SotA section	Each member for their respective subcategory
	Compile list of potential robot designs	Collaborative effort of all members
	Make some concept design sketches	Maikel
	Make a preliminary list of required parts	Gerben
	Define embedded software environment	Luc
	Preliminary elimination session for designs based on user requirements	Adine
	Start compiling list of design preferences/requirements/constraints	David
3
	Finish list of preferences/requirements/constraints	Adine
	Further eliminate designs due to constraints	Collaborative effort of all members
	Rank remaining designs and select a winner	Collaborative effort of all members
	Develop a building plan/schemata for the winner design	Gerben, Luc
	Start acquiring physical quantities for modelling design	Maikel, David
	Start with a simple model of some system parameters	Maikel, David
4
	Commence robot assembly according to highest priority of building schemata	Gerben, David
	Continue modelling/simulating	Maikel
	Start coding robot functionalities	Luc
	Catch up on documenting the wiki	Adine
5
	Continue robot assembly and coding	Gerben, David, Luc
	Continue modelling/simulating	Maikel
	Catch up on documenting the wiki	Collaborative effort of all members
6
	Continue robot assembly and coding	Gerben, Luc
	Test the first (few) finished sub-system(s) of the robot.	Collaborative effort of all members
	Finish modelling/simulating	Maikel, David
	Finish catching up on documenting the wiki	Collaborative effort of all members
7
	Finish robot assembly	Gerben
	Make concept designs for possible modules	Luc
	Make a draft for final presentation	Maikel, David, Adine
	Test the first (few) finished sub-system(s) of the robot.	Collaborative effort of all members
8
	Buffer time	Collaborative effort of all members
	Finish final presentation	Maikel, David, Adine
	Complete wiki	Gerben, Luc

^* The current division of task is a rough estimate for the next 7 weeks. New tasks may pop up or task division may be rotated, and is hence subject to change during the progress of the course.

Old problem approach

The problem will be approached by a design question. What is the best design for a robot to combat deforestation which will be build modular so that it can be implemented for other purposes with minor changes. The first 2 weeks the approach will primarily be sequential, as user analysis, use cases and requirements/preferences/constraints need to be done sequentially before the rest of the project can start. Once this is over, the project will run in a parallel fashion where building and modelling will happen simultaneously.

Old milestones & deliverables

Table 5: Milestones

Date	Accomplished
30-04-2018	SotA research done
03-05-2018	User analysis/use cases done
07-05-2018	Have a partially eliminated list of designs
10-05-2018	Pick final “winner” design
21-05-2018	Have the first working subsystem
25-05-2018	Finish modelling
31-05-2018	Have an operational prototype running with at least 2 subsystems
07-06-2018	Made several concepts for modules
11-06-2018	Presentation is finished
14-06-2018	Wiki is completely updated

Reflection

From the very first brainstorm about what the topic of our research would be, to the final presentation, this project has taken roughly nine weeks. During those nine weeks, a lot of research, 3-D modelling and interface design has been done. All this work was done based on certain decisions that have been made by the group members. The decision to no longer make a prototype, but focus on research instead, and the decision to scope in on the user interface instead of keeping the project zoomed out at the entire robot are two examples that spring to mind. By taking a look at the difficulties that arose during this project, we might improve the way we make decision for future projects.

The Necessity of the Project

One of the first steps in a project should always be a state of the art research, which fulfills two purposes. It reveals a retrospective overview of the level of technological sophistication on the related topics and it might provide hints as to what can yet be achieved. This latter purpose is of utmost importance, because there is usually a reason why something has not yet been researched. The first question one should ask themselves when the state of the art research returns that no research has been done in their topic of interest is: “Is my research going to be useful?” In other words,”would the end-product I have in mind be a desirable artifact in the real world?” If the answer to these questions is ‘no’, it means that there is no necessity for the project, meaning that it would be futile to carry out the project in the first place, as it will not contribute to society. During our project, this question sprang to mind a couple of times, even when we were already well over half-way with our research. Even though it was eventually unraveled that the robot would indeed have practical applications beyond the possibilities provided by current reforestation methods, this should have been a larger focus point during the outset of the project. Now, we investigated the necessity of the robot in parallel with setting up requirements for the robot and defining its context (users), additionally, when the latter was done, some preliminary designs were initialised, even though it was not yet confirmed that the prototype robot would indeed necessary. If the research into the usefulness of the robot had shown that the robot would not have any practical applications, all work on the preliminary designs would have been wasted. This means that for future projects the question ‘Is my research going to be useful?’ should be answered fully before starting research that is not needed to answer this first question.

The Focus of the Project

Right from the start, our ambition was to build a functioning prototype robot which could preferably drive, sample the soil and plant seeds. Over the first few weeks it became clear to us that this was way too ambitious for the few weeks this project would last, considering that research on the necessity of the robot had to be done before actually building it. Only in week six did we come to the conclusion that focusing on the user interface, and how the rangers would communicate with the robots, would be the best logical follow up of our in depth literature study, considering that building a complete prototype would no longer be achievable within the remaining time. Furthermore, it would be highly likely that if we had stuck to developing a prototype we would eventually have had to build an interface to control them, therefore building the interface is still very closely related to the goal of developing a reforestation robot for national parks. The lesson learned from this is that when designing, a concrete focus on one part or mechanism is more effective than a broad focus on the bigger picture, this is because developing a single component will result in a product with higher level of sophistication. If, on the other hand, a complete interacting end result is made consisting of multiple components, these individual components will not be as sophisticated and have a higher chance for failures to occur. Taking into the account that the final product would consist of the interplay of these components, a propagation of errors and failures due to the low-level sophisticated components would result in an end product of mediocre quality at most. Furthermore, in most literature research, things are only being developed one at a time, indicating that this is the best way to go. This, however, does not mean that the picture is to be disregarded when designing the one specific mechanism. You should still keep the bigger picture in mind, otherwise the combination of the designed mechanism with the rest might be a miss-match.

Deliverables and Milestones

As already highlighted, the initial goal of the project was far too ambitious for the given timespan, forcing us to adapt overtime and rethink what we truly wanted to deliver. A way this could have been prevented is by setting clearer milestones for ourselves. If we had made a planning which would specify what we wanted to be done each week, in combination with the time this would cost, we might have noticed that we had taken too much on our plate. Additionally, after we had recapped our final deliverable, from a prototype to a user interface, a clearer planning with deadlines per week would have been a useful addition. The last weeks most deadlines were set one week beforehand, meaning there was no clear path for the project to follow once a task had been accomplished, creating uncertainty. A clearer and more specific formulation of project milestones in the future would result in a more realisable deliverable.

Decision making errors

During many stages in the project decisions were made, which influence the direction and end target of the project. During the decision making process, many factors can cloud rational judgement and hence lead to a (rationally) inferior option being chosen over a better alternative (Robbins, Judge and Campbell, 2016) . Some of the noteworthy ones which are of relevant to our project are the halo effect, anchoring bias, confirmation bias, and risk aversion, which will be elaborated on below.

The halo effect, is the phenomena of taking a single characteristic of an individual and using that characteristic as the sole criterion to evaluate that individual. This cognitive bias was profoundly present during the first stage of the project, where we judged the capabilities of our groups solely on the composition of our majors. Comprising of students from software science, psychology & technology, mechanical engineering and applied physics, we thought this was an ideal team to build a prototype robot, hence influencing our initial decision for making a prototype. This bias can be overcome in future projects by compiling a list of team member competencies during the first meeting. In this way everyone of the group will know the strengths and weaknesses of the other and this can be used to make a better task division. By doing so some biases caused by the halo effect can be overturned. For example, if a student electrical engineering would say he is good at signal processing but horrible at calculating electrical circuits, it would be wise, if a prototype would be made as deliverable, to hand over this task to someone else. If no list of competencies would have been compiled, it would be most likely that said hypothetical electrical engineering student would have ended up getting the task of calculating and designing the required electrical circuit.

The anchoring bias is the tendency to rely on initial information when making decisions at a later point in time. This bias is for our project indirectly linked with the halo effect, as the halo effect caused us to opt for building a prototype, whereas the anchoring bias caused us to keeping this project goal even though it was unclear whether a robot was really necessary to solve the reforestation problem at hand. Therefore it was only after more than half of the project time had passed that we decided on abandoning this idea due to time constraints. For future projects it would be wise to appoint one group member as ‘the devil’s advocate’, who is to criticise any decision made unanimously, such that any decision is thought over twice before being implemented, therefore reducing the odds of an anchoring bias to have severe negative long lasting effects, as was in our case. Some of these critical questions to be asked would include: ‘What are the other reforestation methods?’; ‘Why would these not be sufficient?; ‘If so, would there be other alternatives besides a robot which could also improve on the current methods?’

The confirmation bias is the tendency to search for data which supports your claim, or to interpret data such that it supports your claim. In any decision making process like the one of “Is a robot really necessary or is it redundant?” one will tend to look for information which confirms that a robot is indeed necessary if one’s goal is to build a robot. Although eventually objective conclusions are reached based on criteria of biodiversity, degree of control, time consumption, resource intensivity, and economic costs, the initial search for information was subconsciously guided by the belief that robots are an omni-potential platform capable of outperforming humans in just about anything, albeit technology is yet to realise this potential. In future project this bias can be overcome by putting one group member in charge of independently evaluating the quality of the results that the other group members acquired, and where appropriately put doubts into words. In this way, any fact is double checked which increases objectivity of results and will hence reduce the magnitude of the confirmation bias. Also in case of scientific articles, a threshold value for the h-index could be agreed upon, such that is ensured that the article is from a reputable author.

Lastly risk aversion is the tendency of individuals to opt for a situation with lowest uncertainty, even if the situation with higher uncertainty could have a higher pay-off. The most intuitive example would be a choice between a guaranteed €10 or tossing a coin for €30. Even though the mathematical pay off of the coin toss is higher, most people would opt for the guaranteed €10 because it is a 100% probability of occuring. This effect was partly the reason as to why the weekly feedback was followed and indeed intensive research was done to verify if a robot was desired. If the feedback had not been followed and a prototype would have been built whereas it would have turned out that having a robot is redundant, we would have ended up with a failed project (yes, the prototype may have worked, but this is still a USE course so if the prototype has no place in the world, it is just a useless chunk of metal). This cognitive bias is probably most noteworthy because it can safely be said that it is the only one which had a positive contribution to our project. Although risk aversion is probably the least dangerous of all the biases, since it is made to lower the risk involved in decisions, and even to lead to a positive contribution of our project, its effects should preferably be contained to some extent. Risk aversion may have prevented us from being too ambitious with our project, but in the later stages of the project it may have also inhibited us in performance. Once it was established that a robot was a desirable artifact only 3 weeks were left. Although it would have most likely been possible to produce a physically working prototype with some primitive functionings, the choice was made to develop an interface. This is because many things could have gone wrong in developing the prototype, whereas the only issues arising from developing the interface are software/programming errors, which also certainly would have been the case when designing a prototype, besides mechanical and electronic failures.

To conclude, although some biases did influence our initial decision making processes and thereby the course of our project, these were eventually overcome as objective arguments were used to reach conclusions and formulate the next stage in the project. The only bias which was constantly present during the project was risk aversion. At times decisions were made not purely based on conclusions, but also based on the impeding time constraint of the nearing deadline. The most notable example of this being the switch from developing a prototype once it was established that a prototype is desirable to the aim of developing a user interface for the operation of the to-be-designed robots.