Technologies for Connectivity: DBSU10 – World E group 04 – final report

Abstract With means of 2 challenges a collaborative module system was designed which used the OOCSI library to create a security system that would protect so called ‘infinity stones’. Challenge 1 was used to ideate and as a first iteration for a module design. Challenge 2 used modules from different teams to create a decentralized security system on the 6th floor of the Atlas building on the TU/e campus. Three different routes were created for outsiders to follow as a result unlock the system. Three corresponding maps were created for visual clearance and explanation on where, how and when to trigger each module. The results showed good visual communication via the maps and a fully working decentralized security system that used 5 trigger able and different modules that made use of 4 different sensors. The system would reset after 2 minutes, worked when 1 or 2 modules were not connected and would unlock when 1 of the 3 pre-programmed routes were followed

ACM Classification Keywords H.5.m. Information interfaces and presentation (e.g., HCI): Miscellaneous; See http://acm.org/about/class/1998 for the full list of ACM classifiers. This section is required.

Please do not modify this text block until you receive explicit instructions. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Permissions@acm.org. CONF '22, Jan 1 - Dec 31 2022, Authorberg. Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-xxxx-yyyy-z/zz/zz…$zz.00. unique doi string will go here

Koen Barten 1221456 University of Technology Eindhoven, the Netherlands Niek van den Berk 1234269 University of Technology Eindhoven, the Netherlands Dion Tjokroatmo 1234410 University of Technology Eindhoven, the Netherlands

Mathias Verheijden 1234306 University of Technology Eindhoven, the Netherlands

Introduction The course Technology for Connectivity (DBSU10) is all about gathering data in different ways. We from group E04 were given the space stone which is located in the Erilea world. The aim for this project is to gather data which is relevant in the area around the stone. In the Erilea world, the stone is located left next to the small kitchen on the sixth floor. Since the kitchen is in front of the entry, there are a lot of people and there is a lot of data which can be gathered from them. The data which is gathered during challenge 1 is the number of people around the kitchen. The thing we wanted to know was when there are people around the stone and at what times there are more people around than others. This data came in handy in the second challenge, where 5 different modules had to work together in order to protect the stones of the Erilea world.

Challenge 1 Concept & motivation It is chosen by the group to design a module and put it underneath a floor tile that is located close to the kitchen; the place where the stone was located. This module uses a pressure sensor to measure when a person is standing in front of the coffee machine. This module gives a clear and definite message to the server when a person is around the stone. That is why this was chosen as a good option to measure how crowded it is a specific time slots during the day.

While looking for an implementation of the module, one of the teammates found out that the tiles in front of the kitchen of Atlas floor 6 were partly removable. This finding ensured a good implementation place for the module. By placing the module underneath a floor tile it

would mean that the module would completely disappear in the environment. For this reason, the ‘Phantom Thief’, who is going to try to steal the stone, can hardly notice the module. People who walk in front of the kitchen are also not able to notice the module as it is minimally visible. This means that the behavior of people around our stone is not influenced, which leads to trustworthy data gathering. For example, when a person is walking on the pressure sensor, the time spent on this sensor and the way of standing is not influenced in any way. As a result, true data can be gathered with the pressure sensor of the module. This is one reason why the group chose a pressure sensor to use as a module.

The second important reason to choose this sensor was because of the formfactor. Pressure sensors are flat and thus can be located underneath a floor tile without relative elevation to the floor tiles. Next to that, this sensor only changes value when pressure is applied. The only way extra pressure is applied on the tile is when an object or person is standing on the tile. This means that no other variables can influence the data gathered. In comparison, sound sensors or vibration sensors could cause unreliable readings through other variables such as environmental sound or building vibration. Pressure sensors detect through direct contact which thus eliminates most other detection variables.

However, this is also a downside of the pressure sensor as it only detects a person standing directly on the pressure plate. Most pressure sensors are very small which lessens the change the sensor is going to pick up significant changes in pressure.

