การเขียนโปรแกรมแบบเรียลไทม์ในวิทยาการหุ่นยนต์เป็นอย่างไร [ปิด]

แก้ไข:ฉันไม่รู้ว่าทำไม แต่คำถามนี้ดูเหมือนจะทำให้หลายคนสับสน ฉันทราบว่าเมื่อใด / ที่ไหน / ทำไม / วิธีใช้แบบเรียลไทม์ ฉันสนใจที่จะรู้ว่าคนที่มีภารกิจแบบเรียลไทม์จะสนใจพอที่จะใช้งานแบบเรียลไทม์หรือไม่

ไม่จำเป็นต้องพูดถึงว่าทำไมการทำงานแบบเรียลไทม์จึงมีความสำคัญสำหรับหุ่นยนต์ อย่างไรก็ตามคำถามของฉันมันใช้กับหุ่นยนต์จริงแค่ไหน?

ใช้คำถามนี้เช่น มีเพียงหนึ่งคำตอบที่กล่าวถึงแพลตฟอร์มที่มีความสามารถแบบเรียลไทม์และอยู่ไกลจากจุดสูงสุด ROS เห็นได้ชัดว่าเป็นแพลตฟอร์มที่ได้รับความนิยมมากซึ่งไม่ใช่แบบเรียลไทม์

อย่างไรก็ตามในโลกตามเวลาจริง RTAI ¹น่าจะเป็นแพลตฟอร์มการใช้งานฟรีแบบเรียลไทม์ที่ใช้งานได้เท่านั้น อย่างไรก็ตามลินุกซ์ (ไม่มีปัญหา) มีเอกสารไม่ดีและมีการพัฒนาอย่างช้าๆ

ดังนั้นพฤติกรรมตามเวลาจริงของผู้พัฒนาหุ่นยนต์เป็นที่ต้องการมากแค่ไหน?คำถามคือผู้พัฒนามีแนวโน้มที่จะเขียนแอปพลิเคชันตามเวลาจริงมากน้อยเพียงใดเมื่อต้องการใช้พฤติกรรมตามเวลาจริง ถ้าไม่มากทำไม

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

¹หรือ Xenomai ในทำนองเดียวกัน

จำได้ว่ามีเป็นแบบ Real Timeและมีเวลาจริง

ฮาร์ดเรียลไทม์ทำได้ยากโดยไม่มีการสนับสนุนฮาร์ดแวร์หรือการสนับสนุนซอฟต์แวร์ระดับต่ำ แต่บ่อยครั้งที่คุณไม่ต้องการทุกสิ่งที่จะสามารถใช้ฮาร์ดเรียลไทม์ได้ Soft & Firm การตอบสนองแบบเรียลไทม์นั้นง่ายกว่ามากที่จะบรรลุและมักจะเพียงพอสำหรับแอพพลิเคชั่นมากมาย

นอกจากนี้ส่วนต่าง ๆ ของระบบอาจมีความต้องการตามเวลาจริงที่แตกต่างกันมาก หากคุณใช้ PID ลูปซอฟต์แวร์พวกเขาควรได้รับการตอบสนองแบบเรียลไทม์อย่างหนัก (คุณไม่ต้องการให้เลือกระหว่างการปรับจูน PID ของคุณแบบนุ่มนวลหรือปรับจูนอย่างหนักและทำให้บางครั้งมันไม่เสถียร) ระบบการมองเห็นอาจมีความต้องการการตอบสนองแบบเรียลไทม์ที่มีประสิทธิภาพการทำงานจะลดลงหากคุณไม่สามารถประมวลผลภาพได้ทันเวลาสำหรับการตัดสินใจครั้งต่อไป แต่ไม่จำเป็นต้องป้องกันไม่ให้ระบบทำงานในกรณีนี้หากคุณไม่สามารถประมวลผลได้ทันเวลา เป็นการดีกว่าที่จะละทิ้งผลลัพธ์บางส่วนและไม่เสียเวลาในการวิเคราะห์เริ่มต้นในเฟรมถัดไป ในที่สุดการวางแผนโดยรวมและการประสานงานของคุณ (อาจซับซ้อนที่สุดส่วนหนึ่งของระบบหุ่นยนต์ของคุณ) มักจะยังคงอยู่อย่างมั่นคงในโดเมนของเวลาจริงนุ่ม

