VR Robot Cockpit

VR Robot Cockpit เป็นระบบควบคุมหุ่นยนต์ผ่าน Virtual Reality (VR) ที่ออกแบบในรูปแบบ “Cockpit Interface” โดยได้รับแรงบันดาลใจจากอนิเมชันเรื่อง Gundam Build Fighters ระบบนี้มุ่งเน้นการสร้างประสบการณ์ควบคุมแบบ immersive พร้อมทั้งรองรับการแสดงผลข้อมูลของหุ่นยนต์แบบ real-time เช่น ภาพจากกล้อง, ข้อมูลเซนเซอร์ และสถานะการทำงาน ผ่านสภาพแวดล้อมเสมือนจริง

ภายในระบบ ผู้ใช้งานสามารถควบคุมหุ่นยนต์ Hiwonder JetRover ได้โดยตรงผ่าน VR Controller ที่เชื่อมต่อกับระบบหุ่นยนต์ผ่าน ROS2

วัตถุประสงค์

เพื่อสร้างระบบควบคุมหุ่นยนต์ Jet Rover ในรูปแบบ Cockpit ผ่านแว่น Oculus Quest 2
เพื่อพัฒนาอินเทอร์เฟซ VR สำหรับควบคุมและดูสถานะหุ่นยนต์แบบ Real-time
เพื่อศึกษากระบวนการรับ-ส่งข้อมูลแบบ Real-time ระหว่าง Robot และ VR ผ่าน ROS TCP

System Design

System Architectures

ระบบถูกออกแบบในลักษณะ distributed system โดยมี 3 องค์ประกอบหลัก ได้แก่ ตัวหุ่นยนต์ (JetRover), ระบบ VR Interface (Oculus Quest 2) และตัวกลางในการสื่อสาร (ROS2 TCP) ซึ่งทำหน้าที่เชื่อมต่อข้อมูลระหว่างโลกจริงและโลกเสมือน

Flowchart

Command flow (Processing Block)

Command flow แสดงกระบวนการส่งคำสั่งจากผู้ใช้งานใน VR ไปยังหุ่นยนต์ โดยข้อมูลการเคลื่อนที่จาก VR Controller จะถูกแปลงเป็น velocity command และส่งผ่าน ROS2 ไปยังตัวหุ่นยนต์เพื่อควบคุมการเคลื่อนที่

Feedback Flow (Data flow Diagram)

ในทางกลับกัน Feedback flow แสดงการส่งข้อมูลจากหุ่นยนต์กลับมายัง VR เช่น ข้อมูล LiDAR, ภาพจากกล้อง และสถานะของระบบ ซึ่งถูกนำไปแสดงผลในรูปแบบ HUD และ Digital Twin ภายใน Cockpit

Implementation

Unity Setup & Script

Github (Script only): https://github.com/Constantine404/FRA500-Human-Robotics-Interface-Class-Project-VR-Robot-Cockpit

JetRover_ws

Github: https://github.com/ThepokKung/JetRover_ws

ประมาณข้อมูลขารับ (ส่งจาก JetRover)

ข้อมูลรูปที่ใช้ในการส่งข้อมูล width: 640, height: 360, fps: 30, Format: OB_FORMAT_MJPG

ข้อมูล scan ของ LiDAR A1

ข้อมูล Joint ของ JetRover

ข้อมูล Battery

สรุปประมาณข้อมูลที่ใช้งาน

Image = 0.69 MB
LiDAR = 8.70 KB ≈ 0.0087 MB
Joint = 0.28 KB ≈ 0.00028 MB
Battery = 8 B ≈ 0.000008 MB 0.69+0.0087+0.00028+0.000008≈0.699 MB

เมื่อระบบทำงานที่ 30 FPS:

Bandwidth ≈ 0.699 MB × 30 ≈ 20.97 MB/s

≈ 168 Mbps

ซึ่งถือว่าสูงมากสำหรับการใช้งานผ่านเครือข่าย Wi-Fi ทั่วไป และเป็นปัจจัยหลักที่ส่งผลต่อ latency ของระบบ

จากการวิเคราะห์ขนาดข้อมูล พบว่าข้อมูลภาพจากกล้องมีสัดส่วนมากกว่า 98% ของข้อมูลทั้งหมด ขณะที่ข้อมูลประเภทอื่นมีขนาดน้อยมาก

