ตอนที่ 5: การเรียกใช้คำสั่งด้วย Services (Client/Server) และ Actions
1. 🎯 ตอนที่ 5: สั่งหุ่นยนต์ดั่งใจนึกด้วย Services และ Actions
สวัสดีครับน้องๆ ว่าที่วิศวกรหุ่นยนต์ทุกคน! หลังจากตอนที่แล้วพี่พาน้องๆ ไปจัดเต็มกับระบบ “กระจายเสียง” หรือ Topics กันมาแล้ว วันนี้พี่จะพามาดูอีกด้านของการสื่อสารในโลก ROS 2 กันบ้างครับ
Topic เป็นพระเอกในเรื่องการส่งข้อมูลแบบต่อเนื่องก็จริง แต่มันก็มีจุดอ่อนมหันต์เวลาที่เราต้องการ “สั่งงานแล้วรอคำตอบ” หรือ “สั่งงานที่ใช้เวลานานๆ” วันนี้เราจะมาทำความรู้จักกับเครื่องมือคู่บุญของคนทำหุ่นยนต์อย่าง Services และ Actions ที่จะมาอุดช่องโหว่นี้กันครับ!
2. 📖 เปิดฉาก (The Hook)
น้องๆ ลองนึกภาพตามพี่นะครับ สมมติว่าเราเขียน Node ควบคุมแขนกลหุ่นยนต์ ถ้าเราใช้ Topic ในการสั่งให้แขนกลขยับไปหยิบแก้วน้ำ ปัญหาคือ Topic มันส่งข้อมูลทางเดียว (Unidirectional) เราสั่งไปแล้ว เราจะรู้ได้ยังไงว่าหุ่นยนต์หยิบแก้วน้ำสำเร็จหรือเปล่า? หรือถ้าหุ่นยนต์เดินไปชนกำแพงระหว่างทาง เราจะสั่งยกเลิก (Cancel) คำสั่งกลางคันยังไง?
สมัยพี่ทำหุ่นยนต์ตัวแรกๆ พี่พยายามใช้ Topic แก้ปัญหาทุกอย่าง ผลคือโค้ดพันกันยุ่งเหยิงยิ่งกว่าสายไฟ หุ่นยนต์ค้างเพราะมัวแต่รอข้อมูลตอบกลับ (Block) ในลูปประมวลผลหลัก นี่แหละครับคือเหตุผลที่วิศวกรหุ่นยนต์ระดับโลกถึงออกแบบ Services และ Actions มาให้เราใช้งาน เพื่อให้เราควบคุมลอจิกของหุ่นยนต์ได้อย่างสง่างามและมีประสิทธิภาพสูงสุดครับ!
3. 🧠 แก่นวิชา (Core Concepts)
เพื่อให้เห็นภาพชัดเจนที่สุด พี่ขอเปรียบเทียบการสื่อสารทั้ง 3 รูปแบบใน ROS 2 ให้ดูตามนี้ครับ:
Topics (คุยไปเรื่อยๆ ไม่รอคำตอบ):
- คอนเซปต์: การสื่อสารแบบ Asynchronous (ทำงายคู่ขนาน) ผ่าน Publisher / Subscriber เปรียบเหมือน “สถานีวิทยุ” ที่กระจายเสียงไปเรื่อยๆ ใครอยากฟังก็จูนคลื่นมาฟัง
- จุดเด่น: ส่งข้อมูลแบบต่อเนื่องความถี่สูง (Continuous data streams)
- Use case: เหมาะกับการส่งข้อมูลเซ็นเซอร์ เช่น ภาพจากกล้อง (Camera), ค่าการหมุนของล้อ (Odometry), หรือข้อมูลจาก Lidar
Services (ขอไป-ตอบกลับทันที):
- คอนเซปต์: การสื่อสารแบบ Synchronous ผ่านกลไก Client / Server (Request-Response) เปรียบเหมือน “การโทรศัพท์หา Call Center” เราถามไปปุ๊บ พนักงานตอบกลับปั๊บแล้ววางสาย
- จุดเด่น: ทำงานรวดเร็ว แต่ระหว่างรอคำตอบ Node ฝั่ง Client จะถูกบล็อก (Blocking call)
- Use case: เหมาะกับงานที่จบไวๆ เช่น การคำนวณสมการ Kinematics (IK), การสั่งเปิด/ปิดหลอดไฟ LED, หรือการขอสถานะปัจจุบันของหุ่นยนต์
Actions (สั่งงานยาวๆ มีอัปเดตสถานะ):
- คอนเซปต์: การสื่อสารแบบ Asynchronous ที่ออกแบบมาเพื่องานที่กินเวลานาน (Long-running tasks) ประกอบด้วย 3 ส่วนคือ Goal, Result และ Feedback เปรียบเหมือน “การสั่งพิซซ่าเดลิเวอรี่” เราสั่งไป (Goal) ระหว่างรอเราเช็คสถานะในแอปได้ว่าอบเสร็จหรือยัง (Feedback) ถ้าช้าเกินไปเรากดยกเลิกได้ (Cancel/Preempt) และสุดท้ายคนส่งมาถึงหน้าบ้าน (Result)
- จุดเด่น: ไม่บล็อกการทำงานหลัก, สามารถแจ้งสถานะระหว่างทำ (Feedback) และสามารถสั่งยกเลิกกลางคันได้ (Preemptible)
- Use case: เหมาะกับงานที่ใช้เวลานานและซับซ้อน เช่น การสั่งหุ่นยนต์เดินไปยังจุดหมาย (Navigation), หรือการสั่งแขนกลให้หยิบจับวัตถุ
4. 💻 ร่ายมนต์โค้ดและคำสั่ง (Show me the Code)
เรามาดูวิธีการใช้งาน Services และ Actions ผ่าน Terminal ของ ROS 2 กันครับ เครื่องมือพวกนี้ช่วยให้เรา Debug หุ่นยนต์ได้ง่ายมากๆ:
ตัวอย่างการใช้ Services (ขอผลบวกตัวเลข):
# ตรวจสอบว่าในระบบมี Service อะไรเปิดอยู่บ้าง
ros2 service list
# สมมติเราเจอ Service ชื่อ /add_two_ints เราสามารถสั่งให้มันบวกเลข 4 กับ 7 ได้ทันที!
# โครงสร้างคือ: ros2 service call <ชื่อ_service> <ชนิด_interface> "<ข้อมูล_request>"
ros2 service call /add_two_ints example_interfaces/srv/AddTwoInts "{a: 4, b: 7}"คอมเมนต์: คำสั่งนี้จะวิ่งไปหา Server แล้วรอจนกว่าจะได้คำตอบ sum=11 กลับมา จากนั้นก็จะจบการทำงานครับ
ตัวอย่างการใช้ Actions (สั่งหุ่นยนต์หมุนตัว):
# ตรวจสอบ Action ทั้งหมดในระบบ
ros2 action list
# สั่งให้หุ่นยนต์เต่า (turtlesim) หมุนตัวไปที่มุม 1.0 เรเดียน พร้อมขอรับ Feedback ระหว่างหมุน
# โครงสร้างคือ: ros2 action send_goal <ชื่อ_action> <ชนิด_interface> "<ข้อมูล_goal>"
ros2 action send_goal /turtle1/rotate_absolute turtlesim/action/RotateAbsolute "{theta: 1.0}" --feedbackคอมเมนต์: สิ่งที่น้องๆ จะเห็นใน Terminal คือมันจะปริ้นต์ Feedback ออกมาเรื่อยๆ (เช่น หมุนไปได้เท่าไหร่แล้ว) ระหว่างที่หุ่นยนต์กำลังหมุน จนกว่าจะสำเร็จ (SUCCEEDED) แล้วพ่น Result ออกมาครับ
5. 🛡️ เคล็ดลับจากคัมภีร์ลับ (Under the Hood / Pro-Tips)
- ระวัง Deadlock ใน Service (Blocking Call): พี่ขอเตือนแรงๆ เลยว่า ห้าม ใช้ Service กับงานที่ต้องใช้เวลาประมวลผลนานเด็ดขาด! เพราะกลไกของ Service เป็นแบบ Synchronous ทันทีที่ Client ส่ง Request ตัวลูปประมวลผลของ Node นั้นจะถูกหยุด (Block) เพื่อรอคำตอบ ถ้า Server ค้าง หรือเน็ตเวิร์กมีปัญหา หุ่นยนต์ของน้องจะกลายเป็นอัมพาตทันทีครับ! ถ้างานใช้เวลานาน ให้เปลี่ยนไปใช้ Actions เสมอ
- ความลับของ Action (Under the Hood): รู้หรือไม่ครับว่า Actions จริงๆ แล้วไม่ได้เป็นโปรโตคอลใหม่เอี่ยม แต่มันถูกสร้างครอบทับ (Built on top of) Topics และ Services อีกที! โดยเบื้องหลังแล้ว การส่ง Goal, การขอยกเลิก (Cancel), และการขอ Result จะวิ่งผ่านระบบ Services (เพราะต้องการความชัวร์) ส่วนการส่ง Feedback และ Status จะวิ่งผ่านระบบ Topics (เพราะเป็นการส่งข้อมูลแบบสตรีมมิ่ง)
6. 🏁 บทสรุป (To be continued…)
สรุปง่ายๆ ครับ:
- ถ้าอยากส่งข้อมูลรัวๆ ใช้ Topics
- ถ้าอยากถามไวตอบไว ใช้ Services
- ถ้าอยากสั่งงานยาวๆ มีอัปเดตสถานะและยกเลิกได้ ให้ใช้ Actions
การเลือกใช้เครื่องมือให้ถูกกับงาน คือกุญแจสำคัญที่จะทำให้สถาปัตยกรรมซอฟต์แวร์หุ่นยนต์ของน้องๆ แข็งแกร่งและทำงานได้อย่างมีประสิทธิภาพ ตอนนี้เรารู้จักกลไกการสื่อสารหลักของ ROS 2 ครบหมดแล้ว! ในตอนต่อไป พี่จะพาน้องๆ ไปดูเรื่องของการปรับแต่ง “พารามิเตอร์ (Parameters)” ให้หุ่นยนต์สามารถเปลี่ยนพฤติกรรมได้โดยไม่ต้องมานั่ง Re-compile โค้ดใหม่ เตรียมตัวสนุกกันต่อได้เลยครับ!
ต้องการที่ปรึกษาด้านการออกแบบสถาปัตยกรรมหุ่นยนต์ (Robotics) และระบบ Automation ให้กับองค์กรของคุณ? ทีมงาน WP Solution พร้อมให้บริการออกแบบและพัฒนาซอฟต์แวร์แบบครบวงจร ดูรายละเอียดบริการของเราได้ที่: www.wpsolution2017.com หรือพูดคุยปรึกษาเบื้องต้นได้ที่ Line: wisit.p