عندما تبدأ في تعلم ROS ، فأنت تريد عادةً العمل مع الأنظمة الأساسية المادية ، وليس مع النماذج الموجودة في جهاز محاكاة. في الواقع ، تعتبر Gazebo كافية لدراسة خوارزميات الحركة فقط أو فقط لتعليم ROS نفسها ، ولكن العمل مع منصة حقيقية على الفور يجعل من الممكن فهم جميع مشاكل حركة العجلة عمليًا. حسنًا ، وغالبًا ما تكون المنصة مطلوبة فقط كشرط أساسي للمشروع.
بالنسبة للمستقبل ، من الأفضل أن تبدأ بجولة واحدة ، لأن لأسباب واضحة ، يمكن لمثل هذا التكوين أن يدور حول المحور دون مراعاة حجم الجزء البارز. يعتبر مستطيل U-turn أقل ملاءمة ، على سبيل المثال ، في الممرات الضيقة - في بعض الأحيان يصبح من الضروري الكشف عن 3 حيل أو أكثر ، أعتقد أن سائقي السيارات سيفهمونها.
شراء منصات جاهزة
لا توجد العديد من المنصات الجاهزة في السوق ، فهي مدرجة على موقع ROS .
في الوقت نفسه ، تكلفتها في روسيا عالية بما يكفي لبدء العمل ؛ أرخص خيار هو Turtlebot Burger 3 - 549 دولارًا. وجدنا بائعين مباشرة في روسيا مقابل حوالي 90000 روبل.
في الصين ، يمكنك الشراء مقابل 45-50 طنًا ... على أي حال ، ستكون هذه منصات صغيرة الحجم وقدرة تحمل ، غير قادرة على أداء مهام حقيقية.
يمكنك بناء النظام الأساسي بنفسك ، فهناك الكثير من الأدلة والتكوينات المختلفة. لكن في المتوسط ، اتضح أن شيئًا مثل:
- Slamtech A1-A2 class lidar
- عجلات رخيصة تعتمد على محركات التجميع مع علب التروس
- , PWM , UART + rosserial.
- Single Board Computer — Raspberry, Jetson Nano
- 2
- gmapping + amcl/rosbot_ekf + move_base
لم نكن نحب المحركات المصقولة لأنها صاخبة وذات استهلاك مرتفع وهناك حاجة إلى علبة تروس. هنا يجب أن أقول أن المنصات تعتبر ثقيلة جدًا - أي لن تعمل علب التروس المتشابكة + المحركات شيء مثل المحرك من الصورة.
وفقًا لذلك ، تم اختيار محركات العجلات BLDC كمحركات. الخيار الأكثر تكلفة في الوقت الحالي هو عجلات hoverboard 6.5. يبقى فقط لإدارتها من ROS.
ولكن بعد ذلك ظهرت مشكلة واحدة: حتى عند العمل مع روبوتات الجولف ، لوحظت مشكلة كبيرة في دوران مثل هذه المنصة بسرعة منخفضة - استدار الروبوت متشنجًا نوعًا ما.
أسباب هذا السلوك بسيطة: تلعب قوى الاحتكاك المنزلقة دورًا أساسيًا في مقاومة الحركة بدورها. ولديهم خصوصية - تعتمد المقاومة على كتلة وطبيعة الأسطح نفسها - ولهذا السبب يحمل الترباس الصغير هياكل كبيرة مع أول 2-3 دورات.
لذلك ، فإن جعل العجلات تضيق في المركز بحيث تستدير يصبح بلا فائدة - ستتغير المقاومة قليلاً جدًا. تحتك العجلة المطاطية بالعشب والتربة ، وهي ليست متساوية على الإطلاق ويمكن أن تتغير القوة بشكل كبير ، ونتيجة لذلك ، تم صنع شيء مثل علبة التروس - بسرعة منخفضة نتحكم في اللحظة على العجلة ، ومع الحركة المباشرة - السرعة نفسها.
يبدو أنه عند القيادة على الباركيه أو المشمع ، يجب أن يكون الوضع أفضل ، ولكن للأسف ، معامل الاحتكاك هو نفسه تقريبًا (تذكر أن الأحذية المضادة للانزلاق مصنوعة أيضًا من المطاط).
ونتيجة لذلك ، بدأ روبوت يزن 10-15 كيلوغرامًا بالفعل في الظهور مع هزات ملموسة.
تمت إضافة الجزء الثاني من المشكلة بواسطة حزمة ROS diff_drive مع لوحات SBC ضعيفة نوعًا ما.
فيما يلي قائمة بما تمكنت من فهمه
يتم تنفيذ الإدارة باستخدام التنفيذ في الوقت الفعلي ، لكنها لا تأخذ في الاعتبار أن الحزم الأخرى يجب أن تتوقع هذا النهج عند العمل مع الإدارة.
هنا يجب أن نتذكر أن الوقت الفعلي ليس رد فعل فوري لحدث ما ، ولكنه ضمان بأن الحدث ستتم معالجته على فترات زمنية مضمونة من الوقت الفعلي. أولئك. محطة الطاقة الكهرومائية الشرطية ، التي يتم تنظيمها كل دقيقة (بالضرورة كل) هي أيضًا نظام في الوقت الفعلي.
هناك احتمال أن يتم انسداد موضوعات مخطط المسار بالرسائل ، وبالنسبة للأنظمة الفرعية لتحديد المواقع وتخطيط المسار ، يؤدي هذا السلوك عادةً إما إلى إيقاف معالجة التدفق وإعادة تشغيلها ، أو محاولة ضبط العملية أثناء التنقل.
نتيجة لذلك ، في تحديات بناء التشكيلة الضعيفة ، ينشأ موقف مع إعادة حساب مستمرة للمسار، أو يستهلك البحث عن الأقلمة وقتًا كبيرًا إلى حد ما في المعالج - وكلما تم إجراء المزيد من المحاولات لمواكبة مكون RT ، زاد الوقت المتراكم. في شكلها النقي ، ردود الفعل الإيجابية ، والتي في هذه الحالة ليست هناك حاجة على الإطلاق.
بالإضافة إلى ذلك ، لا يبدأ gmapping العمل بسرعة كبيرة مع التغييرات المفاجئة في موضع المنصة و lidar الضعيف - لوحظ توقف مؤقت لمدة تصل إلى نصف ثانية ، مما يحير مخطط المسار بشكل كبير.
يتم التحكم في المحركات بشكل منفصل ، لذلك عند استخدام SBC والتنفيذ الساذج للسائقين ، سيتم التحكم في العجلات مع بعض التأخير.
هنا المشكلة أبسط - نحتاج إلى التحكم في 2-4 عجلات من خلال قناة الاتصال ، والتي. وفقًا لذلك ، تصطف إشارات التحكم وتبدأ في الإرسال واحدة تلو الأخرى - العجلة اليسرى ، والعجلة اليمنى ، والعجلة اليسرى ، والعجلة اليمنى.
نتيجة لذلك ، تبدأ العجلات نفسها ، والأسوأ من ذلك ، مواضع العجلات من المشفرات في المساهمة في تكوين PIC بين تخطيط المسار والتحكم في المحركات.
قياس المسافات المدمج بسيط للغاية.
نظرًا لأننا لم نكن نبحث عن طريقة سهلة لمزامنة الأمر وعودة قياس المسافات - لم نتمكن من العثور عليه. يرتبط التزامن دائمًا بانتظار بعض الأوامر عند الإدخال ، ولكنها ليست منتظمة في الوقت المناسب ، ونتيجة لذلك ، يبدأ قياس المسافات في الانتظار عند الإخراج. ربما سيقترح القراء طريقة سهلة - هنا لا نعتبر أنفسنا غوروًا في ROS.
لم ننجح في ضمان حسن سير مثل هذا التجمع. بتعبير أدق ، كان من الممكن التقليل من قيمة تسارع الإزاحة إلى 0.05-0.1 م / ث ^ 2 والسرعة الزاوية إلى 0.03 راديان / ث.
اعتقدت أنه سيكون من الجيد أن يكون لديك:
- منصة رخيصة
- توجيه عجلة متزامن
- حساب قياس المسافات على أساس سلوك العجلة والتعامل معها
- أوضاع الدوران مع ضوابط مختلفة
- قيود مختلفة في أوضاع مختلفة
ماذا حدث في النهاية
تم أخذ وحدة التحكم من ألواح السكوتر الجيروسكوب وتم كتابة التحكم في العجلة بطريقة تستخدم التحكم في عزم الدوران عند بدء الحركة والانعطاف. وإذا كانت العربة تسير في خط مستقيم وتم تسريعها إلى سرعة معينة ، يتم تنشيط وضع التحكم في السرعة. في كلا الوضعين ، تتم معالجة البيانات من أجهزة التشفير داخل وحدة التحكم ، مع مراعاة السرعة والوضع ، ويتم إخراج البيانات مع بعض التنبؤات قبل 10-15 مللي ثانية.
تتم دائمًا قراءة أجهزة التشفير في وحدة التحكم ، وتتراكم في مخزن مؤقت من 2-3 عناصر ويتم إرسالها مع تأخير. النقطة المهمة هي أنه عند تلقي التحكم ، لا تذهب الاستجابة إلا بعد تنفيذ الأمر - أي يتم حظر المخزن المؤقت حتى يتم استلام قيم التشفير المتغيرة. لكن يتم إصدار قياس المسافات ، ويستخدم فقط القيمة الأخيرة التي تم إرسالها بالفعل.
لان تتلخص جميع المشكلات المذكورة أعلاه في حقيقة أنه من الضروري في أي حال مزامنة التحكم في الإرسال المتزامن المتزامن من منفذ UART ، ثم اعتبرنا أنه من غير المعقول إدخال مزامن قسري في حزمة diff_drive ، لذلك كتبنا حزمة التحكم الخاصة بنا.
يوجد هنا github.com/Shadowru/hoverboard_driver ويتم حاليًا الانتهاء منه بشكل نشط:
الحزمة مضمنة في ملف التشغيل على النحو التالي:
<node name="hoverboard_driver" pkg="hoverboard_driver" type="node" output="screen">
<param name="uart" value="{ }"/>
<param name="baudrate" value="115200"/>
<param name="wheel_radius" value="0.116"/>
<param name="base_width” value="0.43"/>
<param name="odom_frame” value="odom"/>
<param name="base_frame” value="base_link"/>
</node>
يجب أن يكون منفذ uart نفسه مع حقوق الوصول المناسبة ، على بعض الأنظمة الأساسية لا يكون لديه دائمًا وصول للمستخدم. كمثال - بالنسبة لـ Jetson Nano في دليل hoverboard_driver / scripts / jetson_nano_serial.sh ، يتم إرفاق نص برمجي يعيّن الحقوق عند بدء تشغيل نظام التشغيل.
تحتوي الحزمة نفسها على قراءة تدفق البيانات من وحدة التحكم وإصدار المعلومات ذات الصلة بالموضوعات:
hoverboard_driver / hoverboard_msg مع حزمة مثل hoverboard_msg
بنية الرسالة على النحو التالي:
int16 state1 - المعلومات الداخلية على العجلة 1
int16 state2 - المعلومات الداخلية على العجلة 2
سرعة int161 - السرعة اللحظية للعجلة 1
int16 speed2 - السرعة اللحظية للعجلة 2
int16 bat الجهد - جهد البطارية
int16 boardTemp - درجة حرارة وحدة التحكم
int16 error1 - wheel 1 error
int16 error2 - wheel 2 error
int32 pulseCount1 - wheel 1 encoder counter
int32 pulseCount2 - wheel 2 encoder counter
بالإضافة إلى ذلك ، يتلقى موضوع hoverboard_driver / odometry رسالة نموذجية nav_msgs :: Odometry
يتم حساب الموضع على النحو التالي:
استنادًا إلى المعلمات wheel_radius - radius العجلات بالأمتار ، عرض القاعدة - المسافة بين مراكز العجلات ، نحسب مقدار تحرك كل عجلة خلال الفترة بين الموضع السابق والموقع المقروء.
double curr_wheel_L_ang_pos = getAngularPos((double) feedback.pulseCount1); double curr_wheel_R_ang_pos = getAngularPos((double) feedback.pulseCount2); double dtime = (current_time - last_time).toSec(); double delta_L_ang_pos = curr_wheel_L_ang_pos - raw_wheel_L_ang_pos; double delta_R_ang_pos = -1.0 * (curr_wheel_R_ang_pos - raw_wheel_R_ang_pos);
ثم نحسب عجلة كل عجلة
wheel_L_ang_vel = delta_L_ang_pos / (dtime); wheel_R_ang_vel = delta_R_ang_pos / (dtime);
بعد ذلك ، نحسب التسارع الخطي للروبوت على طول كل محور
robot_angular_vel = (((wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width) - robot_angular_pos) / dtime; robot_angular_pos = (wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width; robot_x_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * cos(robot_angular_pos)); robot_y_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * sin(robot_angular_pos));
نتيجة لذلك ، يتم الحصول على مجموعة كاملة - التسارع الخطي ، والتسارع الزاوي وضربها في الوقت - إزاحة موضع الروبوت.
robot_x_pos = robot_x_pos + robot_x_vel * dtime; robot_y_pos = robot_y_pos + robot_y_vel * dtime;
بعد ذلك ، يتم إرسال رسالة قياس المسافات ، بالإضافة إلى ترجمة tf بين إطار قياس المسافات والإطار الأساسي.
يتم التحكم في وحدة التحكم عند الإدخال بواسطة حزمة واحدة مع معلمتين - السرعة والدوران ، يتم ترجمة الحزمة من الالتواء تقريبًا - يتم تقسيم السرعة على المحيط ويتم الحصول على المنعطفات.
double v = vel.linear.x;
double rps = v / rpm_per_meter;
double rpm = rps * 60;
int16_t speed = static_cast(rpm);
ويتم تحويل التسارع الزاوي إلى فرق في سرعات العجلة في شكل مضاعفة بمعامل ، وستتم إضافة مزيد من إعادة الحساب مع الأخذ في الاعتبار قاعدة العجلة ، ولكن من الناحية العملية هذا ضروري فقط للروبوتات الكبيرة والثقيلة بدرجة كافية.
double w = vel.angular.z;
int16_t steer = static_cast<int>(-1 * w * 30);
نتيجة لذلك ، كان من الممكن تحقيق تحكم ثابت للغاية في العربة على المكونات الرخيصة.
نصنع روبوتات ، مثل الغالبية العظمى منكم. لدينا منتجنا الرئيسي ، الذي نعمل على تطويره بنشاط. اختبار تجريبي وجاهز للإنتاج. هذا روبوت لجمع كرات الجولف.
نقوم بتطوير روبوتات مخصصة وحلول مشتقة. في بعض الأحيان يكون هذا العمل من مهمة فنية ورسم تخطيطي للمنتج النهائي ، وأحيانًا جزء من العمل.
في معظم الحالات ، يحتاج الروبوت إلى عجلات للتفاعل مع العالم الخارجي. غالبًا ما تكون هذه محركات بدون فرش ، نظرًا لقدرتها على التحكم الدقيق في السرعة والموضع.
بالنسبة للروبوتات الصغيرة ، غالبًا ما يتم استخدام عجلات من سكوتر الدوران ، وهذا مبرر بسبب الإنتاج الضخم وسعر هذا الحل. يدرك أي شخص شاهد قائمة أسعار المحركات الروسية أهمية الإنتاج الضخم.
بالنسبة لوحدة التحكم ، غالبًا ما تكون هذه الحلول نموذج esc أو vesc أو odrive أو BLD-300B أو حلول محلية الصنع.
لسهولة الدخول في صنع روبوتات حقيقية وكسر لعنة الجازيبو ، يحتاج معظم المطورين إلى حوت لسهولة الدخول. يختلف الكثير في العالم الحقيقي عن المثالي.
في بعض الأحيان تحدث أشياء غير متوقعة ، أجهزة الاستشعار صاخبة ، في الوقت الحقيقي ، تجاوز المخزن المؤقت. على جهاز الفيديو هذا ، الذي اختبرناه سابقًا باستخدام موصل ومفتاح تحكم عن بعد.
نقدم شيئًا من شأنه أن يساعدنا في الحفاظ على الأعصاب في الوقت المناسب ، هذه مجموعة لتجميع العلبة (متوازية السطوح وأسطوانة) ، عجلتان بمحرك ، بطارية ، شاحن ووحدة تحكم وامضة تعطي قياس المسافات وتعمل مع حزمة ROS الخاصة بنا خارج الصندوق 19.000 فرك. إنها أرخص من قطع الطحن ، تكلفة المواد المركبة ، السحابات وعجلة دوارة مبطن.
اتصل بنا أو تقدم بطلب للحصول على منصة ROS عبر الإنترنت . لنصنع روبوتات معًا. سنخبرك
بالمزيد عن المنصة في لقاء نظام تشغيل الروبوت في 5 ديسمبر. التسجيل للمشاركين مفتوح بالفعل.
→ التسجيل للمشاهدين