แม้จะอยู่ในขอบเขตของพีซี Windows คุณสามารถรับประสิทธิภาพแบบเรียลไทม์ได้คุณเพียงแค่ต้องการซอฟต์แวร์ที่เหมาะสมพร้อมกับขอเกี่ยวกับเคอร์เนล TwinCat ของ PLC ของBeckhoffค่อนข้างมีความสุขเป็นอย่างยิ่งที่มีอัตราการสแกนสูงโดยการแบ่ง PLC ของครึ่งหนึ่งของรอบการทำงานของ Pentium ออกให้ครึ่งหนึ่งกับ Windows NT และนี่เป็นเวลากว่าทศวรรษที่ผ่านมา แม้แต่ระบบควบคุมที่ทันสมัยเช่นตัวเลือกบางตัวในช่วง A3200 ของ Aerotech ก็ทำผลงานได้ดีบนโฮสต์พีซีด้วยเคอร์เนลระดับต่ำที่ใช้เวลา CPU มากที่สุดเท่าที่จำเป็นสำหรับความต้องการแบบเรียลไทม์และออกจากรอบ CPU ที่เหลือสำหรับ Windows 7 ใช้!

ไม่จำเป็นต้องใช้ระบบเรียลไทม์สำหรับระบบควบคุมหุ่นยนต์ (ส่วนใหญ่) ตราบใดที่คุณมีลูปควบคุมที่ทำงานเร็วพอมีกระวนกระวายใจต่ำและไม่พลาดรอบมากเกินไปนี่ก็เพียงพอแล้วสำหรับการควบคุมหุ่นยนต์และเซอร์โว

จากหลักฐานนี้ขอให้ฉันนำเสนอ PR2 และมือหุ่นยนต์เงา:

หุ่นยนต์นี้มีอิสระประมาณ 20 องศาซึ่งทั้งหมดนี้จะถูกนำไปใช้ในวงหลักของ ROS หรือวิธีการเกี่ยวกับ Shadow Robot Hand ซึ่งมี 20 อานนท์รวมถึงชุดตรวจจับและเซ็นเซอร์อื่น ๆ และยังให้บริการผ่านลูปหลักของ ROS

ห่วงหลัก ROS ทนทุกข์ทรมานจากความกระวนกระวายใจเล็ก ๆ น้อย ๆ บางครั้งมากที่สุดเท่าที่ 100us และแม้กระทั่งบางครั้งก็คิดถึงวงจรทั้งหมด แต่ก็ไม่สำคัญว่าจะสามารถดำเนินการรอบ 99.9% ได้สำเร็จหรือไม่

การใช้คอร์จำนวนมากภายในโฮสต์พีซีหมายความว่าหนึ่งคอร์ทั้งหมดทุ่มเทให้กับการทำงานลูปหลักและดังนั้นจึงไม่ค่อยมีความล่าช้าในการทำงานอื่น ๆ

เหตุผลหลักสำหรับการใช้ระบบปฏิบัติการแบบเรียลไทม์สำหรับระบบหุ่นยนต์เพื่อความปลอดภัย หากหุ่นยนต์ทำงานในสถานการณ์ที่สำคัญด้านความปลอดภัยนั่นเป็นความรับผิดชอบของคุณที่จะต้องรับประกันเวลาควบคุม 100% และส่วนหนึ่งของสิ่งนี้คือการรับประกันธรรมชาติตามเวลาจริงของมัน

