GRUPPE6

As single households are on the rise, discussions about a loneliness epidemic was a serious subject before the pandemic, everything got worse with physical distancing. While the health risks of loneliness are difficult to quantify, the issue is real. While we are not designing a solution to the problem, we hope to have a product that helps people feel more connected and encouraging interaction.

The lighting of our product is super important as it is one of the key visual features. Therefore we wanted to utilize our LED's in an interesting fashion. We wanted our lighting to be dynamic when our product is blossoming, while also having the colors be defined by the user in NodeRed. What we came up with for our prototype is a function that smoothly changes between 2 colors that have been defined by the user. To accomplish this we had to go back to our color theory and use one of our favorite color models, HSV!

Since we are able to 3D print, CAD drawings have been used for rapid prototyping of the mechanism. Compared to cardboard mockups, this technique allowed us to limit the degrees of movement to the axes we are interested in. The chosen principle of combining a winch with levers is an intricate solution that benefits from precision techniques. A base plate mounted on the chassis holds the arms and guides the fishing line through control hoops. These serve the purpose of having the force more or less aligned with the plane of motion of these aforementioned arms.

After we had settled on the mechanical, 3D printed and electrical component we had to make a "casing" everything could be mounted on. To make it as small as possible, wires and legs on electrical components were cut and LEGO components where replaced with shorter ones. The prototyping started with testing different kinds of placement for the all the components and different kinds of structures for the casing which was made rapidly out of cardboard to test the ideas. The microswitches were especially difficult to place in a way the switches would be turned on when the plate was about to rotate too much.

After extensive testing of all the components, the electronics was ready to be reduced into a smaller workspace to better fit inside our product. We managed to fit it all on a half-sized breadboard. The electronics runs through a single 12 V DC-power supply making it easy plug and use as no other cables are needed to power on the device. The 12 V power supply is connected directly to the stepper motor and it’s driver and stepped down to 5 V to power the NodeMCU, sensor and LED strips. Our product does not require any batteries, just the power supply plugged in to the wall.

The companionship sculpture is coming together nicely, which led some room to investigate how to further heighten the user experience. We wanted the lamp to be functional even when the partner lamp was not activated, and at the same time take advantage of some of the cool features that is made possible through Node-RED. 

In our last post about the petals, we managed to work up a solution with individual petals and a central bud that would house the lights. There were two small wrinkles in the soup with this concept, on the aesthetic front it looks a little too cute for our tastes, and more importantly the midribs add additional weight. Neither of those problems are huge, but the hope of a weight reduction led us back to some of our early paper-folding tests. These tests were abandoned at the time, since our mood board led us in a different direction.

With a deadline coming up and after some time concentrating on the mechanism and code of the product it was time to take another look at the shape of the flower. If this were an Industrial Design course or a real development of a product we would have decided the exact shape and visualization before the mechanics and coding of the product. But this is a mechatronics course and time is very limited so we have to prioritize mechanics and electronics. It doesn't mean we have to black box the shape of the flower completely.

The mechanism finally works! The prototype can now successfully lift the arbitrary target weight when connected to the stepper motor. Overnight, the 3D-printer has been producing new parts for the new generation prototype.

For the last couple of days we have been working on getting the product to work as intended. Wednesday that culminated in two working prototypes that share the same code base. We have gotten this to work with only the LED's and the radar so far. We have structured the code in such a way that every stage of the flowers cycle runs correctly. When we get the mechanism to work and figure out where the LED's are gonna be placed, the coding of the LED's specific patterns can start. 

Tuesday day marked an important milestone, since it was time for design review 2. We were teamed up with Group 1, who are designing an arcade like basketball game. Each group started with a small presentation of their process so far, and afterwards the other group joined in and discussed the project. It turned out that some parts of our projects were somewhat similar, in terms of making stepper motors work when weight is applied, and creating multiple users via Node-RED. This opens an opportunity for knowledge sharing later on in the project, if one of our groups happen to get stuck. At this point in the process both of our groups are in a good work flow, so the meeting was mostly a sharing of experiences, and not so much answering questions.

One of the conclusions from the last prototype was that we need a gearing in order to lift more weight than just the arms. As per TA-recommendation, Tuesday we got our hands on some LEGO Technic. With the LEGO-parts we built a few different “gear boxes” to try out. They had different gearing and different placement of the motor axle, vertical or horizontal.

