پروتکل CAN و ارتباط بلادرنگ در رباتیک

در یک ربات، ده ها قطعه باید هم زمان با یکدیگر گفت وگو کنند: کنترل کننده مرکزی، درایورهای موتور، حسگرها، انکودرها و سامانه تغذیه. اگر این پیام ها دیر برسند یا در نویز الکترومغناطیسی موتورها گم شوند، ربات از مسیر منحرف می شود یا بازوی آن با تاخیر واکنش نشان می دهد. پروتکل CAN یا Controller Area Network دقیقا برای همین مسئله ساخته شده است؛ گذرگاهی سریال، دوم سیمه و دیفرانسیلی که نخستین بار در دهه ۱۹۸۰ برای خودروها ابداع شد و امروز ستون فقرات ارتباطی ربات های متحرک و بازوهای صنعتی است.

قلب تپنده CAN مکانیزم داوری یا Arbitration است. در این گذرگاه همه گره ها برابرند و هرگاه گذرگاه آزاد باشد می توانند ارسال کنند. اگر دو گره هم زمان شروع کنند، شناسه پیام برنده را تعیین می کند: بیت غالب، صفر منطقی، بر بیت مغلوب، یک منطقی، غلبه می کند و پیامی با شناسه عددی کوچک تر بدون برخورد و بدون از دست رفتن حتی یک بیت ادامه می یابد. به این ترتیب پیام اضطراری توقف یا داده انکودر یک مفصل همیشه بر پیام های کم اهمیت تر مانند گزارش دما اولویت دارد و تاخیر پیام های حیاتی قابل پیش بینی و محدود می ماند؛ از همین رو CAN برای سامانه های بلادرنگ مناسب است.

روی لایه CAN، پروتکل CANopen می نشیند؛ استانداردی بر پایه مشخصه CiA 301 که به هر پیام معنا می دهد. داده های زنده در قالب PDO با حداکثر هشت بایت و بدون نیاز به پاسخ ردوبدل می شوند و پروفایل CiA 402 به طور ویژه برای کنترل حرکت و درایوهای سروو تعریف شده است. در مقایسه با UART که نقطه به نقطه و بدون مکانیزم خطا است و I2C که برای فاصله های کوتاه درون یک برد مناسب است، CAN در برابر نویز مقاوم تر است و چندین گره را روی یک زوج سیم پشتیبانی می کند. سرعت استاندارد آن تا یک مگابیت بر ثانیه و در نسخه CAN FD تا چند مگابیت بر ثانیه می رسد، هرچند در یک مگابیت بر ثانیه طول مجاز گذرگاه حدود چهل متر است. در عمل، یک ربات متحرک می تواند درایور چرخ ها، ماژول باتری و حسگرهای فاصله را با یک گذرگاه CAN به کنترل کننده اصلی متصل کند و مطمئن باشد که فرمان توقف اضطراری بی درنگ می رسد.

CAN Bus in Robotics: Real-Time Communication, CANopen and Arbitration

In a robot, dozens of components must talk at the same time: the central controller, motor drivers, sensors, encoders and the power system. If these messages arrive late or are lost in the electromagnetic noise of the motors, the robot drifts off its path or its arm reacts with delay. The CAN protocol, or Controller Area Network, was built precisely for this problem. It is a two-wire differential serial bus first developed in the 1980s for automobiles, and today it is the communication backbone of mobile robots and industrial arms.

At the heart of CAN lies arbitration. In this bus all nodes are equal and may transmit whenever the bus is free. If two nodes start at the same time, the message identifier decides the winner: a dominant bit, logical zero, overwrites a recessive bit, logical one, so the message with the smaller numeric identifier continues without a collision. An emergency-stop message or an encoder reading from a joint therefore always outranks less critical traffic such as a temperature report, and the delay of vital messages stays predictable and bounded. This is what makes CAN a natural choice for real-time systems.

On top of the CAN layer sits CANopen, a standard based on the CiA 301 specification that gives meaning to each message. Live data travels in Process Data Objects (PDOs) of up to eight bytes with no reply needed, while CiA 402 covers motion control and servo drives. Compared with point-to-point UART, which has no error mechanism, and I2C, which suits short on-board distances, CAN resists noise better and links many nodes on one pair of wires. Its standard speed reaches one megabit per second, and the CAN FD variant reaches several megabits per second, although at one megabit per second the allowed bus length is about forty metres. In practice, a mobile robot can connect its wheel drivers, battery module and ranging sensors to the main controller over a single CAN bus, knowing an emergency-stop command will arrive instantly.

کلیدواژه ها: گذرگاه CAN، ارتباط بلادرنگ، CANopen، داوری پیام، رباتیک

Keywords: CAN bus, real-time communication, CANopen, message arbitration, robotics

منابع / Sources:

1. Influx Technology, "What is CANopen? CAN bus with a common language" — https://influxtechnology.com/blogs/learn/what-is-canopen

2. CAN in Automation (CiA), CANopen — https://www.wachendorff-prozesstechnik.de/en/technology/fieldbus-the-success-story/canopen/

3. element14 Community, "How does the CANopen Network Protocol work?" — https://community.element14.com/learn/learning-center/the-tech-connection/w/documents/4195/how-does-the-canopen-network-protocol-work

4. Tritek Battery, "Battery Communication Protocol Options: How to Choose the Right Protocol" — https://tritekbattery.com/battery-communication-protocol-options-how-to-choose-the-right-protocol/

5. IoT by HVM, "Communication Protocols: I2C, SPI, UART, and CAN" — https://iotbyhvm.ooo/communication-protocols-i2c-spi-uart-and-can/