ไม่ว่าคุณจะใช้ระบบปฏิบัติการแบบเรียลไทม์หรือไม่เซอร์โวของคุณควรทำสิ่งที่ปลอดภัยในกรณีที่ลูปควบคุมตายอย่างสิ้นเชิง ระบบความปลอดภัยนี้จะเป็นประโยชน์ในโอกาสที่หายากที่ระบบปฏิบัติการที่ไม่ใช่แบบเรียลไทม์ของคุณข้ามมากกว่ารอบ ตัวอย่างเช่นใน Shadow Hand มอเตอร์จะหยุดทำงานหากลูปควบคุมหายไปมากกว่า 20 รอบ (20ms) ฉันไม่เคยเห็นสิ่งนี้เกิดขึ้นเลย

ที่เพิ่ม

วิธีคิดอีกอย่างคือ: ระบบเซอร์โวของคุณต้องการอัตราการอัพเดทเท่าไหร่? หากเป็นอาวุธที่มีขนาดใหญ่และไม่ต้องการประสิทธิภาพสูงเป็นพิเศษการจัดตำแหน่งความเร็วสูง 500Hz อาจเพียงพอ สำหรับการขับรถไปรอบ ๆ 200Hz น่าจะเพียงพอ ในทั้งสองกรณีนี้ถ้าการวนซ้ำของคุณทำงานที่ 1000 เฮิร์ตดังนั้นรอบที่ช้าหรือหายไปก็ไม่มีปัญหาเลยตราบใดที่อัลกอริทึมการควบคุมของคุณคำนึงถึงเวลาที่ใช้จริงระหว่างลูป

วัตถุประสงค์ของซอฟต์แวร์กำหนดว่าต้องเป็นแบบเรียลไทม์หรือไม่

ในกรณีที่จุดประสงค์คือการวางแผนเส้นทางหรือการโลคัลไลซ์มักมีความถี่ต่ำเพียงพอเช่น 10Hz ในกรณีเหล่านี้การตั้งค่าเครื่องเล่น / ขั้นตอนที่ทำงานบน Linux นั้นใช้ได้ เราจะเห็นว่ามีปัญหาเล็กน้อยหากขั้นตอนเดียวนานกว่าหรือสั้นกว่าเล็กน้อย

ต้องใช้พฤติกรรมแบบเรียลไทม์อย่างเคร่งครัดหากการเปลี่ยนแปลงของหุ่นยนต์รวดเร็ว ตัวอย่างเช่นการย้ายแขนหุ่นยนต์เพื่อติดตามตำแหน่งหรือเพื่อจัดการ / จับวัตถุและย้ายพวกเขา หากพลาดขั้นตอนเวลาตำแหน่งอาจเกินกว่าที่คาดไม่ถึงและเราอาจต้องการพฤติกรรมที่คาดเดาได้มากขึ้น ในกรณีนี้เราอาจมีความถี่สูงถึง 1kHz หรือมากกว่า หากมีการใช้ระบบปฏิบัติการเราต้องการระบบปฏิบัติการแบบเรียลไทม์

การทำงานแบบเรียลไทม์สามารถทำได้ในแอปพลิเคชันแบบฝังโดยใช้ตัวจับเวลาและการขัดจังหวะ (คอมไพล์รหัส C บนไมโครคอนโทรลเลอร์) ในกรณีนี้เราต้องตรวจสอบให้แน่ใจว่าโหลดการประมวลผลไม่สูงเกินไปเพื่อให้สามารถเก็บความถี่การสุ่มตัวอย่างเป็นประจำได้

หุ่นยนต์ที่ใช้คอมพิวเตอร์ / ไมโครโปรเซสเซอร์ (เนื่องจากต้องการพลังการประมวลผลมากขึ้น) จะต้องใช้ระบบปฏิบัติการแบบเรียลไทม์เพื่อรับประกันอัตราการสุ่มตัวอย่างสูง