ดังนั้นภาระของเครือข่ายจึงเกิดจาก video streaming เป็นหลัก ซึ่งเป็น bottleneck ของระบบ

ประมาณข้อมูลขาออก (ส่งเข้า JetRover)

ประมาณข้อมูลการส่งการเคลื่อนที่

ประมาณข้อมูลการสั่งงานแขนกล (Joint เดียว)

ตัวอย่างคำสั่ง

ros2 topic pub --once /ros_robot_controller/bus_servo/set_position ros_robot_controller_msgs/msg/ServosPosition "{duration: 1.5, position: [{id: 4, position: 30}]}"

สรุปประมาณข้อมูลที่ใช้งาน

cmd_vel = 52 B
joint_cmd = 68 B 52+68=120 B 120 B ≈ 0.12 KB ≈ 0.00012 MB

สรุปผลข้อมูล

เมื่อเปรียบเทียบข้อมูลระหว่างฝั่ง command (~120 bytes) และ feedback (~0.699 MB) พบว่ามีขนาดแตกต่างกันมากกว่า 5000 เท่า

แสดงให้เห็นว่าระบบมีลักษณะเป็น feedback-heavy system ซึ่งภาระหลักของ network มาจากการส่งข้อมูลกลับจากหุ่นยนต์ ไม่ใช่คำสั่งควบคุม

Network Performance Test

จากการใช้งานพบว่า เมื่อเราใช้งานตอนมีคนอยู่ในเครือข่ายเยอะ พบว่าภาพมีการ Delay ผิดปกติ จากที่ตอนทดสอบระบบแรกๆ ไม่มีผู้ใช้งานในเครืองข่ายมากนึง ทางผู้จัดผมจึงทำการทดลองใช้ Router (D-Link DIR-612) ที่มีอยู่แล้วสลับใช้แทนในการทดลอง

จากการทดลองเปลี่ยนรูปแบบการเชื่อมต่อเครือข่าย พบว่า:

การใช้งานผ่าน Wi-Fi (D-Link DIR-612) มีอาการ delay สูง
การใช้งานผ่าน LAN สามารถลด latency ได้อย่างชัดเจน

สาเหตุเกิดจากข้อจำกัดของ bandwidth และความเสถียรของ Wi-Fi โดย router ที่ใช้งานรองรับ throughput ได้ประมาณ 20–50 Mbps ซึ่งต่ำกว่าความต้องการของระบบ (~168 Mbps)

นอกจากนี้ Wi-Fi ยังมีปัญหา latency jitter และ packet loss ซึ่งส่งผลต่อ video streaming โดยตรง

การใช้งาน JetRover ในตอนนี้

ทางผู้จัดทำได้ทำการสร้าง WS ใหม่ขึ้นมาโดยใช้ ws ใน github https://github.com/Hiwonder/JetRover/tree/Jetson_Orin_ros2 ในการใช้งาน โดยได้ตัด PKG ที่ไม่ได้ใช้ให้เหลือดังนี้ https://github.com/ThepokKung/JetRover_ws

คลิปวีดิโอการทำงาน

System Evaluation

ได้ทำแบบสอบถามจำนวน 20 ข้อ โดยมีคำถามแบ่งคำถามเป็นหัวข้อ

Section 1: System Performance (จำนวน 7 ข้อ) ให้คะแนน 1–5: 1 = แย่มาก, 5 = ดีมาก
Section 2: Usability (จำนวน 7 ข้อ) ให้คะแนน 1–5: 1 = แย่มาก, 5 = ดีมาก
Section 3: Value for Specific Task (จำนวน 6 ข้อ) ให้คะแนน 1–5: 1 = แย่มาก, 5 = ดีมาก

โดยมีรายละเอียดของคำถามแต่ละข้อดังนี้

