Differences

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

--- report:conc [2026/04/30 17:13] – [Conclusions] team5
+++ report:conc [2026/05/28 13:18] (current) – team5
@@ Line 1: / Line 1: @@
 ===== 8. Conclusions =====
-==== Achievements ====
-//Discuss here what was achieved (wrt the initial objectives) and what is missing (wrt the initial objectives) of the project.//
+==== 8.1 Achievements ====
-==== Limitations ====
-//Identify here the limitations of the solution and prototype.//
+The Connect project set out to transform a standard metro carriage into a participatory space that counteracts digital isolation through ambient light interaction and asynchronous voice exchange. Evaluated against the four objectives defined in Section 1.4, all primary targets were met.
-==== Future Development ====
-//Provide here your recommendations for future work.//
+The functional core of the system was fully validated. The two-node prototype demonstrates pressure detection via Velostat sensors, bidirectional CAN bus communication between an ESP32-C3 sensor node and a central node, and real-time RGB LED feedback driven by the WS2813 addressable strip. ADC output responded linearly to applied pressure, the CAN bus achieved a Packet Delivery Ratio exceeding 99.9 %, and LED output was confirmed free of dead pixels and flickering across the full animation cycle. The potentiometer-based sensitivity calibration allowed reliable threshold adjustment independent of firmware changes. The interrupt-driven, deep-sleep firmware architecture performed correctly on both nodes and scales to additional nodes without modification.
+All performance targets were met. End-to-end latency from sensor contact to LED illumination was confirmed below 100 ms. No ghost triggers were observed during electromagnetic interference testing with a brushed DC motor operating in proximity to the CAN wiring. Enclosure surface temperature remained below 50 °C after four hours of continuous operation at 80 % LED brightness, end-of-line voltage remained above 4.7 V under full white load, and the system retained full electrical sensitivity after 1000 automated trigger cycles.
+Structural and safety validation was completed. Finite Element Analysis of both the ceiling-mounted main box and the pole-mounted secondary node confirmed safety factors exceeding 12.0 and 30.0 respectively against the yield strength of Nanovia PA Rail. Electrical continuity between enclosure and ground was confirmed below 0.1 Ω, all cable and filament materials carry V-0 or LSHF certification, the sensor assembly survived a 5 kg impact test without loss of function, and no moisture ingress was detected following cleaning mist exposure.
+Software testing passed in full. CAD integration confirmed zero mechanical interference between components with the required 5 mm clearance maintained. CAN bus arbitration correctly prioritised the higher-priority node ID under forced collision conditions. The animation algorithm ran for 24 hours in simulation without memory leaks or buffer overflows. Heartbeat timeout detection triggered within 500 ms of CAN disconnection and correctly switched the LED output to static safety white.
+The web platform reached a deployable state. Load testing at 1000 concurrent requests produced a zero error rate and a mean latency of 195.77 ms on the write endpoint. The System Usability Scale evaluation returned a mean score of 86.59 across 11 participants, placing the interface in the "Excellent" range, well above the industry average of 68. All five Jest unit test cases covering the GET and POST API routes passed in 0.277 seconds. User acceptance testing confirmed that more than 80 % of non-technical participants identified the pole sensor as the interaction point within 5 seconds, no participants reported glare or eye strain at maximum brightness, users correctly associated the light animations with system state, and the interaction was successfully triggered by participants across the full range of tested heights and hand strengths.
+The prototype was delivered within the 100 € budget constraint at a total cost of 97.92 €.
+==== 8.2 Limitations ====
+The prototype represents a deliberate functional reduction and several gaps between the designed solution and the implemented system remain relevant for future iterations.
+The prototype covers a single handrail segment with two nodes. The full designed solution requires eleven sensor nodes distributed across a carriage. The two-node configuration validates the communication protocol and interaction loop but does not exercise bus arbitration under simultaneous multi-node transmission at full network scale.
+Fire-rated enclosures were not fabricated for the prototype. The housings are 3D-printed in PLA, which does not meet EN 45545-2 flammability requirements. The PA Rail enclosures specified for deployment were impractical to source within the prototype budget. Physical compliance testing of the enclosure material against railway fire safety standards therefore remains pending.
+The dual-rail power architecture was not implemented. The prototype uses a single 5 V bench supply in place of the six step-down converters and dual 12 V and 5 V distribution chain specified for the full installation. Behaviour of the power architecture under worst-case current draw across all eleven nodes has not been empirically verified.
+Phase 2 was not evaluated in a simulated transit environment. The QR voice messaging platform was assessed via load testing and SUS scoring, but end-to-end passenger behaviour, including QR code discovery at exit doors and the intentional delay mechanic, was not observed under realistic boarding and alighting conditions.
+==== 8.3 Future Development ====
+Scaling from two nodes to the full eleven-node network is the primary technical extension. This requires fabrication of additional Sensor Node PCBs and validation of bus arbitration timing under simultaneous transmission from multiple nodes. The heartbeat timeout and safety-white fallback logic should also be confirmed correct when any single node drops from a live eleven-node network.
+Enclosure fabrication in Nanovia PA Rail is required before any deployment in a transit environment. A Portuguese or EU-based supplier should be identified to reduce logistics cost and lead time at scale. The enclosure geometry is defined and FEA-validated; procurement and physical fire compliance testing are the remaining steps.
+The dual power rail should be implemented and verified with converters sized for worst-case current draw across the full node count. Voltage drop along the LED strip should be re-confirmed against the 4.7 V minimum under the full three-strip, eleven-node load.
+For Phase 2, a pilot deployment in a controlled transit-adjacent environment, such as a station concourse or a simulated carriage mockup, would allow end-to-end validation of the QR discovery flow, the intentional delay mechanic, and the content moderation pipeline under realistic passenger behaviour. A longitudinal dataset from Phase 2 submissions would also provide quantitative grounding for the social impact claims established in Sections 2.3.1 and 5.5.
+The heart rate sensing capability referenced in Section 1.5.3 and the auditory feedback output described in Section 1.4 were not implemented in this iteration. Both represent additional sensing and output channels that would enrich the interaction model and bring the system closer to the full vision outlined in the initial objectives.