This shows you the differences between two versions of the page.
|
pm:prj2026:jan.vaduva:nicolas.costescu [2026/05/16 20:42] nicolas.costescu [3.6. Hardware Assembly & Proof of Concept] |
pm:prj2026:jan.vaduva:nicolas.costescu [2026/05/24 20:52] (current) nicolas.costescu |
||
|---|---|---|---|
| Line 89: | Line 89: | ||
| {{ :pm:prj2026:jan.vaduva:schema1.jpeg?600 | System detecting a full bin }} | {{ :pm:prj2026:jan.vaduva:schema1.jpeg?600 | System detecting a full bin }} | ||
| > **Explanation:** This test validates the interlocking safety state. An obstacle is placed physically close (< 7cm) to the interior ultrasonic sensor (simulating a trash capacity of > 85%). The microcontroller correctly processes the echo timing, updates the logic state, and physically turns on the **Red LED**. Simultaneously, the active buzzer is triggered on pin PD5, and the servo motor is software-locked, proving that the hardware responds accurately to environmental inputs. | > **Explanation:** This test validates the interlocking safety state. An obstacle is placed physically close (< 7cm) to the interior ultrasonic sensor (simulating a trash capacity of > 85%). The microcontroller correctly processes the echo timing, updates the logic state, and physically turns on the **Red LED**. Simultaneously, the active buzzer is triggered on pin PD5, and the servo motor is software-locked, proving that the hardware responds accurately to environmental inputs. | ||
| + | |||
| + | ===== 4. Software Design ===== | ||
| + | |||
| + | ==== 4.1. Current Status of Software Implementation ==== | ||
| + | Currently, the software component is fully functional and successfully integrated with the hardware. The project has been migrated to a modern development environment (PlatformIO), utilizing a hybrid C/C++ architecture. | ||
| + | The core logic of the system (sensor reading, PWM signal generation, LED and buzzer control) is implemented //bare-metal// (in pure C language, through direct manipulation of AVR registers). To ensure the stability of the Human-Machine Interface (HMI), the upper level of the application uses the Arduino framework (''main.cpp''), allowing the integration of previously written C modules via the ''extern "C"'' directive and managing the LCD screen through a dedicated C++ library. The finite state machine runs correctly, with the system being able to process data in real time without blocking. | ||
| + | |||
| + | ==== 4.2. Motivation for Chosen Libraries ==== | ||
| + | Although a large part of the code was written from scratch to maintain strict control over hardware resources, certain libraries were strategically chosen to streamline development and guarantee stability: | ||
| + | * **LiquidCrystal_I2C.h (and the Wire.h dependency):** Chosen for controlling the 1602 LCD screen via the PCF8574 module. During the //bare-metal// prototyping phase, although the I2C hardware bus was successfully validated (confirming the 0x27 / 0x4E address), the initialization of the HD44780 controller proved to be extremely sensitive to wait times (//delays//) and 4-bit masking sequences. Using this established library abstracts the timing logic and prevents //I2C Bus Hang// phenomena, ensuring robust data display without jeopardizing the main program loop. | ||
| + | * **Arduino.h (PlatformIO):** Included to provide easy access to the basic functions required by the screen library and to unify the compilation process in the C++ environment. | ||
| + | |||
| + | ==== 4.3. Project Novelty ==== | ||
| + | Compared to a standard automatic trash bin (which only opens a lid upon motion detection), the novelty of this project lies in the **dynamic internal volume calculation and monitoring system**, supported by a "self-healing" algorithm (//self-healing logic//). | ||
| + | The system doesn't just measure a distance; it continuously interpolates the fill percentage, automatically adjusting outlier values (e.g., clamping values that exceed the physical depth of the bin). Additionally, the implementation of an **Interlocking (Safety Lock)** state represents a practical innovation: if the system detects a capacity over 85%, it mechanically refuses to open the lid to prevent overfilling and physical jamming of the trash, simultaneously alerting the user visually and acoustically. | ||
| + | |||
| + | ==== 4.4. Justification for Using Lab Functionalities ==== | ||
| + | The project integrates multiple concepts studied in the laboratory, utilized as follows: | ||
| + | * **Hardware Timers / Counters:** * **Timer1 (16-bit):** Configured at the register level (''TCCR1A'', ''TCCR1B'') in Fast/Phase Correct PWM mode to generate a precise 50Hz signal on pin ''PB1'' (OC1A). The ''ICR1'' register defines the period, and ''OCR1A'' is dynamically manipulated to control the pulse width (1ms - 2ms), determining the exact angle of the servo motor. | ||
| + | * **Timer0 / Tick System:** Used for counting milliseconds (''get_milis()''), essential for the non-blocking operation of the system. | ||
| + | * **Interrupts:** Globally activated via the ''sei()'' function, these allow timers to run in the background (e.g., generating overflows for time calculation and ultrasonic sensor pulses) without blocking the main program execution. | ||
| + | * **Serial Communication (USART):** Configured by manipulating the ''UBRR0'' and ''UCSR0'' registers, the USART module was vital during development for debugging. All sensor data and state changes were printed in real-time to the terminal, allowing for precise distance calibration. | ||
| + | * **TWI Module (I2C):** Used internally by C++ libraries to communicate with the LCD screen, exclusively utilizing pins ''PC4'' (SDA) and ''PC5'' (SCL), thus saving valuable GPIO pins. | ||
| + | * **Direct Port Manipulation (GPIO):** Interaction with the LEDs, buzzer, and ultrasonic sensor Trigger pins is done by directly writing to the direction (''DDRx'') and data (''PORTx'') registers, guaranteeing instantaneous execution and a minimal memory footprint. | ||
| + | |||
| + | ==== 4.5. Project Structure, Interaction, and Validation ==== | ||
| + | **Code Architecture:** | ||
| + | The project is strictly modularized, with each hardware component having its own set of header and source files (e.g., ''usart.h'', ''timer.h'', ''ultrasonic.h'', ''servo.h'', ''leds.h'', ''buzzer.h''). This structure decouples the sensor logic from the main application. The ''main.cpp'' file acts as an orchestrator. | ||
| + | |||
| + | **Feature Interaction:** | ||
| + | The core logic is based on a Finite State Machine (FSM) with three main states: ''CLOSED_STATE'', ''OPEN_STATE'', and ''COOLDOWN_STATE''. | ||
| + | The heart of the system is a completely non-blocking loop. Instead of using blocking functions like ''delay()'', the system uses asynchronous time evaluations (''current_time - last_read >= 500''). | ||
| + | * When the system is in the ''CLOSED_STATE'', it reads both ultrasonic sensors. It calculates the trash level and updates the interface (LEDs and LCD). | ||
| + | * If the exterior sensor detects a presence (<= 20cm) and the internal percentage is safe (< 85%), the actuator is triggered (the Servo receives the corresponding value via ''OCR1A''), and the system transitions to the ''OPEN_STATE''. | ||
| + | * After the user moves away, a logical timer moves the system to the ''COOLDOWN_STATE'' to allow the lid to close smoothly. | ||
| + | |||
| + | **Validation Methodology:** | ||
| + | Each module was independently tested and validated (//Unit Testing// at the hardware level). | ||
| + | - //Ultrasonic Sensors:// Validated by printing the read distance on the USART and comparing it with a physical ruler. | ||
| + | - //Servo Motor:// Validated by sending static angles (0, 90, 150 degrees) on an oscilloscope/logic analyzer to confirm the 50Hz frequency, followed by connecting the real mechanical load. | ||
| + | - //LCD/I2C Integration:// Validated through manually written I2C scanners to confirm the physical address, resolving timing conflicts before implementing the final library. | ||
| + | - //Final System:// Validated through "Black Box" testing – simulating the filling of the bin with a physical obstacle to demonstrate the successful triggering of the visual (Red LED), acoustic (Buzzer), and mechanical (servo lock) interlocking. | ||