Technical specifications and description of module The kind of microcontroller used is an ESP32, since it works almost the same as an Arduino and it has an integrated wifi option. It is familiar and no extra wifi modules have to be bought. The kind of pressure sensor used is a square Taiwan Alpha Membrane pressure sensor with dimensions of 44mm x 44mm. It is dedicated to use this type since it has a much larger surface than the 18mm diameter round sensors.

To the ESP 32, the pressure sensor was added. Via single core cables and an additional resistor to ground, the sensor was attached to the ESP32 which was hidden in the cupboard. Of course, the ESP32 had to be powered. Fortunately, there was a power socket in the cupboard. Since this socket was already being used for the Quooker, it was decided to place a powerstrip to make sure no other devices needed to be plugged out.

API Outline Which data?: With the pressure plate placed under the floor tile, there will exist a constant pressure. Depending on the floor tile, a threshold was set that activated the system when exceeded. When triggered, the system would get the current date and time. This data was split into separate date and time. The time from 09:00 until 17:00 was divided into parts of 15 minutes creating a total of 36 parts. These parts were turned into an array of integers starting all with a value of 0. These integers were the counters. Each time the pressure plate was triggered, the current time was compared with the timeslots and a value of 1 was added to the corresponding counter. Then, the array was sent as a whole to the server so other groups can see the progress throughout the day. After a trigger, the plate would become inactive for 2 seconds to make

sure the server was not overloaded if someone stays on the plate for some time. After the day, data on the server showed how much activity was measured in each quarter of an hour.

The channel: Each group in the Erilea world was asked to create its own channel. The channel of group 4 was called “KitchenTrigger”. On this channel, an array of integers (counters) was sent, representing each quarter of an hour between 09:00 and 17:00. This array was updated each time the module was triggered.

Data format/types: The data found in the array looked like timeSlot[0] = 3, timeSlot[1]=5 etc., where timeSlot[0] represents 09:00 until 09:14, timeSlot[1] represents 09:15 until 09:19 etc. Therefore, our key was called ‘timeSlot[x]’ with x ranging from 0 to 35, and the value was a positive integer ranging from 0 to infinity.

Outcome challenge 1 With the API outline and module description described above, measurements were done for a period of 2 days to gather data and test whether the module would give interesting timing results we could use in challenge 2 to propose to the ‘Phantom thief’. Both days measurements were done from 9:00-16:45 as described by the assignment. The bars in the graphs of both days represent the activity of people triggering the module every 15 minutes. Therefore there are 36 bars as described in the API outline.

Figure 1: Challenge 1 module installation

Figure 2: Graph of the data from day 1

Figure 3: Graph of the data from day 2

As seen above, the 2 graphs below show some great similarities. The most interesting similarity are the peaks around 12:45 and the ‘dips’ around 11:30 and

13:30. The high peak of 96 at day 1, 12:45 is an indication that many people stood on the pressure plate either for a longer period of time or a lot of people visited the kitchen on floor 6. This was the same for day 2 at 12:15 (78) and thus shows a pattern where a lot of people are present at that time of the day on floor 6. The dips, however, at day 1: 11:15 (0), 13:30 (0), 14:00 (0) and day 2: 11:15 (1), 13:45 (0), 14:00 (2). Show that at these moments of the day least people visit the kitchen.

Furthermore, it can be noticed that there is a visitor increase in the morning during both days from 9:00-10:30 which indicates an increasing amount of people are visiting floor 6 in the morning. After 14:00 the differences between both days are largest. Whereas day 1 shows quite minimal activity and even a new dip around 15:00 (2). Day 2 shows more activity in the afternoon especially between 14:15 and 15:00. Around 15:30 (2) there is some minimal activity again, however the activity quickly increase after that as can be seen by the 16:15 time slot where 20 people triggered the module.

