Skip to content

Preparing ROS for CAN operation

Guy Corbaz edited this page Sep 22, 2019 · 14 revisions

Introduction

NOTE: this post is not yet complete. What is described in it allows to do some simple tests between CAN and ROS.org ROS, but does now allow yet to pilot the wheels, and the robot. I will update this post as soon as I will have done more config.

Before using the KYDBL 2430-1E brushless controller with ROS, SocketCAN and CANOpen, we need to configure SocketCAN the ROS CANOpen stack. The steps are the following:

  1. Setup SocketCAN for automatic startup
  2. Create the network device
  3. The rest will come later 😇

Setup SocketCAN for automatic startup

In Installing SocketCAN we put together information we collected on the way to start SocketCAN. However, we had to re-type all the commands each time we wanted to start it. We now need to configure it to make sure the whole SocketCAN stack starts automatically.

Loading SocketCAN drivers

In order to automatically load SocketCAN drivers, you just have to create or modify the file /etc/modules as shown below.

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded # at boot time, one per line.
# Lines beginning with "#" are ignored.
can
can_raw
can_dev

When you reboot the system, you should now see the modules with lsmod. After having rebooted the system, you can chen if the modules have been correctly loaded with the command lsmod. You should see something like:

can_dev                28672  0
can_raw                20480  0
can                    24576  1 can_raw

Setting CANOpen device name

You certainly noticed that sometime, when you plug out an USB device and plug it in again after a small while, its device name changes. For example, /dev/ttyUSB0 could have changed to /dev/ttyUSB1.This is not a big issue when you deal manually with software,  but it quickly become very annoying when you would like to automate scripts, software, etc. We would like to make sure that USB device name is predictable and remains the same.

Solving that issue is rather easy. You just have to add a udev rule. To do that,  go into folder /etc/udev/rules.d. In that folder, create a file called 99-usb_can.rules (or another name, but with .rules extension). In that file, add the following parameter:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="canbus"

In our case, we would like to make sure our CANUSB device is always connected to the same device drive, for example /etc/ttyUSB0.

If you unplug and plug again your USB device, you will seen a new link entry /etc/canbus pointing to the USB device name (/etc/ttyUSB0 for example). The real device name might change, but the link on it will always be the one defined above.

You can find the idVendor and idProduct in he log file, with the dmesg command.

Clone this wiki locally