> For the complete documentation index, see [llms.txt](https://taiphoon-com.gitbook.io/taiphoon.com-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://taiphoon-com.gitbook.io/taiphoon.com-docs/th/support/knowledge-base/can-bus.md). # CAN Bus ### CAN Bus คืออะไร CAN (Controller Area Network) คือบัสการสื่อสารแบบใช้สายที่ออกแบบมาสำหรับสภาพแวดล้อมที่มีสัญญาณรบกวน เดิมใช้ในระบบอิเล็กทรอนิกส์ยานยนต์ ปัจจุบันยังใช้อย่างแพร่หลายในการสื่อสารระหว่างตัวควบคุมการบิน เซนเซอร์ GPS, ESC และอุปกรณ์ต่อพ่วงอื่น ๆ บนอากาศยาน มอเตอร์ ESC โมดูลจ่ายไฟ และอุปกรณ์ไร้สายล้วนอาจสร้างสัญญาณรบกวนทางแม่เหล็กไฟฟ้าอย่างชัดเจน เหตุผลสำคัญที่ CAN ถูกใช้บ่อย คือในสภาพแวดล้อมเช่นนี้ CAN มักเสถียรกว่าการสื่อสารอนุกรมแบบ Single-ended ทั่วไป ### คุณลักษณะหลักของ CAN คุณลักษณะที่สำคัญที่สุดของ CAN คือการใช้สถาปัตยกรรม**สัญญาณดิฟเฟอเรนเชียล (Differential Signal)** และ**บัสที่ใช้ร่วมกัน** หมายความว่าอุปกรณ์หลายตัวสามารถใช้สาย CAN\_H และ CAN\_L ชุดเดียวกัน โดยฝั่งรับจะอ่านค่าความต่างศักย์ระหว่างสายทั้งสอง จึงมีความสามารถสูงในการต้านทานสัญญาณรบกวนที่ส่งผลต่อทั้งสองสายพร้อมกัน ### สัญญาณดิฟเฟอเรนเชียลคืออะไร CAN ใช้สายข้อมูลสองเส้น: **CAN\_H** และ **CAN\_L** ขณะส่งข้อมูล สัญญาณบนสายทั้งสองจะเปลี่ยนแปลงในทิศทางตรงข้ามกัน ฝั่งรับไม่ได้ดูเพียงแรงดันสัมบูรณ์ของสายใดสายหนึ่ง แต่ดูผลต่างระหว่างสายทั้งสอง ข้อดีของวิธีนี้คือ หากสัญญาณรบกวนภายนอกคัปเปิลเข้าสู่สายทั้งสองพร้อมกัน สัญญาณรบกวนโหมดร่วม (Common-mode) บนสายทั้งสองจะใกล้เคียงกัน เมื่อฝั่งรับคำนวณผลต่างจึงสามารถหักล้างสัญญาณรบกวนประเภทนี้ได้มาก ดังนั้น CAN จึงยังคงความน่าเชื่อถือได้ดีแม้อยู่ใกล้มอเตอร์ ESC และระบบกระแสสูง ### ความแตกต่างระหว่าง CAN กับ UART / I2C CAN, UART และ I2C ล้วนใช้เชื่อมต่ออุปกรณ์ต่อพ่วงของตัวควบคุมการบินได้ แต่มีจุดประสงค์และแนวคิดการออกแบบที่แตกต่างกัน | อินเทอร์เฟซ | โครงสร้างทั่วไป | ข้อดี | การใช้งานที่พบบ่อย | | ----------- | ------------------------------ | -------------------------------------------------------------------- | ----------------------------------------- | | UART | จุดต่อจุด | เรียบง่าย พบทั่วไป กำหนดค่าง่าย | GPS เทเลเมทรี ตัวรับสัญญาณ คอนโซลดีบัก | | I2C | อุปกรณ์หลายตัวใช้สองสายร่วมกัน | เหมาะสำหรับเซนเซอร์บนบอร์ดระยะสั้นหรือระยะใกล้ | เข็มทิศ บารอมิเตอร์ เซนเซอร์อย่างง่าย | | CAN | หลายโหนดใช้บัสร่วมกัน | ทนต่อสัญญาณรบกวนสูง เหมาะกับระยะทางไกลและการรวมอุปกรณ์ต่อพ่วงหลายตัว | CAN GPS, CAN ESC, เซนเซอร์ CAN, โมดูลโหนด | ### โทโปโลยีของบัส CAN เป็น**บัสแบบหลายจุด (Multi-drop)** อย่างแท้จริง ทุกโหนดต่ออยู่บนสายหลักชุดเดียวกัน โหนดใดก็อาจส่งข้อมูลได้ และทุกโหนดสามารถรับเฟรมบนบัสได้ ในการใช้งานกับตัวควบคุมการบิน วิธีที่พบบ่อยคือต่อตัวควบคุมการบิน GPS เซนเซอร์ ESC หรือโหนดอื่น ๆ แบบอนุกรม (Daisy-chain) เรียงต่อกันบนสายหลัก CAN เดียวกัน แทนที่จะเดินสาย TX/RX แยกกันสำหรับแต่ละอุปกรณ์เหมือน UART ### กลไกการอนุญาตใช้บัส (Arbitration) เนื่องจากหลายโหนดใช้บัสเดียวกัน โปรโตคอล CAN จึงมีกลไกการอนุญาตใช้บัสในตัว เมื่ออุปกรณ์ต้องการส่งข้อมูลพร้อมกัน จะตัดสินว่าใครส่งก่อนตามลำดับความสำคัญของเฟรม นี่เป็นหนึ่งในเหตุผลที่ CAN เหมาะกับงานควบคุมแบบเรียลไทม์ ไม่ได้อาศัยหลัก "มาก่อนได้ก่อน" แบบเสี่ยงโชค แต่ให้ชั้นโปรโตคอลเป็นผู้ตัดสินว่าข้อความใดควรได้อยู่บนบัสก่อน ### ตัวต้านทานปลายสาย (Termination Resistor) บัส CAN ที่ทำงานปกติต้องมี**ตัวต้านทานปลายสาย 120 โอหม์**อยู่ที่**ปลายทั้งสองด้านทางกายภาพ**ด้านละหนึ่งตัว ตัวต้านทานปลายสายทำหน้าที่ดูดซับการสะท้อนของสัญญาณ หากไม่มีการต่อปลายสายอย่างถูกต้อง สัญญาณที่สะท้อนกลับมาจากปลายสายอาจทำให้ข้อมูลผิดเพี้ยน โหนดปรากฏและหายไปเป็นระยะ หรือการสื่อสารไม่สม่ำเสมอ ### วิธีตรวจสอบว่าการต่อปลายสายถูกต้องหรือไม่ หากปลายทั้งสองด้านของบัสมีตัวต้านทานปลายสาย 120 โอหม์ด้านละหนึ่งตัว เมื่อตัดไฟทั้งระบบแล้ววัดความต้านทานระหว่าง CAN\_H กับ CAN\_L โดยทั่วไปควรได้ใกล้เคียง **60 โอหม์** เนื่องจากตัวต้านทาน 120 โอหม์สองตัวต่อกันแบบขนาน นี่เป็นวิธีตรวจสอบอย่างรวดเร็วที่ใช้งานได้จริงมากในการแก้ไขปัญหาหน้างาน หากวัดได้ค่าที่เบี่ยงเบนจาก 60 โอหม์มาก โดยทั่วไปหมายความว่าจำนวนตัวต้านทานปลายสายไม่ถูกต้อง การต่อสายผิด หรือการตั้งค่าตัวต้านทานปลายสายในตัวของบางโหนดไม่ถูกต้อง ### ข้อผิดพลาดที่พบบ่อยเกี่ยวกับตัวต้านทานปลายสาย ปัญหา CAN ที่พบบ่อยที่สุดคือการกำหนดตัวต้านทานปลายสายไม่ถูกต้อง กรณีที่พบบ่อย ได้แก่: * ไม่มีตัวต้านทานปลายสายเลย ทำให้เกิดการสะท้อนรุนแรง * ทุกโหนดเปิดใช้ตัวต้านทานปลายสาย ทำให้อิมพีแดนซ์รวมต่ำเกินไป * ตัวต้านทานปลายสายไม่ได้อยู่ที่ปลายสุดทางกายภาพ แต่อยู่ที่โหนดตรงกลาง หลักที่ถูกต้องนั้นง่ายมาก: **เฉพาะปลายทั้งสองด้านของบัสเท่านั้นที่ต้องมีตัวต้านทานปลายสาย** โดยทั่วไปโหนดตรงกลางไม่ควรมีตัวต้านทานปลายสายเพิ่มอีก ### อัตราบิต (Bit Rate) ในระบบนิเวศตัวควบคุมการบินทั่วไป อัตราบิตที่ใช้บ่อยของ CAN คือ **1 Mbps** ซึ่งเป็นค่าเริ่มต้นที่พบบ่อยของเฟิร์มแวร์ตัวควบคุมการบินและอุปกรณ์ต่อพ่วง DroneCAN จำนวนมาก ต่างจาก UART โดยทั่วไปไม่จำเป็นต้องเปลี่ยนอัตราบิตของ CAN บ่อย ๆ แต่ทุกโหนดต้องใช้อัตราบิตเดียวกัน มิฉะนั้นอุปกรณ์ที่ตั้งค่าผิดมักจะมองไม่เห็นเลยบนบัส ### ขั้วต่อและสายสัญญาณ ในระบบตัวควบคุมการบินจำนวนมาก CAN มักใช้ขั้วต่อ **4-pin JST-GH** โดยมีขาทั่วไปคือ 5V, CAN\_H, CAN\_L, GND อย่างไรก็ตาม แม้รูปแบบขั้วต่อจะพบบ่อย ก็ไม่ได้รับประกันว่าทุกอุปกรณ์จะเหมือนกันทุกประการ ก่อนต่อสายจริง ยังควรตรวจสอบนิยามขา แรงดันไฟเลี้ยง และการรองรับการจ่ายไฟผ่านบัสของอุปกรณ์นั้น ### การจ่ายไฟไม่ได้เกิดขึ้นโดยอัตโนมัติ สาย CAN มักมี 5V และ GND มาด้วย เพื่อความสะดวกในการจ่ายไฟให้อุปกรณ์ต่อพ่วงที่ใช้พลังงานต่ำ แต่ไม่ได้หมายความว่าทุกอุปกรณ์เหมาะที่จะรับไฟจากบัสโดยตรง หากบัสมีจำนวนโหนดมาก สายยาว หรืออุปกรณ์บางตัวใช้ไฟมาก แรงดันตกคร่อมอาจทำให้อุปกรณ์ต่อพ่วงเริ่มทำงานไม่เสถียร รีบูตซ้ำ หรือหลุดการเชื่อมต่อเป็นระยะ ดังนั้นในการใช้งานจริงควรประเมินงบประมาณกระแสและการสูญเสียในสายก่อน ### เหตุใด CAN จึงเหมาะกับอุปกรณ์ต่อพ่วงของตัวควบคุมการบิน สำหรับอุปกรณ์ต่อพ่วงของตัวควบคุมการบิน ข้อดีของ CAN ไม่ได้มีเพียงการทนต่อสัญญาณรบกวนเท่านั้น ข้อดีที่พบบ่อย ได้แก่: * อุปกรณ์หลายตัวใช้บัสเดียวกัน ขยายระบบได้สะดวก * สามารถรายงานสถานะของอุปกรณ์ได้ ไม่ใช่เพียงรับข้อมูลทิศทางเดียว * เหมาะกับการเดินสายระยะไกลกว่าและสภาพแวดล้อมที่มีสัญญาณรบกวนสูงกว่า * สามารถจัดการโหนด ตั้งค่าพารามิเตอร์ และอัปเดตเฟิร์มแวร์บางส่วนผ่านบัสได้ ### DroneCAN คืออะไร ในการใช้งานกับตัวควบคุมการบิน CAN เป็นเพียงวิธีการสื่อสารในชั้นกายภาพและชั้นเชื่อมโยงข้อมูลระดับล่าง สิ่งที่กำหนดจริง ๆ ว่า "เนื้อหาข้อมูลแสดงอย่างไร จัดการโหนดอย่างไร และกำหนดค่าพารามิเตอร์อย่างไร" มักเป็นโปรโตคอลชั้นบน เช่น **DroneCAN** DroneCAN สามารถมองได้ว่าเป็นโปรโตคอลชั้นแอปพลิเคชันที่ทำงานบน CAN โดยกำหนดรูปแบบข้อความมาตรฐาน วิธีจัดการโหนด การจัดสรรหมายเลขโหนดแบบไดนามิก การเข้าถึงพารามิเตอร์ และกระบวนการอัปเดตเฟิร์มแวร์ของอุปกรณ์ ทำให้อุปกรณ์ที่เข้ากันได้จากผู้ผลิตต่างกันทำงานร่วมกันบนบัสเดียวกันได้ง่ายขึ้น ### Node ID ในสถาปัตยกรรม DroneCAN แต่ละโหนดต้องมี **Node ID** ที่ไม่ซ้ำกัน ช่วงที่ใช้ได้ทั่วไปคือ 1 ถึง 127 ในเฟิร์มแวร์ตัวควบคุมการบินจำนวนมาก ระบบสามารถจัดสรรหมายเลขโหนดให้อัตโนมัติ ซึ่งช่วยลดความยุ่งยากในการผสานระบบครั้งแรก แต่หากผู้ใช้กำหนดหมายเลขเอง ต้องหลีกเลี่ยงไม่ให้อุปกรณ์ต่างกันมี Node ID ซ้ำกัน มิฉะนั้นโหนดจะรบกวนกันเอง ### การจัดสรรโหนดแบบไดนามิก ข้อดีของการจัดสรรโหนดแบบไดนามิกคือ เมื่อต่ออุปกรณ์ใหม่เข้ากับบัส อาจไม่จำเป็นต้องกำหนดหมายเลขตายตัวด้วยตนเองก่อน ก็สามารถถูกตัวควบคุมการบินตรวจพบและรวมเข้าสู่ระบบได้ สิ่งนี้มีประโยชน์มากในการประกอบจริง โดยเฉพาะเมื่อผสานเซนเซอร์หรือโมดูลหลายตัวพร้อมกัน แต่หากการกำหนดค่าระบบคงที่ ยังมักแนะนำให้กำหนดหมายเลขโหนดที่สำคัญให้คงที่หลังจากยืนยันว่าทำงานปกติแล้ว เพื่อลดความเสี่ยงจากการเปลี่ยนแปลงเมื่อจัดเครือข่ายใหม่ในภายหลัง ### CAN สำรอง (Redundant CAN) ตัวควบคุมการบินและอุปกรณ์ต่อพ่วงบางรุ่นรองรับอินเทอร์เฟซ CAN ชุดที่สอง ซึ่งสามารถสร้างช่องสัญญาณสำรองเพื่อเพิ่มความน่าเชื่อถือของการเชื่อมต่อโดยรวม นี่ไม่ใช่ฟังก์ชันที่ทุกระบบจำเป็นต้องใช้ แต่สำหรับอากาศยานขนาดใหญ่ ยานพาหนะสำหรับภารกิจสำคัญ หรือระบบที่มีสายยาว สถาปัตยกรรม CAN คู่สามารถให้ความสามารถในการทนต่อความผิดพลาดที่สูงขึ้น ### ปัญหาที่พบบ่อย ปัญหาทั่วไปของบัส CAN มักเกิดในไม่กี่จุด: * **ไม่มีตัวต้านทานปลายสาย**: โหนดจะปรากฏและหายไปเป็นครั้งคราว * **ตัวต้านทานปลายสายมากเกินไป**: อิมพีแดนซ์ต่ำเกินไป คุณภาพการสื่อสารลดลง * **อัตราบิตไม่ตรงกัน**: มองไม่เห็นบางโหนดเลย * **Node ID ซ้ำกัน**: สองโหนดที่ใช้หมายเลขเดียวกันจะรบกวนกัน * **จ่ายไฟไม่เพียงพอ**: อุปกรณ์อาจไม่เสถียร รีบูต หรือหลุดการเชื่อมต่อแบบสุ่ม * **สายยาวเกินไปหรือเดินสายไม่ดี**: แม้ CAN จะทนต่อสัญญาณรบกวนได้ดีกว่า แต่ก็ยังมีขีดจำกัดทางกายภาพ ### ลำดับการแก้ไขปัญหาที่แนะนำ หากอุปกรณ์ CAN ไม่ทำงานตามปกติ แนะนำให้ตรวจสอบตามลำดับต่อไปนี้: 1. ตรวจสอบว่าทิศทางการต่อสาย CAN\_H, CAN\_L, 5V, GND ถูกต้อง 2. ตรวจสอบว่าปลายทั้งสองด้านของบัสมีตัวต้านทานปลายสาย 120 โอหม์ด้านละหนึ่งตัว 3. วัดความต้านทานระหว่าง CAN\_H กับ CAN\_L ขณะตัดไฟระบบ ว่าได้ประมาณ 60 โอหม์หรือไม่ 4. ตรวจสอบว่าอัตราบิตของทุกโหนดตรงกัน 5. ตรวจสอบว่าไม่มี Node ID ซ้ำกัน 6. ตรวจสอบว่าการจ่ายไฟบนบัสเพียงพอ โดยเฉพาะในระบบที่มีหลายโหนด 7. หากจำเป็น ให้ใช้เครื่องมือตรวจสอบที่รองรับ CAN/DroneCAN ดูว่ามีโหนดออนไลน์และมีปริมาณเฟรมหรือไม่ ### ข้อควรระวัง **ข้อควรระวัง:** การต่อ CAN เป็นแบบบัส ไม่ใช่การเดินสายแบบดาว (Star) หากแยกโหนดจำนวนมากออกจากจุดศูนย์กลางเป็นวงกว้าง จะทำลายคุณลักษณะของบัสและเพิ่มความเสี่ยงของการสะท้อนได้ง่าย **ข้อควรระวัง:** ควรมีตัวต้านทานปลายสายเฉพาะที่ปลายทั้งสองด้านทางกายภาพเท่านั้น อย่าเปิดใช้งานทั้งหมดเพียงเพราะทุกอุปกรณ์มีตัวต้านทานปลายสายในตัว **ข้อควรระวัง:** CAN ทนต่อสัญญาณรบกวนได้ดีกว่า UART แต่ไม่ได้หมายความว่าจะไม่ได้รับผลกระทบจากการเดินสายเลย ความยาวสาย คุณภาพขั้วต่อ คุณภาพแหล่งจ่ายไฟ และโทโปโลยีของบัสยังคงส่งผลโดยตรงต่อความน่าเชื่อถือ