It’s time to crawl up from the deep hole that is Node-RED, and give you all an update on what is going on. We have been working on developing the coding for the minimum viable product, and in relation to this we made a coding playbook for all flows that are under construction.

To make sure the development teams are able to work together, we have to know what we are making. Since the work is split up into Arduino and NodeRed it can be difficult to keep track of how they communicate with each other. These problems were anticipated so we made a document to address the issue. In this document we have outlined all the functions of our product and how they will communicate with each other. We have split up all the core functionality into Arduino and NodeRed related functions. With this document we know what the core functionality for the MVP is.

Since the rods had proven to be a poor mechanical choice for pulling the arms we wanted to go back to developing the idea of having strings that pull the arms up. The problems in the last cardboard mock-up we had made was that the arms didn’t always move simultaneously and they leaned in all different directions when they were at the top. Also, the system required a lot of rotational force as soon as we added some weight to the arms - or petals. Our hypothesis was that if we made a higher fidelity model with 3D-printed parts that had less clearance, the arms would move more evenly and maybe the system could handle more weight.

We decided to investigate the solution space of the blossom mechanism due to our concerns about the previous mock up. The main concerns about the mechanism was that the rods could get stuck and jam on the way down as well as some concerns about the stability of the model. After some quick brainstorming and ideation we came up with a solution were we changed the strings of the mechanism to stiff rods. This was thought to prevent the rods of the flower to get stuck on the way down as they would be forced down. 

The objective of the test was to lower the distance of the PIR-sensor, so that we could have two sensor inputs to our code, one that registers when a person is in the room and one that registers if a person is close to the product. After a bit of googling and youtube videos, the most reasonable solution seemed to be that it was possible to lower the distance of the RCWL-0516 sensor by soldering a resistor to the R-GN plates.

Next step in the Arduino process was to set up two-way communication. Product A has buttons and an LED-strip and Product B has buttons and an LED-strip. The buttons on Product A control the LEDs on Product B, and vice versa.

The time has come to brush off our MQTT and MCU-knowledge. We have spent some time setting up a basic communication between two MCUs. We believe that a good first step to setting up the communication is to do so without involving NodeRed, but directly via the MQTT-server. 

Things are starting to look more floral. Yesterday, we initialized the process of prototyping the layered petals.The very first mock-up consisted of kitchen towel, skewers and hot glue. Without too much thought, we wanted to see how the petals could be connected and unfold. In this quick and dirty mock-up, we glued together several alternating layers of two types of kitchen roll + skewers. The layers looked sort of like kites but flexible in the center.

Once upon a time, seven students from D&I had been excited to start on course 41041, slide rules in hand, dxf and gcode on their trusty USB’s. Everyone excited and ready for the Lab of the Sky.Alas, when the time finally came to laser cut and 3D print, the crowned plague struck, forcing our unlikely heroes into lockdown. Virtual lectures, virtual meetings, virtual prototyping and everything changed. Our heroes almost lost their pluck. They had hoped in vain, that Skylab would be open for this final battle of the three weeks. Very sad. 

The stepper motor is up and running! For our first test we tried using the steppe motor driver from the Arduino kit, however it wasn't compatible with our stepper motor. Very sad. We then built our own using the L293D chip, which utilizes two H-bridges, as driver from the Arduino kit. The H-bridge can be used make the steppe motor rotate clockwise and counter clockwise, depending on how the coils in the stepper motor is energized. After a while of use, the driver got very warm! So warm that you'd burn yourself and possibly wear materials around it. The reason the chip got warm is because of the voltage drop inside the chip.

Finally, the apartment floor is covered with cardboard clippings and glue stains. The mock-up process has begun!We needed a proof of concept for our opening mechanism. All we needed for this was cardboard, straws, skewers, toothpicks, string, hot glue and duct tape. We had a rough idea for the mechanism beforehand. This idea was a rotating disc with several connecting strings equally distributed around the disc. These strings should be connected on the other end to rods that rotate around an axis in the bottom end of the rod. When the disc rotates, it pulls on the strings which pull on the rods, lifting them. Gravity pulls the rods back down.

