กลับไปยังบล็อก BIM และ IFC
ดิจิทัลทวิน · 2026-08-21 · 12 นาที
LiDAR แบบเรียลไทม์ + IFC บนเบราว์เซอร์: เดโมการเล่นซ้ำ MCAP
ลองใช้อินเทอร์เฟซเล่นซ้ำบนเว็บตัวจริง และเรียนรู้บัฟเฟอร์แบบจำกัดขนาด เฟรมไบนารี และข้อมูลเทเลเมทรี (telemetry) ที่อยู่เบื้องหลังสตรีม IFC + LiDAR ซึ่งระบุอย่างตรงไปตรงมาว่าเป็นข้อมูลจำลอง
ภาพปกที่มีชื่อเรื่อง “Real-Time LiDAR and IFC” วางบนภาพหน้าจอจริงของโปรแกรมดู ซึ่งแสดงการเล่นซ้ำข้อมูลเชิงเวลาแบบจำลองที่จัดแนวตรงกับอาคารพาวิลเลียน
วิดีโอของพอยต์คลาวด์ (point cloud) กับสตรีมพอยต์คลาวด์แบบสดไม่ใช่ผลิตภัณฑ์เดียวกัน วิดีโอมีพิกเซลตายตัวและมีตัวเข้ารหัสฮาร์ดแวร์ (hardware codec) ที่พัฒนามาเต็มที่แล้ว ส่วนพอยต์คลาวด์เชิงเวลามีพิกัด แอตทริบิวต์ ท่าทาง (pose) และเวลาประทับ ที่ผู้ใช้อาจตรวจดูหรือเปรียบเทียบกับ IFC ความยืดหยุ่นนี้ทำให้ปัญหาด้านการส่งข้อมูลและหน่วยความจำยากขึ้น
สถาปัตยกรรมด้านล่างมองไฟล์บันทึกและแหล่งข้อมูลสดเป็นอะแดปเตอร์สองตัวที่ป้อนข้อมูลเข้าสู่ข้อกำหนดเฟรม (frame contract) แบบจำกัดขนาดชุดเดียวกัน ทำให้ทีมตรวจสอบการเล่น การเลื่อนหาตำแหน่ง (seek) การจัดการข้อมูลเสียหาย และการอัปเดต GPU ด้วยข้อมูลที่บันทึกไว้ได้ ก่อนจะซื้อหรือผสานรวมเซนเซอร์
เบราว์เซอร์รับเฉพาะเฟรมที่จำกัดขนาดและผ่านการตรวจสอบแล้ว ส่วนการกรองข้อมูลและการปรับพิกัดให้เป็นมาตรฐานควรทำที่ฝั่ง edge
ทดลองการเล่นซ้ำ IFC + LiDAR เชิงเวลา
ตัวอย่างสดต่อไปนี้สร้างแนวการสแกน (scan front) แบบกำหนดผลได้แน่นอนรอบอาคารพาวิลเลียน IFC ที่สอดคล้องกัน เฟรมเดียวกันจะผ่านการเข้ารหัสแบบไบนารี การตรวจสอบ CRC และบัฟเฟอร์การส่งข้อมูลขนาดคงที่ 3 ช่อง ก่อนจะถึง GPU สลับไปยังโปรแกรมดูเต็มรูปแบบเพื่อจำลองการสูญหายของเฟรม การสลับลำดับ ข้อมูลเสียหาย และช่วงการเชื่อมต่อใหม่ แบบกำหนดผลได้แน่นอน
อาคาร Operations Pavilion — LiDAR เชิงเวลาแบบจำลอง
การสแกนจำลองความยาว 16 วินาทีที่ 12 FPS ซึ่งจัดแนวตรงกับอาคารพาวิลเลียน IFC4 ที่มาพร้อมกับโปรแกรม ตัวอย่างนี้พิสูจน์ไปป์ไลน์การเล่น ไม่ได้อ้างว่ามาจากเซนเซอร์จริง
LiDAR แบบจำลองกำลังเล่น — ลากเพื่อหมุนมุมมอง
ภาพหน้าจอจากผลิตภัณฑ์จริง: แหล่งข้อมูลเชิงเวลาเป็นการเล่นซ้ำแบบจำลองที่กำหนดผลได้แน่นอน ส่วนการแยกวิเคราะห์ การบัฟเฟอร์ การอัปเดต GPU และการจัดแนวกับ IFC ทำงานในโปรแกรมดูตัวจริง
ข้อกำหนดขั้นต่ำของเฟรม
แพ็กเก็ตที่ใช้ส่งข้อมูลต้องมีมากกว่าค่า XYZ หมายเลขลำดับ (sequence number) ช่วยเผยให้เห็นการสูญหายและการสลับลำดับ เวลาประทับระดับนาโนวินาทีช่วยจัดจุดให้ตรงกับวิดีโอ ท่าทาง และคำอธิบายประกอบ (annotation) จุดกำเนิด (origin) ที่ประกาศไว้ช่วยไม่ให้พิกัดโลกที่มีค่าสูงเข้าไปอยู่ในเวอร์เท็กซ์ Float32 บน GPU และแฟล็กแอตทริบิวต์ช่วยป้องกันไม่ให้ UI แสดงราวกับว่ามีค่าความเข้ม (intensity) หรือการจำแนกประเภท (classification) ทั้งที่แหล่งข้อมูลไม่เคยให้มา
| ฟิลด์ | มีไว้เพื่ออะไร | ความผิดพลาดที่ตรวจจับได้ |
|---|
| sequence | ตัวระบุเฟรมที่เพิ่มขึ้นทางเดียว (monotonic) | การสูญหาย ซ้ำ หรือสลับลำดับ |
| timestampNs | จุดอ้างอิงเวลาร่วม | การเหลื่อมกับวิดีโอ/ท่าทาง |
| origin + bounds | ความแม่นยำของพิกัดเฉพาะที่และการคัดทิ้ง (culling) | การสั่นไหว (jitter) หรือการจองหน่วยความจำที่ผิดปกติ |
| pointCount + stride | งบประมาณขนาดเพย์โหลด (payload) | แพ็กเก็ตที่ถูกตัดทอนหรือเป็นอันตราย |
| แฟล็กแอตทริบิวต์ (attribute flags) | ความหมายที่ระบุชัดเจน | RGB/ค่าความเข้ม/คลาสที่ถูกสร้างขึ้นเอง |
| CRC32 | ความสมบูรณ์ของเพย์โหลด | ข้อมูลเสียหายระหว่างจัดเก็บหรือส่ง |
แรงดันย้อนกลับ (backpressure): เฟรมล่าสุดที่ถูกต้องชนะ
สตรีมเครือข่ายที่เชื่อถือได้ก็ยังให้ประสบการณ์แบบสดที่แย่ได้ หากการถอดรหัสใช้เวลา 120 ms ขณะที่เฟรมมาถึงทุก 80 ms คิวแบบปกติจะยาวขึ้นไม่สิ้นสุด และโปรแกรมดูจะกลายเป็นการเล่นบันทึกที่ล่าช้า นโยบายที่ถูกต้องสำหรับข้อมูลสดคือการจำกัดขนาด ได้แก่ เก็บช่องที่นำกลับมาใช้ซ้ำได้ไว้ 2–3 ช่อง ปฏิเสธเฟรมที่ไม่ถูกต้อง ทิ้งงานที่ค้างอยู่ซึ่งถูกแทนที่แล้ว และแสดงความหน่วงและจำนวนเฟรมที่ถูกทิ้งให้ผู้ใช้เห็น
คิวไม่จำกัดขนาด
- ความหน่วงเพิ่มขึ้นในช่วงที่ระบบช้า
- เฟรมเก่ากินหน่วยความจำและเวลาของตัวถอดรหัส
- UI ยังแสดงว่าเชื่อมต่ออยู่ ขณะที่ภาพที่เห็นเป็นอดีต
- การฟื้นตัวอาจใช้เวลานานกว่าตัวเหตุการณ์เอง
บัฟเฟอร์สดแบบจำกัดขนาด
- หน่วยความจำคงที่
- เฟรมที่ถูกต้องล่าสุดเข้าแทนที่งานที่ล้าสมัย
- จำนวนเฟรมที่ถูกทิ้งและอายุของเฟรมยังมองเห็นได้
- ฟื้นตัวทันทีเมื่อระบบกลับมามีกำลังพอ
MCAP สำหรับการบันทึกและการเล่นซ้ำที่ทำซ้ำได้
MCAP เป็นคอนเทนเนอร์แบบโมดูลาร์สำหรับข้อความแบบ publish/subscribe ที่มีเวลาประทับ และใช้การแปลงข้อมูล (serialization) แบบใดก็ได้ ชังก์ (chunk) และดัชนีของไฟล์รองรับการค้นหาตามเวลาและหัวข้อ (topic) ซึ่งตรงกับสิ่งที่ไทม์ไลน์การเล่นซ้ำต้องการพอดี ข้อกำหนดรูปแบบไฟล์ MCAP อธิบายโครงสร้างคอนเทนเนอร์และระเบียนสรุปสำหรับการเข้าถึงแบบสุ่ม (random access)
การเข้ากันได้ระดับคอนเทนเนอร์ไม่ได้หมายถึงการเข้ากันได้ระดับข้อความ ROS เผยแพร่จุดแบบมีโครงสร้าง (organized) หรือแบบไม่เรียงลำดับผ่าน sensor_msgs/PointCloud2 ส่วน Foxglove กำหนดสคีมา PointCloudของตัวเอง MCAP ของเดโมใช้เพย์โหลดของแอปพลิเคชันที่มีการกำหนดเวอร์ชัน ดังนั้นการนำเข้าจากระบบนิเวศใดก็ตามต้องใช้อะแดปเตอร์ที่ระบุชื่อไว้ชัดเจน ไม่ใช่การแปลงชนิดไบต์ (byte casting) แล้วหวังว่าจะใช้ได้
เริ่มจากข้อมูลที่บันทึกไว้
ชุดข้อมูลทดสอบ (fixture) ที่มีสิทธิ์การใช้งานถูกต้องทำให้การหยุดชั่วคราว การเลื่อนหาตำแหน่ง การเชื่อมต่อใหม่ และการทดสอบถดถอย (regression test) ทำซ้ำได้ ก่อนการผสานรวมกับฮาร์ดแวร์
ตามด้วยอะแดปเตอร์ข้อมูลสด
WebSocket หรือ WebTransport เปลี่ยนเพียงวิธีส่งข้อมูล ไม่ได้เปลี่ยนความหมายของเฟรมที่ตัวเรนเดอร์ใช้
เทเลเมทรีที่มองเห็นได้
ความหน่วง อายุเฟรม การสูญหาย การสลับลำดับ แพ็กเก็ตที่ไม่ถูกต้อง และการเชื่อมต่อใหม่ ควรแสดงอยู่ใน UI ของผลิตภัณฑ์
การจำลองข้อผิดพลาด (fault injection)
ข้อผิดพลาดแบบกำหนดผลได้แน่นอนเปลี่ยน Wi-Fi ที่ล่มในงานสัมมนาจากเรื่องไม่คาดคิด ให้กลายเป็นการเปลี่ยนสถานะที่ซ้อมมาแล้ว
สำหรับบริบทจากการวัดแบบคงที่ กลับไปดูขั้นตอนการทำงาน Scan-to-BIM ด้วย IFC + พอยต์คลาวด์ ส่วนทรัพยากรแบบพิกเซลที่ใช้ตัวเข้ารหัสวิดีโอฮาร์ดแวร์ได้และยังอยู่ในฉาก 3 มิติได้ ดูIFC + วิดีโอบนภูมิประเทศ 3 มิติ
LiDAR แบบเรียลไทม์ + IFC บนเบราว์เซอร์: เดโมการเล่นซ้ำ MCAP