To conclude, for the ‘Phantom thief’ there are therefore two possible kind of times for stealing the stone. One is using the dips as a way to try to steal the stones. During 11:15 and 13:30 there will not be a lot of people around to notice the ‘Phantom thief’ stealing the stones. However, the ‘Phantom thief’ actions might stand out more if it is not busy in the space. Therefore we propose to steal the stones around the busiest peaks where there are a lot of people around and the ‘Phantom thief’ is able to blend in between the people very well.

Challenge 2 Concept and motivation of our module (4) As it was needed to collaborate with other groups to create a security system for the stones, it was not an option to keep our module underneath the floor tile. All the modules were all spread out, so together with all the other groups it was decided to place all the modules somewhat in the same area to walk a certain path. The kitchen, where our module was, was not as close to make it seem inconspicuous when people wanted to trigger it. Although our module was well hidden, we had to make it also applicable for different situations. This required the module, in the first place, to be mobile. After some further thoughts about the mobility of the box, which you can read below, it was decided to stick to the same static idea.

Adjustments to the prototype For the second challenge, no major changes were needed to be made for the prototype because the pressure sensor would be used again. What did change, was the location of it. During the first challenge, it had been placed under the tiles of the kitchen of Atlas floor 6. Because of this location, no one was able to recognize the prototype, which led to reliable outcomes because no one was stepping on the sensor on purpose. During challenge 2, the prototype was placed underneath a reservation note in between the boxes in the racks. This way people did not place anything on top of our sensor accidentally. A nice thing about this was that we could control the time and amount the sensor gets triggered. Another upside was that our electronics would be hidden underneath the shelves of the racks and that there was a socket behind the rack. As the sensor was placed on the shelves, it did not look suspicious if you, for example, placed a box on it.

Figure 4: New implementation of module 4

In the first place it was decided to place the module inside of the box, after which you can put something in it. This way the whole module could be hidden inside of the box underneath a double bottom. A downside of this is dat we needed a powerbank to make it work, as the box had to be mobile. The operating voltage range of the ESP32 is from 2.2V to 3.6V. The complete microcontroller however, had a built-in (3.3V) regulator that accepts voltages up to 5V. The downside however, was that the board only draws about 250 mA of current. This made it difficult to work with a power bank, since these had a certain current threshold, which made them turn off when not enough current was asked. By experience, we had learned that this was the case with the ESP32 board. This downside made us use a socket, so that is why we did not implement our module inside of the box.

Modules in the Erilea world (WORLD) The Erilea world located on Atlas floor 6 consisted of 5 modules that each used different sensors and different ways of triggering to eventually unlock the infinity stones, also placed on atlas floor 6. Some modules

were altered for challenge 2, just like our (group 4) module as described above.

In order to get a good glimpse of what the Erilea world used during challenge 2 to unlock the infinity stones, an overview of all the modules in the world will follow with an explanation on how to unlock each module.

GROUP 1 (BENCH):

Where?: The module of group 1 is placed in a bench next to the entrance of the floor 6 Industrial design space.

Trigger?:To trigger the module of group 1 the Phantom thief must sit on the bench for 3 times in a row within a time span of 15 seconds.

How?: This module uses a pressure sensor underneath the seating so it becomes invisible for other people and therefore fits into the environment very naturally.

GROUP 1 (PLANT POT):

Where?: The module of this group is inside a self made plant pot located on one of the right shelfs of the cabinet on Atlas floor 6.

Trigger?: Turn the plant pot 360 degrees on the shelf. So that it faces the same way as it did before to prevent it from triggering unexpectedly or falsely.

How?: The module is triggered by means of a PIR sensor that measures the presence or movement of an object in front of it. This could also be when the object itself is moved into a direction.

GROUP 3 (SIGN + BOX):

Where?: Thes sign and the box are located at the top middle shelf of the cabinet at Atlas floor 6.

Trigger?: The module is triggered when the box next to the sign is taken out for more than 3 seconds and put back in the same place as before.

How?: This module uses an ultrasonic sensor to measure movement in front of the sensor or change in presence of an object in front of the sign.

GROUP 4 (PAPER ROLL):

