Introduction

Project Context

Blank Image for Project Overview

DUST, or Dynamic Unified Smart Transport System, was a two-week IoT team project completed during a six-month robotics software development bootcamp in South Korea. It was my first team project focused on building a hardware-software integrated system from requirements to a working prototype.

The goal was to build a small automated factory-style transport system using sensors, motors, RFID, communication modules, and a line-tracing AGV. The system integrated the robot, gates, conveyor, distribution station, GUI, database, and central control system into a single coordinated workflow.

Project Goal

My Role

My role / contribution

I served as the team lead, helping define the project direction, distribute tasks, coordinate development, and support final integration. I also built the gate system, the automatic distribution system, and the physical prototype structures, and helped set up the full demonstration environment.

Challenge 1: Turning Requirements Into a Working System for the First Time

Following a Structured Development Process

This project was our first real attempt to follow a structured development process using the V-model. We tried to move from user requirements and system requirements into system architecture, hardware architecture, software architecture, implementation, and testing.

Challenge / Problem Visual 1

Moving Too Quickly Past Scenario Planning

Although we followed the basic steps, we did not yet understand how much detail was needed in the system scenario stage. We defined the general workflow, but overlooked important details such as module responsibilities, interface behaviour, communication timing, and how the system should respond when something failed.

Challenge / Problem Visual 2

Facing Integration Gaps During Development

Those missing details created gaps during integration. Individual modules could be built, but connecting the AGV, RFID-based position tracking, facility modules, central system, GUI, and database required more trial and error because the expected behaviour between modules was not defined clearly enough.

Challenge / Problem Visual 3

Applying the Lesson to Later Projects

The project still resulted in a working prototype, but it made the weakness of shallow architecture planning clear. After this project, I paid closer attention to defining system scenarios, module boundaries, data flow, and communication interfaces before implementation went too far, especially in later ROS 2 projects.

Challenge / Problem Visual 3

Challenge 2: Central System Bottleneck During Integration

Concentrating Control Around One Module

The prototype relied on a single central control system that coordinated the AGV, facility modules, GUI, database, and communication flow. I assigned this task to the strongest technical team member after considering each person’s strengths, and at the time, this was the most practical way to move the project forward within the short timeline.

Challenge / Problem Visual 1

Running Into a Communication Bottleneck

As integration progressed, the central system became a bottleneck. The developer responsible for it was able to build the core system, but did not have enough time to clearly explain the communication routes, interface details, and expected behaviour to the rest of the team.

Challenge / Problem Visual 2

Making Interface Planning a Shared Task

To reduce the integration gap, I pushed the team to clarify the interface specifications together instead of treating them as one person’s responsibility. Each module owner had to participate because the interface defined how their subsystem would communicate with the central system and with the rest of the factory workflow.

Challenge / Problem Visual 3

Completing Integration Through Alignment

After discussing the interface issues directly, the team aligned the AGV, facility modules, central system, GUI, and database well enough to complete the final demonstration. The process showed that central system development requires both implementation and coordination with every dependent module.

Challenge / Problem Visual 3

Challenge 3: Power Instability and Hardware Debugging

Tracking Unclear Failures Across the Robot System

During testing, the line-tracing AGV sometimes stopped unexpectedly, moved incorrectly, or failed to send position data to the central system on time. Since the factory facilities depended on that data, even a small delay could cause the robot to pass a checkpoint before the system recognized its location.

Challenge / Problem Visual 1

Finding That Power Was the Root Cause

At first, the issue looked like a software, Wi-Fi, or communication problem. After repeated testing, we found that the weak battery source was causing the ESP32-based robot to slow down, lose reliable communication, and fail at line tracing when the power dropped.

Challenge / Problem Visual 3

Stabilizing the System by Improving the Power Source

Once we replaced the weak battery setup with a more stable power source, many of the random failures disappeared. This showed that the code was not always the source of the problem; the system needed reliable power before the software and communication layers could behave correctly.

Challenge / Problem Visual 3

Checking Hardware Issues Step by Step

Power was the main issue, but we also dealt with loose breadboard connections, unreliable jumper wires, unresponsive motors, and microcontroller issues that sometimes required a reset. These problems made it clear that small physical issues can appear to be larger software failures, so hardware debugging requires careful step-by-step checking.

Challenge / Problem Visual 3

Conclusion

Outcome

By the end of the project, our team had completed a working prototype of an automated factory-style transport system. The line-tracing AGV, RFID-based position tracking, gate system, distribution station, conveyor, GUI, database, and central control system worked together well enough to demonstrate the full workflow.

Outcome Vissual

Key Lesson

DUST became an important foundation for later robotics work. It showed me that integrated systems depend on clear scenarios, shared interface planning, reliable power delivery, and careful hardware validation before the full system can behave predictably.

Extra Visual