For our project, we want to use a sensor to detect if a person is sitting in front of our companionship sculpture. For this we are using the sensor RCWL-0516.We set up the sensor with Arduino and breadboard. Using an LED as indicator to light when the sensor detects a person or object moving. Our 1 st test was successful, and the radar sensor picked up movement both from the front, and behind of the sensor. However, finding out the range of the sensor is about 7 meters, the range of which it detects a person is too far, so we worked on how to decrease the range.

After our morning meeting, we divided into subgroups. One of the things we worked on early in the day was a discussion of the core functionalities of the product. The functionality of the product is created in interaction with four different actors: the user, their sculpture, the NodeRed and their partners sculpture. We brainstormed different ideas on functionality linked to each actor, and quickly sketched a flowchart for minimum viable product. 

This morning we discussed different mechanisms. One candidate was a spindle, either driving a vertical motion with a nut-in-a-rack, or using the spindle with pinions to create an up-down rotation aligned with the central axis, the idea being that we could simulate leaves blooming. The problem with the latter is that the level of complexity would rise fairly quickly as more leaves are added, and more generally that the motions might look really stiff on their own. This stiffness can of course be mediated by the software, tweening the motor action in and out.

Today was the first day we physically met as a group, which was a delight! The day started with preparing for Design Review 1. In the review we presented our progress so far and discussed the possible challenges lying ahead of us. Details on review takeaways along with the initial progress follows.

We are back! This is the first day of the three-week period where we over the course of 15 days will bring the Companion Sculpture from an idea in our heads to reality. Or well, as close to as we can.We already have in place a rough product description, component list, some sketches, a moodboard and a function-means tree.

The final touches of Project 2 have been made, and we now turn our full attention to the final project - Project 3! In this project we will develop a product that makes use of the new market opportunities that appear along with the global Corona lockdown situation. It should be an IoT “Smart Product” that satisfies one or several needs created by the corona lockdown. 

The moment has finally arrived! It is time to reveal the result of what we have been working on for many weeks now, an interactive locker that fits into the environment at DTU!

An app has been developed to integrate the locker in the IoT. Nodred, MQTT and Arduino has been used to make a functioning prototype. It all works by sending information back and forth between the MCU and Nodered to keep them both "in the know" about what is going on. Mostly this is used to make sure one form of entry will be disabled by the other. When the user decides on which form of entry they will use they will communicate. Fx, if the user chooses to use the NFC sensor on the front of the locker, the NodeMCU will send a command, via MQTT, to the Nodered telling it that the locker has been RFID-locked. This is now displayed in the app so that future users can see that the locker is occupied.

The process started out with a brief discussion about requirements in terms of wants and needs, that quickly turned into a sketching session. Ideas were explored, elaborated and changed until something feasible started taking shape.

To best make use of our manpower, we decided to split up into smaller groups and let each group work on a part of the code. One group was in charge of the NodeRed (signup/login of the locker using username and password), another group was in charge of the weather function and the OLED-screen, and the final group was in charge of the RFID code. When the weather/OLED code and the RFID-code was finished, we decided to merge these codes, and clean up.

We worked on how to compare the login username/password with the earlier chosen signup username/password. First of all - how to save the username and password as global variables? We use a function node to save the output from the sign up form (msg.payload.navn and msg.payload.kode) under a global variable each. This global variable can later be used in another function node, after the login node, to compare the output from the login node with the username and password variables. If they are the same, an ”ok” message will be sent to the MCU, and the lock can be opened. If not, the login app will send a message that the username or password is invalid/incorrect.

Work on the RFID system is done! It began by fishing the MFRC522 out of the kit box, installing the library of the same name and running the example codes to work backwards from there. First point of order was to see how much info could be extracted from student ID cards and of course, credit cards. Luckily we were only able to get the unique and very much read-only UID's from these types of cards with the rest of the information nice and unavailable.

Our two sub-groups have finally gathered to make a IoT smart locker, what follows is the summary of our two initial meetings and our division of labor so far. What we want is a lock that can be interacted with by either an online app or a RFID of for example a DTU student card, to lock the cabinet for X hours. The state of the locker should then be displayed on an OLED user interface, that idles on a weather forecast.

Our very first post on this project blog for our project for 41030 Mechatronics Engineering Design F20. This project centers around the Arduino platform, which is an open-source electronics platform with easy to use hardware with an accessible programming language. We are a team of 7 from Design & Innovation and Electrotechnology respectively, looking forward to develop the project over the next 12 weeks and the following 3 week period.