amr-ros-k4/readme.md

Project Management — AMR ROS2 K4

Project: Blockly ROS2 Robot Controller (Kiwi Wheel AMR) ROS2 Distro: Jazzy Last Updated: 2026-03-09 Current Focus: kiwi_controller — Adaptive control for Kiwi Wheel drive

Dokumentasi lengkap dapat dilihat di DOCUMENTATION.md.

Aturan pengggunaan dokumen

bab pada dokumen merepresentasikan alur rencana pengembangan.

Potential Enhancements

bab ini digunakan untuk Feasibility Study

Planned Feature

Backlog. Setelah kita pelajari untuk di kerjakan maka kita pindah ke backlog

Feature Task

penjabaran Pekerjaan yang ready untuk dikerjakan. Task harus dijelaskan apa yang akan dikerjakan dan terdapat definition of done nya Berikut ini adalah template untuk pembuatan task :

## <nomor task> <judul task> : <state: [ ] >
jelaskan permasalah di bab ini
### Definition Of Done
jelaskan apa yang dimaksut untuk menyelesaikan task

---

Potential Enhancements

this list is short by priority

• ROS Feature in generated block blocky: currently, block blocky only generate action client, and there is sub/pub and other ROS feature need to implement to get/set value to node.
• Launch files: blockly_bringup package with ROS2 launch files to start all nodes with one command
• Sensor integration: Subscriber nodes for sensor data feeding back into Blockly visual feedback
• RealHardware implementation: Fill in ROS2 publishers/service clients for actual Pi hardware nodes (topics TBD)
• ROS2 lifecycle nodes: Migrate executor and controller to lifecycle nodes for managed state transitions
• Simulation: Integrate with Gazebo/Isaac Sim for testing Kiwi Wheel kinematics before deploying to hardware
• Block categories: Future blocks grouped into Robot, Sensors, Navigation categories

Feature Task

1 Hardware Interface Consolidation [✅]

Menambah block baru sebelumnya butuh edit 4 file (interface, dummy, real, handler). Sekarang refactored agar handler menjadi single source of truth — satu file handler berisi logika dummy dan real hardware.

Perubahan:

• Hapus interface.py, dummy_hardware.py, real_hardware.py (ABC + 3 implementasi)
• Buat hardware.py — class Hardware generic (mode, node, call_log) yang tidak pernah perlu diubah
• Handler berisi logika dummy (log) dan real (ROS2 publish) — cek via hardware.is_real()
• Dependency real hardware di-import lazy (di dalam if) untuk menghindari import error di dev machine

Definition Of Done

• Menambah block baru hanya perlu 1 file handler (+ JS block + manifest)
• pixi run executor dan pixi run executor-hw tetap berfungsi
• hardware.call_log tetap bisa dipakai untuk testing
• Semua test pass (pixi run test)

2 Fix Stop Button — Client-Side Cancellation [✅]

Stop button tidak benar-benar menghentikan eksekusi. Root cause: saat await executeAction() blocking (misal delay 10 detik), flag stopRequested tidak dicek. Di Python, _wait_for_future() tidak punya mekanisme cancel. Di executor, _cancel_callback() tidak bisa jalan karena single-threaded rclpy.spin().

Solusi: client-side cancellation — cancel di sisi JS dan Python, executor handler tetap jalan sampai selesai tapi hasilnya di-discard.

Perubahan yang diperlukan:

• bridge.js: tambah cancelCurrentAction() + Promise.race di executeAction() agar bisa di-cancel segera
• debug-engine.js: wire stopExecution() → cancelCurrentAction()
• app.py: tambah cancel_action() bridge method + cancel-aware _wait_for_future() dengan threading.Event

Definition Of Done

• Klik Stop saat delay 10 detik → UI respond dalam < 500ms
• Console tampilkan "Program stopped by user"
• Block highlighting di-clear setelah stop
• Tombol Run/Stop state benar setelah stop
• Stop berfungsi di mode Run dan Debug
• Stop saat block instan (misal led_on) tidak crash
• Semua test existing pass (pixi run test)