**This is an old revision of the document!**
Project Development
Introduction
This chapter outlines the project's evolution, beginning with the initial ideation phase for both the team and the product. After establishing the core concept, including its physical structure, smart systems, and packaging, the focus shifts to the prototyping stage. Here, we detail the key hardware and software adjustments made to the original design, concluding with an analysis of the test results and final performance.
Ideation
The first Ideation of the team idea can be found on Figure 1
Here the team already had the idea of keeping the components on the bottom of the bottle, but a more square bottle was kept in mind with a handle that would be comfortable for the user's hand.
The second ideation of TRAQUA already has a more “classic” bottle shape 2.
For the third design, the team tried to come up with a concept that would either easy fold or just fit inside a backpack very easily. This was quite hard to accomplish, not because of the design but more in terms of the electronic components. It would be very hard to put them into the bottle if the bottle were shaped like in FIGURE 3.
Flyers
The team also had a few changes in their flyer before coming up with the definite solution. Below we will explore the different flyers the TRAQUA design team came up with.
The team's first flyer had no QR code; the text idea was already there, but the text just lies in boxes that feel out of place alongside the TRAQUA water bottle 4.
Choice of the subject
Immediately following the initial presentation, the group gathered to evaluate the proposed project tracks and reach a consensus. Our approach was rooted in an open brainstorming session where we weighed our individual strengths against the potential of each topic. It quickly became clear that the “Smartification of Objects” was the path that generated the most genuine enthusiasm among us.
More specifically, we decided to focus on a smart water bottle. This choice wasn't just based on personal interest; after conducting a preliminary market analysis, we identified a significant gap in the current landscape. We felt we could differentiate our product by consolidating multiple features and services into a single, cohesive solution. This sense of opportunity, combined with the fact that every team member felt comfortable and motivated by the technical challenges involved, made the smart bottle the definitive choice for our project.
Brainstorming
Once we settled on the smartification of objects, specifically the smart water bottle, the team held its first dedicated brainstorming session. Because the potential features for a “smart” container are so vast, we needed a way to filter the noise and focus on what actually added value. We turned to Miro to map out these early thoughts, using the boards shown to organize our ideas into functional clusters. This collaborative space was essential not just for tracking our suggestions, but for refining a set of concepts that eventually became the foundation of our final proposal. Figure 5 represents one of the brainstorming activities we did in Miro.
Design Thinking
Figures 6, 7 and 8 showcase the result of the initial brainstorming sessions conducted as part of the Design Thinking process.
Concept
The primary function of the smart bottle is to encourage consistent and healthy water consumption while, in the meantime, eliminating the hygiene concerns commonly associated with reusable water bottles. To achieve this, the bottle integrates five core features into a single device
First, a built-in UV-C sterilization module automatically disinfects the water and the interior surface of the bottle at regular intervals, removing the need for frequent manual cleaning and reducing bacterial buildup. Second, a temperature sensor continuously monitors the drink's temperature and makes this data available to the user in real time. Third, a hydration tracking system records water intake throughout the day and sends customizable reminders when the user falls behind their hydration goal.
All sensor data is transmitted via Bluetooth to a companion mobile application that serves as the central interface for the end user. The app displays all key aspects mentioned above. . This ensures that the user remains actively involved in managing their hydration while the bottle handles the more technical tasks autonomously.
The bottle will be prices at approximately 330 €. For mass production the team could look to reduce the production price up to 100 € per bottle. Meaning the end price of the bottle would be around 250 €.
Design
Structure
Figure 9 illustrates the initial structural draft of the product concept. The sketches explore the basic 3-piece concept.
The design contains the main body, which serves as the holder for the water. The top, a removable cap. The cap design also ensures the product can be safely transported without leakage or contamination. A filter integrated at the nozzle is proposed, indicating that the product may be used for dispensing liquids while controlling flow or removing particles.
Last, the bottom part that holds all the components.
The sketch also demonstrated how the different parts are assembled together, showing connection points and structural alignments.
Overall, these drafts focus on defining the product’s core structure, usability, and functional components before moving into more detailed design stages.
To ensure a coherent and professional presentation of the project, a visual identity was established for TRAQUA. This identity provides consistency across all project deliverables, including the report, presentation, and prototype interfaces.
Logo: The TRAQUA logo combines a water droplet icon with the project name, reflecting the system's core focus on water quality monitoring.
Tagline: “Know your water, trust your bottle.” — summarizing the project's goal of giving users reliable, real-time insight into their water quality.
Color Palette (Monochrome): Three colors form the visual foundation:
#6377BD— primary dark blue, used for headings and key UI elements#D0E3FF— light blue, used for backgrounds and secondary elements#FFF9F0— off-white, used for neutral backgrounds and contrast
Typography: The project uses the Big Shoulders font family, chosen for its clean, technical aesthetic that aligns with the engineering nature of the product.
(ii) material selection; (iii) detailed drawings;
(iv) 3D model with load and stress analysis; (v) colour palette.
Smart System
Hardware
Figure 19 This is a system architecture/block diagram for a smart water bottle. At the core is an ESP32 DEVKIT V1 microcontroller that connects to several peripherals: an LED light, accelerometer (LIS3DHTR), TDS sensor (SEN0244), UV-C light, and a pressure sensor (FSR406) with a capacitor. Power is supplied by a battery through a charging circuit. The ESP32 communicates with a mobile application over BLE (encrypted + bonded) using notify/read/write operations. The legend color-codes the lines: red for energy, green for information, and blue for water-related connections.
Figure 20 presents the initial electronic system architecture of the smart bottle prototype. The diagram outlines the integration of the main components and their interactions, serving as a first iteration of the system design. At the core of the system is the ESP32 microcontroller, which manages data processing and communication between all connected components. Several sensors are included to support the intended functionality of the product. A TDS sensor is used to measure water quality, while a temperature and humidity sensor (DHT11) monitors environmental conditions. Additionally, a motion sensor and a force-sensitive resistor (FSR) are incorporated to detect user interaction and usage patterns.
The system also includes a UV-C light module, controlled via a transistor circuit, which is intended for sterilization purposes. A display module (SSD1306) is connected via I²C to provide real-time feedback to the user.
Power is supplied through a battery management system (BMS) connected to multiple lithium-ion cells. Voltage regulation is handled by a boost converter and linear regulator to provide stable 5V and 3.3V outputs required by different components. A USB-C interface is included for charging.
It is important to note that this design represents an initial draft, created to explore component selection and system integration. Certain aspects, such as power efficiency, component optimization, and circuit simplification, will be revised in later iterations.
To ensure the system operates reliably, a power budget was established for all electronic components. The table below outlines the voltage, normal and maximum current draw, and resulting power consumption for each component.21
(iv) power budget.
Software
The following sub chapter will introduce and explain the reason why TRAQUA decided to program the application system the way it is, talk about its components and the tools used to do it.
Figure 22 we can see an easy entry flow of how the application works. The application was made with one key concept in mind. Keep most of the “important” values one click away. With that mindset in mind. The application works in the following way. If the users log in for the first time, they enter their height and weight. This will help us determine how much water that person needs to intake per day. Then with 1 click that person can see the water purity and his or her total water intake. He can also start the cleaning process from the app by clicking on the navigation menu on the bottom of the app.
Figure 23 This is a Level 1 Data Flow Diagram (DFD) for a hydration tracking system. It shows an external entity (Water bottle) sending raw readings to a Sensors process (1.0), which passes data to a Process Data process (1.5). That process sends processed data to a Data store, which feeds into a Display on app process (2.0) that delivers hydration info to the User external entity. There's also a legend in the bottom-left defining the DFD notation (rectangles for external entities, circles for processes, open rectangles for data stores).
Software choices
The system consists of four main components. A mobile application, a web application a backend service and an embedded device based on ESP32
- Mobile Application
The application was developed using EXPO Go, a framework built on top of React Native. The choice was made due to its rapid development capacity, its cross-platform support (iOS and Android), its ease of testing without the requirement of complex native configuration, and the fewer risks of vulnerabilities that React has. Expo Go also enables efficient prototyping and provides access to device features such as Bluetooth, which is essential for communicating with the ESP32.
- Web application
Link to website: https://alvesbernardo.github.io/TRAQUA/
The shop of TRAQUA. This was done using SVELTE. SVELETE was chosen because of its lightweight nature, fast performance, and simple reactive model. Unlike traditional frameworks, Svelte compiles components at build time, resulting in highly optimized and efficient code
Figure 24, Figure 25, Figure 26, Figure 27, Figure 28 are screenshots of the website
- Backend
The backend is planned to be developed using Python in combination with FASTAPI. Due to its simplicity, readability and extensive ecosystem. The backend is responsible for handling business logic, data storage, and communication between the web application and other system components.
- ESP32 The system uses an ESP32 microcontroller, which is well-suited for IoT applications due to its low cost, built-in Wi-Fi and Bluetooth capabilities, and sufficient processing power. The ESP32 is responsible for interacting with hardware components and executing real-time tasks while communicating with the mobile application.
- Communication Communication between the mobile application and the ESP32 is established using Bluetooth Low Energy (BLE). BLE was selected because it is energy-efficient, widely supported, and ideal for short-range communication between devices
- Security Considerations
Security is an important aspect of the system, particularly in Bluetooth communication. To ensure secure data exchange, several measures are implemented:
Secure pairing and bonding between devices Encryption of Bluetooth communication to prevent interception Authentication mechanisms to restrict unauthorized access Input validation across all components (mobile app, backend, and ESP32)
Additionally, secure development practices are followed in both the frontend and backend to minimize potential vulnerabilities.
Comparing Mobile framework
| Criteria | Expo Go (React Native) | Flutter | Native (Swift/Kotlin) |
|---|---|---|---|
| Cross-platform | iOS + Android from one codebase | iOS + Android from one codebase | Separate codebases needed |
| BLE Support | Yes (expo-ble / react-native-ble-plx) | Yes (flutter_blue) | Full native BLE APIs |
| Development Speed | Fast — hot reload, JS/TS | Fast — hot reload, Dart | Slower — two separate apps |
| Testing/Prototyping | Very easy — scan QR to test | Requires emulator or device build | Requires full build per platform |
| Community/Ecosystem | Large (React/JS ecosystem) | Growing rapidly | Mature but platform-specific |
| Learning Curve | Low (JS/TS knowledge) | Medium (Dart) | High (two languages) |
| Chosen | Yes | No | No |
Web Framework
| Criteria | Svelte | React | Vue |
|---|---|---|---|
| Bundle Size | Very small (compile-time) | Larger (virtual DOM runtime) | Medium |
| Performance | High — no virtual DOM overhead | Good — virtual DOM diffing | Good |
| Learning Curve | Low — simple reactive model | Medium — JSX, hooks, state mgmt | Low-Medium |
| Build Output | Highly optimized vanilla JS | Requires runtime library | Requires runtime library |
| Community | Smaller but growing | Largest | Large |
| Chosen | Yes | No | No |
Backend Framework
| Criteria | FastAPI (Python) | Django (Python) | Express (Node.js) |
|---|---|---|---|
| Performance | High — async, built on Starlette | Moderate — synchronous by default | High — async, event-driven |
| API Development | Built for APIs — auto Swagger docs | Heavier (DRF needed) | Flexible but manual setup |
| Learning Curve | Low | Medium (opinionated, ORM, admin) | Low |
| Data Validation | Built-in (Pydantic) | Manual or via serializers | Manual or via libraries |
| Ecosystem | Growing | Very mature | Very large (JS ecosystem) |
| Chosen | Yes | No | No |
Microcontroller
| Criteria | ESP32 | Arduino Uno | Raspberry Pi Pico |
|---|---|---|---|
| Wi-Fi | Built-in | No (shield needed) | Pico W only |
| Bluetooth/BLE | Built-in | No (module needed) | Pico W has BLE |
| Processing Power | Dual-core 240 MHz | Single-core 16 MHz | Dual-core 133 MHz |
| Cost | Low (~5-8 €) | Low (~5 €) | Low (~4-6 €) |
| GPIO Pins | 34 | 14 digital, 6 analog | 26 |
| IoT Suitability | Excellent — designed for IoT | Limited — no wireless | Good but less mature |
| Chosen | Yes | No | No |
Below you can find a detailed use case explanation of how the user interacts with the system. Our user being the actor in this case. Figure 29 …
Packaging
Present and explain the: (i) initial packaging drafts; (ii) detailed drawings; (iii) 3D model with load and stress analysis, if applicable.
Prototype
For the prototype, we use a rigid plastic bottle as the main structure. This material is easy to obtain, lightweight, and resistant, making it suitable for testing our concept. Inside the bottle, we add aluminum foil sheets. The aluminum acts as a reflective surface, allowing the UV-C light emitted by the LED to be reflected throughout the interior of the bottle. This improves the distribution of the light and increases the efficiency of the water disinfection process. We also include a plastic separator at the bottom of the bottle to protect the electronic components. This separator isolates the battery, sensors, and LED from direct contact with the water, ensuring safety and proper functioning during testing. This simple prototype allows us to validate the concept and test the performance of the UV-C cleaning system before developing the final product.
Refer main changes in relation to the designed solution.
Structure
Detail and explain any changes made in relation to the designed solution, including structural downscaling, different materials, parts, etc.
Hardware
Detail and explain any change made in relation to the designed solution. In case there are changes regarding the hardware, present the detailed schematics of the prototype.
Software
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.
Tests & Results
Hardware tests
Perform the hardware tests specified in Tests. These results are usually presented in the form of tables with two columns: Functionality and Test Result (Pass/Fail).
Software tests
Software tests comprise: (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); (iii) usability tests according to the System Usability Scale.
Summary
Provide here the conclusions of this chapter and make the bridge to the next chapter.
- report/dvp.1775673177.txt.gz
- Last modified: 2026/04/08 19:32
- by team3