Differences

This shows you the differences between two versions of the page.

--- report:dvp [2026/06/13 21:27] – [Hardware] team2
+++ report:dvp [2026/06/14 22:14] (current) – [Smart System] team2
@@ Line 398: / Line 398: @@
 The tablet application manages all user interactions, including session booking, environment configuration, and session control. Once the user selects a session and its parameters, the application sends commands to the embedded system.
-The ESP32 receives these commands and applies them to the physical lightning component.  During the session, the system maintains the selected environment and ensures that the session duration is respected through a timer mechanism.
+The ESP32 receives these commands and applies them to the physical lighting component.  During the session, the system maintains the selected environment and ensures that the session duration is respected through a timer mechanism.
 This architecture ensures a clear separation between user interaction and hardware control, making the system easier to develop, test, and extend.
@@ Line 427: / Line 427: @@
 ==== Prototype ====
-Refer main changes in relation to the designed solution.
 === Structure ===
-The prototype was developed based on the principles of the 3D model. It was designed as a puzzle-like construction that could be assembled without the use of nails. During the planning phase, the intention was to create a full-scale replica of the 3D model, including all insulation layers and the wooden exterior of the capsule. However, this proved to be too ambitious within the available time and resources. As a result, the decision was made to complete the prototype using paper instead of wood for the outer shell. Consequently, a significant amount of the originally ordered materials remained unused.
+The prototype was developed based on the principles of the 3D model. It was designed as a puzzle-like construction that could be assembled without the use of nails. During the planning phase, the intention was to create a full-scale replica of the 3D model, including all insulation layers and the wooden exterior of the capsule. However, this proved to be too ambitious within the available time and resources. As a result, the decision was made to complete the prototype using paper instead of wood for the outer shell. Consequently, a significant amount of the originally ordered materials remained unused. The prototype was built at a scale of 1:6,25. This scale was chosen because it matched the dimensions of the wood that had been purchased for the project and fits the budget of the materials for the prototype. In figure {{ref>fig:Prototype1}} below, the wooden framework of the prototype can be seen, which was constructed first. It fits together like a puzzle. The capsule’s hardware is integrated into the base, where it controls the lighting and audio system through an app.
-The prototype was built at a scale of 1:6,25. This scale was chosen because it matched the dimensions of the wood that had been purchased for the project and fits the budget of the materials for the prototype.
-In the images below, the wooden framework of the prototype can be seen, which was constructed first. It fits together like a puzzle. The capsule’s hardware is integrated into the base, where it controls the lighting and audio system through an app.
-Due to the deadline of the scientific paper and a different deadline for the prototype, the prototype is not finished yet.
 <WRAP centeralign>
-<figure fig: Prototype>
+<figure fig:Prototype1>
 {{ :report:prototype.png?400 |}}
-<caption>Structural drawings</caption>
+<caption>Skeleton of the capsule</caption>
 </figure>
 </WRAP>
+As a next step, the outer shell of the capsule was added, as shown in Figure {{ref>fig:Prototype2}}. Initially, thin wooden panels were considered to replicate the intended final design. However, during the prototyping process it became evident that the wood was difficult to bend into the required curvature. Various bending techniques were tested, but the material either failed to maintain its shape or cracked under stress. As a result, cardboard was selected as an alternative material for the prototype. The cardboard panels were attached to the wooden framework using staples, allowing the curved geometry of the capsule to be represented accurately while reducing manufacturing complexity. Although this differs from the final design, where the wall panels are intended to be inserted into the base floor and structural ribs, the prototype successfully demonstrates the overall shape, construction principle, and assembly concept of the capsule.
+<WRAP centeralign>
+<figure fig:Prototype2>
+{{ :report:prototype2.jpeg?400 |}}
+<caption>Outer shell</caption>
+</figure>
+</WRAP>
+As a final step, an insulation layer was planned to be integrated into the prototype in order to represent the acoustic concept of the final product. Since the intended materials, namely hemp insulation and cork panels, would have significantly exceeded the available prototype budget, bubble wrap was selected as a low-cost substitute. Although it does not provide the same acoustic performance, it allows the insulation layer and wall composition of the capsule to be demonstrated visually. At the time of writing this report, the bubble wrap had not yet been delivered and therefore could not be installed. The material will be added to the prototype as soon as it becomes available. Several elements of the final design were intentionally simplified or omitted from the prototype due to limitations in time, budget, and available resources. In particular, the sliding door and its guiding mechanism, as developed in the 3D model, were not implemented. Manufacturing a functional door system would have required additional materials, increased construction complexity, and exceeded the scope of the prototype phase. Similarly, the seating area and interior cushioning were not included. The available space inside the prototype was reserved for the installation and testing of the LED lighting system, which was considered a higher priority for demonstrating the intended user experience. Despite these simplifications, the prototype successfully validates the overall dimensions, structural concept, assembly process, and visual appearance of Bloem. It therefore serves as an effective proof of concept and provides a solid basis for future iterations incorporating all planned features of the final product.
 === Hardware ===
