มุมมองที่เป็นเรื่องตลกเกี่ยวกับประวัติศาสตร์หุ่นยนต์ได้จุดประกายการอภิปรายอย่างหลงใหลเกี่ยวกับเครื่องมือที่ถกเถียงกันมากที่สุดชิ้นหนึ่งในสาขานี้ คือ Robot Operating System ( ROS ) การถกเถียงครั้งนี้เผยให้เห็นความแตกแยกอย่างลึกซึ้งภายในชุมชนหุ่นยนต์ว่า framework ที่ใช้กันอย่างแพร่หลายนี้เป็นเครื่องมือที่มีประโยชน์หรือเป็นภาระทางเทคนิคที่บริษัทต่างๆ ต้องดิ้นรนเพื่อหลีกหนี
ความสัมพันธ์แบบรัก-เกลียดกับ ROS
ชุมชนหุ่นยนต์พบว่าตัวเองติดอยู่ในวงจรที่ไม่มีที่สิ้นสุดกับ ROS องค์กรหลายแห่งเริ่มต้นโครงการด้วย ROS เพื่อให้เคลื่อนไหวได้อย่างรวดเร็วในช่วงการสร้างต้นแบบ แต่จากนั้นก็ต้องเผชิญกับความท้าทายในการย้ายออกจากมันเมื่อขยายขนาดขึ้น สิ่งนี้สร้างรูปแบบที่คุ้นเคยที่ทีมงานค้นพบว่า ROS เสนอโซลูชันที่สร้างไว้แล้วซึ่งสามารถแทนที่โค้ดที่กำหนดเองหลายพันบรรทัด ดึงพวกเขากลับเข้าสู่ระบบนิเวศของมันแม้จะมีแผนก่อนหน้านี้ที่จะย้ายออกไป
นักพัฒนาคนหนึ่งได้จับความหงุดหงิดนี้ได้อย่างสมบูรณ์แบบ โดยอธิบาย ROS ว่าเป็นวิธีการประเมินอย่างรวดเร็วว่าองค์กรอาจสับสนเกี่ยวกับตัวเลือกทางเทคนิคของพวกเขามากแค่ไหน การวิพากษ์วิจารณ์มุ่งเน้นไปที่ ROS ที่เป็นชุดของส่วนประกอบที่แต่ละส่วนแสดงถึงเวอร์ชันที่ด้อยกว่าของเครื่องมือที่มีอยู่ ซึ่งใช้งานโดยผู้คนที่อาจไม่เข้าใจทางเลือกที่ดีกว่าที่มีอยู่อย่างเต็มที่
วงจรการพัฒนา ROS ทั่วไป:
- เริ่มต้นด้วย ROS สำหรับการสร้างต้นแบบอย่างรวดเร็ว
- วางแผนที่จะย้ายออกจาก ROS เมื่อโปรเจกต์ขยายตัว
- ค้นพบคอมโพเนนต์ของ ROS ที่สามารถแทนที่โค้ดที่เขียนเอง
- กลับมาใช้ ROS อีกครั้งแม้จะมีแผนการย้าย
- วงจรนี้เกิดขึ้นซ้ำกับโปรเจกต์ใหม่
ความท้าทายทางเทคนิคและข้อกังวลด้านสถาปัตยกรรม
ปัญหาหลักกับ ROS นั้นไปไกลกว่าปัญหาการใช้งานง่ายๆ นักวิจารณ์ชี้ให้เห็นว่า ROS ส่งเสริมสถาปัตยกรรมแบบกระจายที่ทำให้ปัญหาหุ่นยนต์ส่วนใหญ่แก้ไขได้ยากขึ้น โดยเฉพาะอย่างยิ่งปัญหาที่ต้องการการตอบสนองแบบ low latency สิ่งนี้เป็นปัญหาโดยเฉพาะเนื่องจากแอปพลิเคชันหุ่นยนต์ส่วนใหญ่มีความไวต่อเวลาโดยธรรมชาติ
สำหรับผู้มาใหม่ที่พยายามทำความเข้าใจ ROS เส้นโค้งการเรียนรู้พิสูจน์ว่าสูงชันเป็นพิเศษ เอกสารมักจะเริ่มต้นในช่วงกลางของแนวคิดแทนที่จะสร้างความเข้าใจจากพื้นฐานขึ้นมาหรือให้ภาพรวมแบบ top-down ที่ชัดเจน สิ่งนี้ทำให้นักพัฒนาหลายคนสับสนเกี่ยวกับคำถามพื้นฐาน เช่น วิธีการควบคุมมอเตอร์ง่ายๆ ผ่าน Arduino โดยใช้ระบบการส่งข้อความของ ROS
ส่วนประกอบของ ROS และข้อวิจารณ์:
- ระบบ Build สำหรับจัดการโครงการหุ่นยนต์
- การส่งข้อความแบบ Inter-process communication (IPC)
- ชุดรวมของไลบรารีและเครื่องมือ debugging
- ส่งเสริมสถาปัตยกรรมแบบกระจายที่เพิ่ม latency
- แต่ละส่วนประกอบถูกอธิบายว่าด้อยกว่าเครื่องมือเฉพาะทางที่มีอยู่
บริบทที่กว้างขึ้นของเครื่องมือหุ่นยนต์
การถกเถียงเรื่อง ROS เน้นย้ำถึงความท้าทายที่ใหญ่กว่าในการพัฒนาหุ่นยนต์ คือ ช่องว่างระหว่างเครื่องมือวิจัยทางวิชาการและการประยุกต์ใช้เชิงพาณิชย์ในทางปฏิบัติ ในขณะที่ ROS ให้ชุดเครื่องมือที่ครอบคลุมรวมถึงระบบ build โปรโตคอลการส่งข้อความ และยูทิลิตี้การดีบัก แต่ละส่วนประกอบมักจะไม่เทียบเท่าทางเลือกเฉพาะทางที่มีอยู่ในโลกการพัฒนาซอฟต์แวร์ที่กว้างขึ้น
การอภิปรายยังเผยให้เห็นว่าสาขาหุ่นยนต์ต้องดิ้นรนกับการเปลี่ยนผ่านจากสภาพแวดล้อมการวิจัยไปสู่ระบบการผลิต เครื่องมือที่ทำงานได้ดีในห้องปฏิบัติการมหาวิทยาลัยอาจไม่ขยายขนาดได้อย่างมีประสิทธิภาพสู่การปรับใช้เชิงพาณิชย์ ทำให้บริษัทต่างๆ ติดอยู่ระหว่างโซลูชันที่คุ้นเคยแต่จำกัดกับความพยายามอย่างมากที่ต้องใช้ในการสร้างทางเลือกที่ดีกว่า
การถกเถียงที่ดำเนินอยู่นี้สะท้อนถึงความเจ็บปวดในการเติบโตของสาขาที่อยู่ที่จุดตัดของวิศวกรรมฮาร์ดแวร์และซอฟต์แวร์ ซึ่งความซับซ้อนของแอปพลิเคชันหุ่นยนต์ในโลกแห่งความเป็นจริงมักจะเกินกว่าที่ framework อเนกประสงค์จะจัดการได้อย่างสง่างาม
อ้างอิง: A Brief, Incomplete, and Mostly Wrong History of Robotics