ระบบตอบสนองต่อการควบคุมได้รวดเร็ว (ไม่มี delay ที่รู้สึกได้)
ภาพจากกล้องมีความลื่นไหล (ไม่กระตุก)
ความหน่วงของภาพ (video delay) อยู่ในระดับที่ยอมรับได้
การควบคุมหุ่นยนต์มีความแม่นยำ
ระบบมีความเสถียรระหว่างใช้งาน (ไม่หลุด/ค้าง)
ข้อมูลสถานะ (แบตเตอรี่) แสดงแบบ real-time ถูกต้อง
ฉันไม่รู้สึกวิงเวียน คลื่นไส้ หรือปวดหัวระหว่างการ/หลังการใช้งาน
เรียนรู้การใช้งานระบบได้ง่าย (Learnability)
เข้าใจการควบคุม Controller ได้รวดเร็ว (Learnability)
สามารถควบคุมหุ่นยนต์ได้อย่างรวดเร็ว (Efficiency)
จำรูปแบบการควบคุมได้ง่าย (Memorability)
เกิดข้อผิดพลาดระหว่างใช้งานน้อย (Errors)
พึงพอใจกับประสบการณ์ใช้งานโดยรวม (Satisfaction)
รู้สึกมั่นใจขณะควบคุมหุ่นยนต์ (Satisfaction)
การเชื่อมต่อกับหุ่นยนต์ทำได้ง่าย
ใช้เวลาในการเชื่อมต่ออยู่ในระดับเหมาะสม
ระบบช่วยให้ควบคุมหุ่นยนต์ไปยังเป้าหมายได้สำเร็จ
ทิศทางการเคลื่อนที่ตรงตามที่สั่ง
ระบบแสดงข้อมูลสถานะ (แบตเตอรี่) ชัดเจน
สามารถรับรู้สถานการณ์ของหุ่นยนต์ได้ง่าย

สรุปผลการทำแบบสอบถาม

System Performance

คะแนนเฉลี่ยรวม: 3.52 / 5.00 ภาพรวมประสิทธิภาพของระบบอยู่ในเกณฑ์ปานกลางค่อนข้างดี โดยมีจุดเด่นและจุดที่ต้องปรับปรุงดังนี้

จุดเด่น: ผู้ใช้งานส่วนใหญ่ให้คะแนนความสบายในการใช้งานสูง (Q7: ไม่วิงเวียนหรือปวดหัว) และระบบแสดงข้อมูลแบตเตอรี่ได้ถูกต้อง (Q6) โดยได้คะแนนเฉลี่ย 4.33 และ 4.00 ตามลำดับ
จุดที่ต้องปรับปรุง (Critical Issue): ความเสถียรของระบบ (Q5: ระบบไม่หลุดหรือค้าง) ได้คะแนนต่ำที่สุดในการประเมินทั้งหมดเพียง 2.00 คะแนน ซึ่งดึงค่าเฉลี่ยในหมวดนี้ลงอย่างมีนัยสำคัญ นอกจากนี้ความแม่นยำในการควบคุม (Q4) ยังได้คะแนนเพียง 3.33 คะแนน ซึ่งควรได้รับการแก้ไขปรับปรุงระบบเครือข่ายหรือซอฟต์แวร์ให้มีความเสถียรมากยิ่งขึ้น

Usability

คะแนนเฉลี่ยรวม: 4.29 / 5.00 นี่คือหมวดที่ได้รับคะแนนสูงที่สุด แสดงให้เห็นว่าระบบถูกออกแบบมาให้เป็นมิตรกับผู้ใช้งาน (User-Friendly) เป็นอย่างมาก

ผู้ทดสอบให้คะแนนสูงถึง 4.33 คะแนน ในเกือบทุกข้อ ไม่ว่าจะเป็นการเรียนรู้ได้ง่าย (Q8, Q9), การควบคุมได้อย่างรวดเร็ว (Q10), การจดจำรูปแบบได้ง่าย (Q11), ตลอดจนความพึงพอใจและความมั่นใจขณะควบคุมหุ่นยนต์ (Q13, Q14)
มีเพียงข้อ Q12 (เกิดข้อผิดพลาดระหว่างใช้งานน้อย) ที่ได้คะแนน 4.00 ซึ่งถือว่ายังอยู่ในเกณฑ์ที่น่าพึงพอใจมาก สรุปได้ว่า UI/UX และ Controller ออกแบบมาได้ตอบโจทย์สรีระและความเข้าใจของมนุษย์ได้เป็นอย่างดี

Values for Specific Task

คะแนนเฉลี่ยรวม: 3.89 / 5.00 ผู้ใช้งานสามารถนำระบบนี้ไปปฏิบัติงานตามเป้าหมาย (Tasks) ต่างๆ ได้ในระดับที่ดี