ดังนั้นไม่ว่าจะต้องการพฤติกรรมแบบเรียลไทม์หรือไม่นั้นขึ้นอยู่กับสิ่งที่นักพัฒนาตั้งใจจะใช้

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

หากคุณต้องการเรียลไทม์คุณต้องใช้ระบบปฏิบัติการแบบเรียลไทม์ การตรวจสอบความปลอดภัยการเก็บข้อมูลและลูปควบคุมอัตราตัวอย่างคงที่เป็นระบบย่อยทั่วไปที่ใช้การตั้งเวลาตามเวลาจริง

ส่วนการเขียนโปรแกรมแบบเรียลไทม์มักจะมีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้เนื่องจากยากต่อการตรวจแก้จุดบกพร่องและรหัสน้อยลงง่ายต่อการตรวจสอบความถูกต้อง เอกสารเกี่ยวกับระบบปฏิบัติการแบบเรียลไทม์นั้นค่อนข้างดี (รวมถึง RTAI / Xenomai)

ฉันใช้ QNX และ RTAI-> Xenomai ในโครงการหุ่นยนต์ตัวจริง ฉันชอบ QNX แต่ Xenomai มีประสิทธิภาพเท่ากัน

Orocosเป็นกรอบซอฟต์แวร์ควบคุมหุ่นยนต์แบบเรียลไทม์ที่เป็นผู้ใหญ่ ฉันเคยเห็นว่ามันเคยประสบความสำเร็จในการควบคุมหุ่นยนต์ควบคุมความเร็วสูงด้วยข้อกำหนดแบบเรียลไทม์ที่ยาก มีส่วนประกอบระดับเฟรมเวิร์กมากมายเช่นเดียวกับ ROS การสื่อสารการกำหนดค่าการทำให้เป็นอนุกรมและบรรจุภัณฑ์ที่ใช้ส่วนประกอบ

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

คุณสามารถถ่ายภาพลูปควบคุมแบบนี้ไปยัง CPU แบบเรียลไทม์โดยเฉพาะเช่น 8 บิต AVR ราคาถูกหรือ ARM 32 บิตต่ำสุดที่พบในอุปกรณ์ Arduino ระดับ ไม่มีอะไรขัดขวางคุณจากการเพิ่ม MCU ขนาดเล็กจำนวนมากที่รันลูปควบคุมเฉพาะการแจงนับอุปกรณ์ USB ทำให้การดำเนินการนี้เป็นเรื่องง่าย

ตอนนี้คุณมีลูปควบคุมที่ตอบสนองต่อจังหวะเวลาที่จัดการโดยซีพียูโดยเฉพาะแล้วคุณสามารถผ่อนคลายความต้องการเรียลไทม์ของ 'สมอง' ของหุ่นยนต์ซึ่งสามารถใช้ตรรกะระดับสูงขึ้นโดยใช้ส่วนประกอบเช่น ROS บน Linux หรือ Kinect สำหรับ Windows

ในการตอบสนองต่อการใช้ระบบแบบเรียลไทม์ "เมื่อ / ในกรณีใด":

จากประสบการณ์ของฉันการควบคุมการเคลื่อนไหวเป็นแอพพลิเคชั่นหลักสำหรับระบบเรียลไทม์ สำหรับการควบคุมมอเตอร์ความถี่สูง (100hz, 1000hz และอื่น ๆ ) และ jitter ต่ำ (ความแปรผันของเวลา) เป็นสิ่งสำคัญ ความปลอดภัยเป็นประเด็นใหญ่ที่นี่ พิจารณาหุ่นยนต์ในหมู่มนุษย์: ตัวอย่างเช่นคุณต้องการ / จำเป็นเพื่อให้แน่ใจว่าหุ่นยนต์ (แขน) หยุดในกรอบเวลา / ระยะทางเฉพาะ