Where?: The paper roll is located on a high table in the middle of the space on Atlas floor 6

Trigger?: Get enough paper to rotate the roll once from the paper roll at an odd ending time (e.g.: 1:33PM or 2:45PM)

How?: This paper roll uses a gyroscope that is located on one end of the rotating shaft. The gyroscope will measure the rotation of the shaft when the paper is taken out and will, as a result, trigger the module.

Concept and motivation of the World project (WORLD) ROUTES Together with all the groups in the Erilea world 3 routes and 3 corresponding maps were created in order to create 3 possibilities of unlocking the infinity stones in our world. For this reason we needed to make sure that the Phantom Thief would be able to start with any of the three maps when no modules have been triggered. This meant a careful API plan had to be set up that would support this system.

Figure 5: Module group 1

Figure 6: Module group 2

Figure 7: Module group 3

Figure 8: Module group 5

Another logistical problem that was necessary in order to have 3 different routes working was the fact that all modules needed to be re-triggerable. This meant that for some modules that used objects to trigger, these objects needed to be placed in the same spot as before the module was triggered. Therefore our group (group 4), group 2 and group 3 needed to think of a way to do this. As a result, these groups came up with the idea to rotate the plant pot 360 degrees, put a box on the reserved spot and put it back (group 4) and take a box out of the shelf and put it back in the same place (group 3).

After these problems were identified and solved the routes were created. After some discussion the world settled upon the idea to create 3 different routes pf 5 modules where in each route another team would start. In this way it would be clear for the general security system which route was being walked and which the triggered module would have to communicate next. The three routes created were as follows (group numbers):

1. 4-5-1-2-3 2. 1-5-4-3-2 3. 2-4-3-1-5

Each module was triggered in the same way for each route to eliminate inconvenience and let the Phantom Thief start each route at any given point in time even if the system was resetted. As one can see, module 4, 1 and 5 are triggering one of the routes. This meant these modules needed to measure activity at all times which in the end these modules did.

MAPS After this, three different maps were created. These maps would create a visual of where the modules would be located and the corresponding route that must be walked. The technological aspects of these maps will be further explained in the API. In the first map, our module was triggered as the 1st module thus sending a signal to module 3.

Figure 9: Map of route 1

In the second map, our module was triggered as the 3rd module thus receiving a signal from module 5 and sending a signal to module 3.

Figure 10: Map of route 2

In the third map, our module was triggered as the 2nd module thus receiving a signal from module 2 and sending a signal to module 3.

Figure 11: Map of route 3

Central API outline (WORLD) For the security system of the world, the world came up with a decentralized system that would still work when a maximum of 1 module was not connected or would not respond. It was chosen for a maximum of 1 broken module in order to keep the security system safe enough.

As mentioned, there were three routes created for the world. The three modules that are first in one of the routes, are always measuring to be triggered. Once this happens, all modules stop measuring and a signal is sent to the next module in line. If this module is ‘alive’, it will send a signal back to the first module to indicate it is functioning where after it starts measuring. If the second module is not functioning, the first module does not receive a signal back, and therefore tells the 3rd module in the sequence to start measuring. This same workflow also counts for the rest of the modules in the sequence. Because of this, there is only one modules measuring at a time, which minimizes the possibility for errors.

During the sequence, an integer array of length 5 is sent to the world channel each time the status of a module changes. The array starts as [0, 0, 0, 0, 0], representing the order in the sequence. If a module sends a signal to indicate it is functioning (‘alive’), it replaces the 0 corresponding to its position in the sequence with -2. Then, when a module is correctly triggered, it replaces that -2 with its own group number. If a module, say module X, is not functioning correctly (‘not alive’), the previous module will replace the 0 corresponding to the position of module X with -1. If more than one module results in -1, the complete array/system is reset to 0.

Figure 12: Decentralized system schematic

The system explained above was developed by a small team existing out of members from each of the five groups of the world. Together they thought out how the system should function and how the modules should communicate. It was then decided to create a template code for the groups to use, where the communication part of the code would be pre-written. The writing of this template was done by Daan Wubs.