จุดเด่น: การเชื่อมต่อกับหุ่นยนต์ในช่วงเริ่มต้นทำได้ง่ายมาก (Q15) ได้คะแนนสูงถึง 4.33 รวมถึงระบบช่วยให้การบังคับหุ่นยนต์ไปถึงเป้าหมายได้สำเร็จ (Q16, Q17, Q19) ล้วนได้คะแนนเฉลี่ยที่ 4.00
จุดที่ควรพัฒนา: ทิศทางการเคลื่อนที่ของหุ่นยนต์ตรงตามที่สั่ง (Q18) ได้คะแนนต่ำสุดในหมวดนี้ที่ 3.33 คะแนน ซึ่งอาจมีความเชื่อมโยงกับปัญหาด้านความหน่วง (Delay)

สรุปและข้อเสนอแนะ

จากการประเมิน UX/HRI พบว่า:

จุดเด่น:

ระบบมี learnability สูง ผู้ใช้งานสามารถเรียนรู้การควบคุมได้รวดเร็ว
ความพึงพอใจโดยรวมอยู่ในระดับสูง

ข้อจำกัด:

ความเสถียรของระบบยังต่ำ (connection หลุดบ่อย)
latency ของ video streaming ส่งผลต่อการควบคุม
ความแม่นยำของการควบคุมอยู่ในระดับปานกลาง

แนวทางพัฒนา:

ลด resolution และ frame rate ของ video stream เพื่อลด bandwidth
ใช้ video encoding ที่มีประสิทธิภาพ เช่น H.264 แทน MJPEG
ปรับปรุง network architecture เช่น ใช้ 5GHz Wi-Fi หรือ wired connection
เพิ่ม buffering และ smoothing เพื่อลดผลกระทบจาก latency jitter

Conclusion

โปรเจกต์ VR Robot Cockpit แสดงให้เห็นถึงศักยภาพของการใช้ Virtual Reality ในการควบคุมหุ่นยนต์ โดยสามารถเพิ่มประสบการณ์และ situational awareness ของผู้ใช้งานได้อย่างมีนัยสำคัญ

อย่างไรก็ตาม ผลการวิเคราะห์และการทดลองพบว่าข้อจำกัดหลักของระบบอยู่ที่ network bandwidth โดยเฉพาะการส่งข้อมูลภาพแบบ real-time ซึ่งต้องใช้ bandwidth สูงถึงประมาณ 168 Mbps

ดังนั้น การพัฒนาระบบในอนาคตควรมุ่งเน้นไปที่การลดปริมาณข้อมูลและเพิ่มประสิทธิภาพของการสื่อสาร เพื่อให้สามารถใช้งานได้ในสภาพแวดล้อมจริง

หลังจากไปออกงานที่ Futurium (08/05/2026)

หลังจากที่กลุ่มของพวกเราได้ไปแสดงผลงานที่ Futurium โดยกลุ่มผู้มาใช้งานต่ำกว่าที่คาดหมายเอาไว้ เป็นเด็กเล็กซะส่วนใหญ่ โดยก่อนวันที่จะไปได้ทำการปรับปรุงการทำงานของระบบส่งภาพโดยเปลี่ยนไปใช้ “WebRTC” ในการส่งข้อมูลวีดีโอแทน แต่พบว่าหลังจากใช้งานจริง Rounter ที่นำไปเก่าเกินไปและสู้สัญญาณรบกวนไม่ได้ จึงไม่สามารถใช้งานได้จริง และได้ใช้สาย Lan ในการส่งข้อมูลภาพออกไป

ข้อเสนอแนะเพิ่มเติมหลังจากไปออกงาน

เราได้รับ Feedback ในส่วนของการควบคุมที่อยากควบคุมได้มากกว่านี้ ในผู้มาใช้งานที่เป็นกลุ่มเด็กโต และผู้ใหญ่ เนื่องจากผู้จัดทำได้ทำการ Limit การควบคุมไว้ที่ หมุนกล้องซ้ายขวาเท่านั้น เพื่อความง่ายในการควบคุม และ UI ที่ค่อนข้างใกล้ ผู้ใช้บางคนชอบบางคนไม่ชอบ จึงถูกนำเสนอให้สามารถปรับ Cockpit ในรูปแบบของตัวเองได้ และแบตรเตอร์รี่ที่น้อยเกินไป ทำให้เด็กบางคนไม่สามารถเล่นได้เนื่องจากแบตเตอร์รี่หมดก่อน

ผู้พัฒนา

65340500004 นายไกรวิชญ์ วิชาโคตร

ทำหน้าที่

Mobile Robot Development
Unity Development

65340500005 นายคณพล กาจธัญกิจ

ทำหน้าที่

Unity Development