สำหรับงานอื่น ๆ เช่นการวางแผนเส้นทางการประมวลผลการมองเห็นและการใช้เหตุผลแบบเรียลไทม์ระบบนั้นไม่สำคัญและมักจะหลีกเลี่ยงเนื่องจากค่าใช้จ่ายในการพัฒนาเวลาและต้นทุนฮาร์ดแวร์

ทุกวันนี้หุ่นยนต์ขนาดใหญ่เช่น PR2 ผสมผสานทั้งสองโลกเข้าด้วยกัน ในบริบทแบบเรียลไทม์ของระบบปฏิบัติการที่เปิดใช้งาน RT (เช่น Linux + Xenomai) การควบคุมการเคลื่อนไหวเกิดขึ้นและในส่วนที่ไม่ใช่เรียลไทม์ (พื้นที่ของผู้ใช้) การประมวลผลการมองเห็นและการวางแผนจะฝังอยู่ในระบบเช่น ROS ทั้งสองสามารถทำงานบนคอมพิวเตอร์เครื่องเดียวกัน

ฉันยินดีที่จะแก้ไขคำตอบนี้เมื่อคำถามได้รับการชี้แจง :-)

ใช่สมมติว่าทรัพยากรฮาร์ดแวร์สามารถตอบสนองความต้องการเวลา (พลังการประมวลผลที่เพียงพอความล่าช้าต่ำพอ) เมื่อตัวกำหนดตารางเวลาไม่สามารถจัดลำดับกระบวนการและเธรดได้อย่างเหมาะสมจากนั้นหนึ่งใช้ตัวกำหนดตารางเวลาแบบเรียลไทม์ ความท้าทายของสิ่งนี้ โปรแกรมควบคุมฮาร์ดแวร์สามารถปรับให้เหมาะสมกับสภาพเวลาจริง

ใช่หากซอฟต์แวร์ตัวใดตัวหนึ่งไม่สามารถรับประกันได้ว่าจะทำงานในเวลาที่กำหนดข้อ จำกัด นั้นจะใช้วิธีการแบบเรียลไทม์

ทางออกที่ดีวิธีหนึ่งคือทำทั้งสองอย่าง การออกแบบที่ฉันใช้ฟังก์ชั่นเรียลไทม์ของสถานที่ "ยาก" บนคอนโทรลเลอร์ไมโครขนาดเล็กลูปควบคุมเซอร์โวที่แน่นหนาและเช่นนั้น จากนั้นก็มีซีพียูตัวอื่นที่มีขนาดใหญ่กว่ารัน Linux และ ROS ฉันปล่อยให้ ROS จัดการกับงานในระดับที่สูงขึ้นและ uP จัดการกับสิ่งต่าง ๆ เช่นการควบคุมสเต็ปเปอร์มอเตอร์หรือใช้ลูป PID

ตามที่กล่าวไว้ข้างต้นโดยคนอื่น ๆ คุณสามารถอนุญาตให้ระบบปฏิบัติการแบบเรียลไทม์เรียกใช้ลูปควบคุม 1KHz แต่เพื่อให้สิ่งนี้ทำงานได้คุณต้องใช้คอมพิวเตอร์ที่มีขนาดใหญ่กว่าที่ใช้เวลาส่วนใหญ่ในการวนรอบ หากคุณเรียกใช้คอมพิวเตอร์ Linux / ROS ที่การใช้ CPU เกือบ 100% ประสิทธิภาพแบบเรียลไทม์จะไม่ดี การใช้การออกแบบสองระดับช่วยให้คุณได้รับประสิทธิภาพการทำงาน RT ที่ดีมากและใช้คอมพิวเตอร์ที่มีขนาดเล็กลงและหิวน้อยลง (อาจเป็นงานระดับสูงกว่า Pi2) ปัจจุบัน uP ของฉันไม่สามารถใช้งานระบบปฏิบัติการใด ๆ ได้