API outline group module MODULE API With the pressure plate placed on the shelf under the reserved poster, there would be no pressure. Still a quite high threshold was set to not trigger on light objects, but be purposely sensitive to heavy objects. When the threshold was exceeded, the system would be activated. When triggered, the system would send a signal to other potential modules according to the preset sequences:

SIGNAL key: “eA”

value: integer array: (int, int, int, int, int)

channel: “Erilea”

The (determination of the) content of this array was previously discussed in the central API outline.

DATA CANVAS

Figure 13: Data canvas schematic

1. Previous module (optional) 2. Module 4: ESP32 + Pressure sensor 3. OOCSI server A. Next module according to sequence B. Next module according to sequence (if A is not

working)

Outcomes As there was made a master code by another group which made sure all the modules worked as desired, there was no need for us to adjust the code from challenge 1. Instead, the code only needed to be filled in in the master code to make it work. The place of the module however, had to be changed. In the end all the modules worked as planned and the three routes could be successfully followed.

Module presentation On April fourth, a presentation was given by the Erilea World to present to the coaches how the modules were

working together. Next to that, the routes earlier described in this report were presented and also tried out by a member of a different world. Luckily, all modules worked perfectly fine because there was put a lot of time in it before the demoday. Because of this, the presentation was a big success.

Discussion During the first part of the project, the group looked for a creative way to gather data that would be trustworthy. Next to that, it needed to be ethically justified, so it was not allowed to go against morals. Examples of bad sensors would for instance be cameras or microphones that are recording constantly. Because a pressure sensor does not gather personal data, it is ethically justified. Therefore, it was not needed to ask people for permission. When there is no need to inform people about the test you are doing, they are not aware of it and act in a natural way instead of activating the sensor on purpose. This helped to make the data more reliable.

There is a downside to the data gathered. It does not give any insights about the reason behind the quantitative, objective outcomes. For this project, it was not necessary, but when doing measurements for user-research purposes, the designers would have to go into the field in order to talk to the users. This way, they can get to know the motives behind the data. For this project, it is only possible to speculate why it is way busier at some time slots than others, in the kitchen.

Another downside to the data gathered, is that it gave no real numbers about how many people visited the kitchen. This is due to the fact that the sensor got

triggered multiple times per person when he or she was standing there for more than two seconds. This is because the sensor could send a signal every two seconds when triggered. Because it is unknown how long the visits to the kitchen took, it is only possible to know at what time slots the kitchen was the most crowded.

Challenge 2 reflections Reflection Koen Barten Reflection Niek van den Berk Challenge 2 required a lot of communication and discussion about whether the right thing was done and who, out of the approximately 20 people in world E, would do what. This meant that meetings needed to be structured and some of the group members needed to take charge of what happened within the world. At first several routes had to be designed in order to use the modules in a variety of ways to unlock the stones. This meant that for all the groups it had to be clear what and how their new module would operate in challenge 2. For our group this meant that we had to change our ‘floor tile’ concept to something more reliable. Our floor tile concept would be prone to inaccurate triggerings of people other than the ‘phantom thief’. The change to another concept, I found quite difficult in terms of communication and needs of different students. At the point of changing the concepts within a world meeting our group was not complete which made it difficult for us to decide upon a new concept. Additionally, some groups did not need to think of a new concept whilst others did. Furthermore, some groups finished their concepts in time, whilst other didn’t This caused some discussion and frustration. In the end we as a group and world managed to divide tasks accordingly. I felt like I learned a lot from working in a bigger group as I

now recognized that more opinions give more problems and require better communication.