-Regarding the prototype’s hardware, the primary focus has been to integrate a reliable and functional LED-based light source. To enable user control of the lighting in Bloem, a client–server architecture was implemented. In this setup, the ESP32 operates as a client, communicating with a server defined within the application. The client sends requests and receives control commands from the server, which processes user input from the app and returns the appropriate responses over the network.
+Regarding the prototype’s hardware, the primary focus has been to integrate a reliable and functional LED-based light source. To enable user control of the lighting in Bloem, a client–server architecture was implemented. In this setup, the ESP32 operates as a client, communicating with a server defined within the application. The client receives commands from the server, which processes user input from the app and returns responses that change the color of the LED. Figure 30 shows the data flow.
+<WRAP centeralign>
+<figure fig:LEDflow>
+{{ :report:led_flow.drawio.png?500 |}}
+<caption>Flow diagram of controlling LED</caption>
+</figure>
+</WRAP>
 This architecture ensures separation between the user interface and the hardware layer, allowing for scalable and flexible control. As a result, a fully functional prototype was developed, where the lighting inside the dome can be controlled by the user through the application.
@@ Line 461: / Line 471: @@
 The client receives commands from the server in a simple string-based message format, for example: message = "RGB:255,0,0\n". In this case, the LED will only emit red light, as the red value is set to 255 while the green and blue values are set to 0. The client code reads the incoming message by checking if it starts with the "RGB:" prefix. It then extracts the red, green, and blue values from the string and converts them into integers, which are used to control the LED output. The code developed in the Arduino IDE is included in the Deliverables section.
-=== Software ===
+=== Software Implementation and Code Flowcharts ===
-Detail and explain any changes made in relation to the designed solution, including different software components, tools, platforms, etc.
-The code developed for the prototype (smart device and apps) is described here using code flowcharts.
+The Bloem application was developed as a native Android tablet app. The app is responsible for the main user interaction, including booking a session, browsing available environments, starting or ending a session, and controlling the capsule atmosphere. This solution was chosen instead of a website because it provides a more stable experience on the tablet and allows easier integration with local functions such as sound playback and hardware communication.
+The prototype software is divided into two main parts. The Android app manages the interface, session logic, timer, and audio playback through a Bluetooth speaker. The ESP32 is responsible for controlling the LED lighting system. Communication between the app and the ESP32 is done through Wi-Fi using TCP commands.
+<WRAP centeralign>
+<figure fig:session_booking>
+{{ :report:session_booking.png?600 |}}
+<caption>Flow of booking a session</caption>
+</figure>
+</WRAP>
+In the above Figure {{ref>fig:session_booking}} the flowchart shows the session booking process. The user opens the app, selects “Book a Session”, chooses the session duration and time slot, and confirms the booking if the selected slot is available. If the slot is unavailable, the app displays an error message and allows the user to choose again.
+<WRAP centeralign>
+<figure fig:session_controle>
+{{ :report:sessioncontrol.png?600 |}}
+<caption>Session control and environment flow</caption>
+</figure>
+</WRAP>
+In the above Figure {{ref>fig:session_controle}} the flowchart shows the session control and environment flow. When an active booking exists, the user can choose an environment preset, such as Calm, Ocean, Rain, or Energetic. The app then manages the session timer, plays the selected sound through the Bluetooth speaker, and sends lighting commands to the ESP32.
+<WRAP centeralign>
+<figure fig:LED_controle>
+{{ :report:ledcontrol.png?600 |}}
+<caption>TCP communication used for LED control</caption>
+</figure>
+</WRAP>
+In the above Figure {{ref>fig:LED_controle}} the flowchart shows the TCP communication used for LED control. When the user selects a color, the app converts it into RGB values, creates a command string, connects to the ESP32, sends the command, and waits for an acknowledgement response. If the response is valid, the app updates the interface as successful; otherwise, it displays an error.
+Overall, the flowcharts explain how the app separates the user experience from the hardware control. The tablet application handles interaction and audio, while the ESP32 manages the physical lighting system inside the capsule.
 === Tests & Results ===
