Context
The final project of Integrated Design II (Tugas Perancangan Terintegrasi II), a course focused on the design stage: turning a need into a system architecture and a working prototype.
Problem
Indoor environments are GPS-denied, so Automated Guided Vehicles (AGVs) must localize another way. LiDAR is accurate but expensive. This project asks how far a low-cost approach can go: localizing from a camera and printed ArUco markers alone.
Approach
- Marker-based localization only: the AGV’s position comes purely from ArUco marker readings. There is no odometry or other sensor fusion.
- General by design: any number of markers can be registered in the web interface, and multiple maps can be created and managed, so the system is not tied to one fixed layout.
- ROS2 pipeline on Raspberry Pi: OpenCV detects the markers, and separate ROS2 nodes handle detection and localization.
- Web interface: used to register markers, manage maps, and display the AGV’s position and trajectory live.
My Contribution
I worked on the system end to end:
- Architecture: designed how the components connect and how data flows between them (see the diagram above).
- ROS2 development: set up the environment and implemented the ROS2 programs for ArUco detection, localization, and the web interface.
- Integration: connected the detection, localization, and web interface into one working system.
Result
A working system that localizes the AGV from ArUco markers and shows its position and trajectory live in the web interface.
In a simple accuracy check, the position error was about 3 cm. Each marker placement was compared against a reference point marked on the floor and measured with a ruler. This was a single manual test under uncontrolled conditions, so treat it as an indication, not a benchmark. Frame rate and latency were not measured.
Limitations and Lessons
- Blur breaks localization: when the image is blurred, the markers cannot be detected and the position estimate freezes at its last value. Motion blur from the robot itself causes the same problem.
- No fallback between detections: since localization relies only on markers, nothing bridges the gaps when detection is lost. Fusing wheel odometry or an IMU would be a natural improvement.
- Needs a prepared environment: markers must be placed and registered before the AGV can localize.
- Next step: a repeated, controlled accuracy test, with measured frame rate and latency on the Raspberry Pi.