A very important learning point for me during challenge 2 was communication, visualisation and taking leadership. During challenge 2 I initiated to make videos of the routes to visualize and make clear for every group what or how their module would be used in the context of unlocking the stone. I recognized this leadership was needed and I felt like in the end this contributed a lot to the end result we, as a world, presented. Right before the presentation of challenge 2 I also took the lead in getting every world member present to participate in testing. I did not expect to learn this kind of coordination and leadership skill during this course but am very happy I did. I will definitely take this skill with me for next courses as I think leadership, coordination and communication skills can be applied to many different aspects of group work and design processes. Again, for challenge 2 I would’ve liked to have contributed more to the technical aspect of the overall module system. Right now, I only participated slightly but others were simply better and faster at designing the technical part of the system. I will explain more about this in my overall reflection.

Reflection Dion Tjokroatmo Challenge two was a bit less work for us as a group than challenge one. As our module worked properly during the first challenge, there was no need to finalize or adjust it. In short, communication and organization in our group went well. However, during challenge two we had to work closer together with all the other groups from world E. This required greater planning

and leadership. Next to the lectures, all the groups came together once or twice a week to discuss issues and to divide certain tasks. After all the meetings it was compromised for our group to change our module a bit, this ment our module had to be moved. We were a bit unhappy with this since our module was well hidden underneath a floor tile, but after some brainstorming it was decided our module could now be hidden underneath a reservation poster. Moving the module gave us no problems and we did not have to change something to the module at all.

Regarding the collaboration with the world, it went actually quite smooth, as we had someone in our world who liked programming, Daan. He made a master code which made sure all the modules would be connected if the codes of the individual modules were filled in. In the end, a couple of hours before the demo day, we all tested our modules and some groups had some little issues. Since we started testing in time, all the issues could be fixed before the demo day started. This resulted in a smooth and flawless presentation. Sometimes there were a bit of issues, for example when things were not shared on the Drive we made. But after asking it quickly, all the files were shared within short period of time. This way all the groups could work on their part and look at each other's work when stuck. Perhaps it was a bit inconvenient to work together with around twenty people. Sometimes a group did not show up, or only half of the group did. However, since most of the groups hang around on the sixth floor, there was always someone working on their module. Resulting in easy communication and people gave random thoughts on your module to improve it.

This made sure there was a nice atmosphere and everyone could say what they wanted.

Reflection Mathias Verheijden To start, I can say that I am very happy with the results from the second challenge. The module worked perfectly fine and there was good communication with the other groups. As mentioned in my first reflection and personal development plan, the (technical) communication would be my main focus within the second challenge.

My first contribution to this goal was to setup a “communication team”, existing out of one member from each team in the Erelia world, including myself. This immediately turned out to be a good idea, since the team quickly developed the complete communications concept for the world. Additionally, I proposed to create one template code for this concept that all groups could use. This would reduce the chance of using wrong variables etc. The template was eventually written by Daan from group E01, for which I have to give him a huge compliment. Being involved in the development of the communication system allowed me to integrate the material from the lectures into a real-world scenario, The emergent behavior that our system is based on for example, was explained by Dr. Tanir Ozcelebi during the 4th lecture.

Next to developing the main concept, I helped Daan finalizing the template and fixing some bugs. Since he has a software science background, understanding and contributing to his work taught me some new knowledge and tricks that will help me create better and more advanced code in future projects. Overall, this challenge helped me improving my technological

skills and I now fully understand the functionality and potential of the OOCSI system. It is knowledge that I am already using in my design research project (P3). It helped me to create a research prototype that otherwise would not have been possible. It is nice to see the immediate impact of the this course.

Apart from the technological developments I went through in the second challenge, I gained quite some experience in working in multidisciplinary teams. Different than the first challenge, this one required us to work with the whole world. The most interesting thing in my opinion, is the different approaches people use for the same problem. These approaches gave me new ideas and techniques to work with, but most importantly showed me that the ‘industrial design approach’ is definitely not always the best one. In short, the second challenge showed me the value of working in multidisciplinary teams.

Finally, in my first reflection I mentioned that I “wanted to work on engaging my group more in the development of the second module”. I’m happy to say that my group had a more pro-active mindset during the second part of the course. Their feedback was valuable and helped me to better reflect on the choices that we made for our module.