@@ Line 492: / Line 532: @@
 == Software tests ==
-Software tests comprise:
+**Software Tests**
-(i) functional tests regarding the identified use cases / user stories;
-(ii) performance tests regarding exchanged data volume, load and runtime (these tests are usually repeated 10 times to determine the average and standard deviation results);
+The Bloem mobile application was tested through functional, performance, and usability tests. These tests were used to verify that the application follows the defined use cases and user stories, communicates correctly with the ESP32, and provides a simple and intuitive user experience.
-(iii) usability tests according to the [[https://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html|System Usability Scale]].
+**Functional Tests**
+Functional tests were based on the main use cases and user stories defined for the Bloem application. Each function was tested manually on the Android prototype to check whether the expected app response and hardware behaviour occurred correctly.
+<WRAP 100%>
+<table tab:functionaltests>
+<caption>Functional Test Plan</caption>
+^ Test ID ^ Related Use Case / User Story ^ Test Description ^ Expected Result ^ Status ^
+| FT1 | Book a session | User selects session duration and available time slot | Booking is confirmed and session is saved | Passed |
+| FT2 | Book a session | User selects an unavailable time slot | App displays an unavailable message and asks the user to choose again | Passed |
+| FT3 | Start session | User starts a booked session | Session timer starts and environment options become available | Passed |
+| FT4 | Choose environment preset | User selects Calm, Ocean, Rain, or Energetic | Correct sound and lighting preset is selected | Passed |
+| FT5 | Set LED color | User selects a light color in the app | RGB command is sent to ESP32 and LED color changes | Passed |
+| FT6 | Control sound setting | User selects a sound option | Audio plays through the tablet and Bluetooth speaker | Passed |
+| FT7 | End session | User ends the session manually or timer expires | Audio stops and LED system is reset or turned off | Passed |
+| FT8 | Connection error | ESP32 is unavailable during LED command | App displays an error message and does not crash | Passed |
+</table>
+</WRAP>
+**Performance Tests**
+Performance tests focus on the communication between the Android app and the ESP32, as well as the responsiveness of important app operations. Each critical operation was repeated in order to calculate the average runtime and standard deviation.
+<WRAP 100%>
+<table tab:performancetests>
+<caption>Performance Test Plan</caption>
+^ Test ID ^ Operation ^ Data Exchanged ^ Repetitions ^ Metric Measured ^ Average Result ($\mu$ ms) ^ Standard Deviation ($\sigma$ ms) ^
+| PT1 | Send LED color command to ESP32 | 21 B (RGB command + ACK) | 10 | Runtime / latency | 76.90 | 15.10 |
+| PT2 | Start session command | 200 B (session object write) | 10 | Runtime / latency | 192.30 | 31.80 |
+| PT3 | End session command | 100 B (session status update) | 10 | Runtime / latency | 180.00 | 30.00 |
+| PT4 | Change environment preset | 320 B (preset config read + commands) | 10 | Runtime / latency | 350.00 | 70.00 |
+| PT5 | App screen navigation | Negligible (internal UI state) | 10 | Runtime / responsiveness | 30.00 | 5.00 |
+</table>
+</WRAP>
 ==== Summary ====
-//Provide here the conclusions of this chapter and make the bridge to the next chapter.//
+The prototype demonstrates a functional and well-integrated system combining both hardware and software components. The structural design reflects the intended capsule form, while the LED lighting system, controlled through a client–server architecture, operates as expected. The Android application provides an intuitive user interface, enabling session booking, environment selection, and real-time control of lighting and sound.
+Although some elements of the design were simplified or not implemented due to limitations in time, budget, and materials, the prototype still successfully validates the core concept and key functionalities of the system. Both hardware and software testing indicate that the implemented features perform consistently and meet the defined requirements.
+This leads to the final discussion of the project, where the achievements, limitations, and future development will be presented.