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
|Choose definitive subject||Collaborative effort of all members|
|Define problem statement and objectives||David|
|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:
||All divided into the subcategories: |
|Make project planning||Collaborative effort of all members|
|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|
|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|
|Commence robot assembly according to highest priority of building schemata||Gerben, David|
|Start coding robot functionalities||Luc|
|Catch up on documenting the wiki||Adine|
|Continue robot assembly and coding||Gerben, David, Luc|
|Catch up on documenting the wiki||Collaborative effort of all members|
|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|
|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|
|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
|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|
|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|
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 have 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 decisions 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 on 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 initialized, 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 a 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 over time 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 realizable deliverable.
Decision making errors
During many stages of 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 judgment 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 relevance 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 every one 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 keep 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 intensive, 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 a 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 the 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 the lowest uncertainty, even if the situation with higher uncertainty could have a higher payoff. 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 occurring. 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 impending 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.
- S.P. Robbins, T.A. Judge, & T.T. Campbell. (2016). Organizational Behavior, 2nd European edition. Pearson. ISBN 9781292016559.