[ROS] Go down deep, Technical Review Pt.1 “ ROS Master and Connectivity”
DISCLAIMER
บทความนี้เป็นหนึ่งใน Series Go down deep ของ ROS ซึ่ง จะไม่มีการอธิบายคำศัพท์ และการทำงานพื้นฐาน เราจะสมมติว่าคนอ่านพอจะรู้เรื่องเกี่ยวกับ Computer science ทั่วไปมาระดับนึงแล้ว และ เราจะมั่วไปด้วยกัน !
ผู้เขียน พยายามจะย่อย http://wiki.ros.org/ROS/Technical%20Overview
ให้คนที่ไม่รู้เรื่อง พยายามเข้าใจ (อย่างน้อยก็ไอ้คนเขียนนี่แหละ)
มารู้จักกับ ROS Ecosystem กันเถอะ!
ROS พยายามจะสร้างภาวะแวดล้อมให้เหมือนกับ ระบบ Network ที่เราเข้าใจกันแหละ โดยที่จะมีการแยก เรื่องราวบ้าๆบอๆต่างๆ ออกเป็น Node แล้วคุยกันผ่าน Message มีการคุยกันทั้งแบบ Asynchronous(เป็นหลัก…) เช่นพวก Message Pub/Sub และ Synchronous เช่น Services
จริงๆแล้ว ROS เวลาคุยกัน(ส่ง Message , บลาๆ) จะ Implement เป็น Socket ผ่าน TCP เลย จึงมี Class ที่เรียกว่า TCPROS เกิดขึ้นมาใน implementation ในตัว communication backbone core ของระบบเลย (โดยใช้ C++ & Boost Lib)
เอ้อ พูดถึง TCPROS จริงๆแล้ว ก็มี UDPROS นะ เอาไว้ส่งข้อมูลที่เราส่วนใหญ่น่าจะรู้แล้วว่า เป็นของที่ lossy ปล่อยๆมันไปได้บ้าง รับได้บ้างไม่ได้บ้าง เพื่อความเร็ว
เพราะฉะนั้น แต่ละ Component จะมีสิ่งที่เรียกว่าเป็น Address(IP:PORT) ของ Node นั้นๆ อยู่เลยด้วยซ้ำ เช่น driver = localhost:1234 . viewer = localhost:5678
ROS MASTER มันก็มี ros_master_uri = localhost:11311 เป็น default ใช้ในการ ติดต่อแบบ XMLRPC เข้าไปที่ Server Core หลัก เพื่อรับรู้เรื่องราวการ register publisher และ subscriber ในรูปแบบต่างๆ
ROS MASTER CORE — “roscore”
Master ทำหน้าที่เป็น แกนกลางของระบบ จะเป็น Process ที่ Ecosystem ใดๆที่ใช้ ROS จะ RUN มันขึ้นมาแค่ตัวเดียว และ ห้ามล่ม ห้ามตาย ห้ามรักหมอ(เดี๋ยว!!)
ROS Master จะทำงานคล้ายๆ DNS Server เลย ให้ตรงๆกว่า คือ เป็นสมุดหน้าเหลือง (คือ การทำตัวเป็นผู้รอบรู้ คอยจดจำว่าใครเป็นใคร และ จะไปหายังไง)
นั่นคือการ Register ชื่อของ Node ทุกๆอัน เข้าไปเก็บไว้ที่มัน
รวมถึง Detail การส่งรับข้อมูลของ Node นั้นๆด้วย
(Publish ของไปให้ใครบ้าง, Subscribe ของจากใครบ้าง, มี Service อะไรบ้าง และ อีกมหาศาล)
รวมไปถึง Parameter ที่เราอยากจะฝากไว้ ไม่ว่าจะเป็น Global scope หรือ Private scope ก็ตาม มันก็จะไปแอบอยู่ที่นี่ (และเรียกใช้ เรียก Get จากตรงนี้แหละ)
ซึ่งเมื่อข้อมูลประจำ Node มีการเปลี่ยนแปลง (เช่น มีคน Publish ของ)
ROS Master จะรับรู้ และสร้าง Callback ไปยัง Node ปลายทางที่เกี่ยวข้อง (คนที่ Subscribe)
เช่น มีคำสั่งความเร็วมาจาก Joystick แล้วต้อง Callback ที่ Motor (จะได้เปลี่ยนความเร็วได้) ROS Master จะเป็นคนไปบอก Motor เอง ว่ามุงมีข้อมูลใหม่มาแล้วน๊ะะ !
แล้วอะไรทำให้ ROS สร้าง Topic , Pub , Sub คุยกันได้ล่ะ ?
เก็บคำศัพท์ก่อน RPC คืออะไร
Remote Procedure Call เป็นกระบวนการนึงในโลกของการเขียนโปรแกรม ที่ทำให้ process นึง ติดต่อกับอีก process ได้ เหมือนไปเรียก function ของ process อื่นได้นั้นเอง โดยจะส่งผ่านค่าต่างๆผ่านทาง การติดต่อกับ Kernel (คือการติดต่อผ่าน Operating System ของเครื่องนั้นๆเลย เช่น linux kernel , windows kernel) และ pass ข้อมูลที่จะส่ง ผ่าน Kernel Buffer ด้วย
โดยการส่งค่านั้น จะกินทรัพยากรน้อยมากๆเมื่อเทียบกับการ implement Socket (ท่อการเชื่อมต่อระหว่าง process แบบขั้นสูงมาหน่อย) ไปตรงๆเลย ROS เลยใช้การเชื่อมต่อแบบนี้ ในการช่วยสร้าง Connection(ให้ข้อมูลต่างๆที่จำเป็น) ก่อนที่จะสร้าง Socket ที่ใช้ส่งของ (Topic, Service , ..) จริงๆ
ข้อมูลต่างๆที่โดนยัดลงไป มีได้ หลาย Format เหมือนการจะเลือกส่งข้อความหากัน จะมี Format ยังไงดี จริงก็มีหลายแบบเช่น XML, JSON , BSON , …. เยอะแยะ
ROS Master ใช้ XMLRPC ในการ Implement
ใน ROS Master จะมีการรัน XMLRPC Server ขึ้นมาด้วย
ซึ่งใน โค๊ดจริงๆ ก็ใช้ Lib XMLRPC มาแบบเน้นๆเลย…
ใน Node มันถึงมีคำสั่งที่เรียกว่า init node เกิดขึ้น
ตอนเวลาเริ่มใช้งาน Node ใน ROS
เพื่อที่จะใช้ Slave API ต่างๆ เช่น Receive Callback จากชาวบ้านชาวช่อง
ด้านล่างนี้ Quote จากเว็บของ ROS มานะ
The XMLRPC server provides a Slave API, which enables the node to receive publisher update calls from the Master. These publisher updates contain a topic name and a list of URIs for nodes that publish that topic.
The XMLRPC server will also receive calls from subscribers that are looking to request topic connections. In general, when a node receives a publisher update, it will connect to any new publishers.
ที่อ่านๆมานี้คือเข้าใจว่า Master มี XMLRPC ที่ช่วยในการ Establish Subscriber , Publisher ใหม่ๆ เข้ามาในระบบ หรือ Maintain Connection information ของ Node ต่างๆ
เพราะฉะนั้น Flow ใน การ Establish connection ระหว่าง Publisher , Subscriber ภายใน Node จะออกมาประมาณนี้
จำลองสถานการณ์ ว่ามี publisher อยู่แล้ว และมีการสร้าง Node ใหม่ (process ใหม่ ที่ก็มี pub,sub เป็นของตัวเองเหมือนกันแหละ) แล้ว sub ของ Node ใหม่จะไป Connect กับ publisher ที่มีอยู่แล้ว
- Node ที่มี Subscriberใหม่ เริ่มลงทะเบียนที่ Master ผ่านการใช้ XMLRPC
- เช่นเดียวกัน Nodeใหม่นี้ ก็ให้ Publisher ลงทะเบียนกับ Master ด้วย XMLRPC
(คิดว่าข้อ 1 และข้อ 2 นี้เกิดขึ้นตอน Runtime หลังจาก init node แล้วมาประกาศตัวแปร publisher , subscriber) - หลังจากที่ Master ได้รับการลงทะเบียนจากข้อ 1,2 ต้องแจ้งคนอื่นๆ(ที่เคยลงทะเบียนไว้ก่อนหน้านี้) ว่ามี Publisher, Subscriber อันใหม่เกิดขึ้น
- Subscriber ที่ Topic ตรงกัน — เริ่มติดต่อไปหา Publisher ที่เป็นคนสร้าง Topic ด้วยตัว process เอง และเริ่ม Transport Protocol (ในเรื่องของ network เวลาจะเริ่ม protocol จะต้องมี Negotiate Protocol ก่อน แนวๆว่า ทำการตกลงกันก่อนว่าจะคุยกันแบบไหน ยกตัวอย่างโง่ๆแบบไม่ใช่ของจริง เช่น แต่ละคน พูดได้คนละ 3 คำเท่านั้น หรือว่าอะไรก็แล้วแต่) ทั้งหมดนี้ยังใช้ XMLRPC
- (ไม่รู้ว่าเกิดขึ้นในระหว่าง Negotiation ไหม) Publisher ส่ง Setting ของตัวเองให้กับ Subscriber ที่ฟัง Topic ของ publisher ตัวนั้นๆ (สงสัยคงจะเป็นพวก Type Message , queue size อะไรทำนองนั้นมั้ง) ผ่าน XMLRPC เหมือนกัน
- Subscriber รับข้อมูลของการเชื่อมต่อครบแล้ว รวมถึง Setting ต่างๆแล้วด้วย
ก็เริ่ม Connect กันได้ ผ่าน Network Protocol จริงๆจังๆ (ซึ่งก็คือพวก TCPROS,UDPROS)
TLDR : พบว่าสุดท้าย Node พอมัน Resolve หากันได้แล้ว มันก็ไปคุยกันเองแหละ ไม่พึง Master แล้ว (ถ้าไม่ได้สั่งให้มัน Check ว่า Master ยังเปิดอยู่ไหมอะนะ)
…
เอ แต่ทำไมเวลา Master node ตายแล้ว มันถึงตายยกแก๊งค์เลยหละ T_T
เพราะใน Code ส่วนใหญ่มีการเชค ROS Master ว่า Shutdown แล้วหรือยัง ไงล่ะ !!
หรือไม่ก็มีการคอย Update กับ XMLRPC Server ตลอด พอ update ไม่ได้ ก็เลยขอให้ process ตัวเองตายเลยดีกว่าา
พักยกกันก่อนน !!! ไว้มานั่งวิเคราะห์กันต่อ
ในส่วนของ Technical Review บน Ecosystem กับ Master Node ก็จะประมาณนี้ !!!
