Preparing ROS for CAN operation

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. Test if communication work properly

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, which is /dev/canbus.

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 now acess the CANUSB device via /dev/canbus.

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

Create the network device

Create a file, called init_can, in the folder where your ROS configuration are stored. The file should contain the following commands:

#!/bin/bash
#
# This script initialize socketCAN.
# It is based on the ssumption that
# CAN drivers are automatically
# loaded at boot time.
#

# set -x

echo "Initialize SocketCAN"

sudo slcand -o -c -f -s4 /dev/canbus can0
sleep 2
sudo ifconfig can0 up

For the gribot project, we put it under gribot/script. This is fine for development, but has to be automatized in production.

Checking if CANOpen is working

Now it is time to test if ROS can see CANOpen device. The system configuration used to do the tests is the following:

• Ubuntu 18.04
• ROS Melodic official distribution installed
• Interface is available (you can see a can0 interface with ifconfig)
• Keya brushless controller connected the the CAN bus with following parameters (configured via Keya configuration tool):
  • ID: 11
  • Baud rate: H125
  • Heartbeat: 500ms
  • Self start: Open You can now check if your computer is receiving packet from CANUSB et can0 device. Type candump can0 and you should seen something like:

can0  70B   [1]  05
can0  70B   [1]  05
can0  70B   [1]  05
...

Sending a command to the controller

Now that the keep alive packets are arriving, it is time to check if we can send commands to run the motor. If everything went correctly in the steps below and the Keya brushless controller is configured as described above, you can test if the motor is running. Type the following command:

cansend can0 60B#23.00.20.01.f4.01.00.00

This will tell controller with id 11 to run the motor at 500rpm. The motor should run for a small while. If you want to run it longer, you have to re-submit the command.

Testing if ros_canopen is working

Now, you can test if ros_canopen is working. Just type the followingcommand:

rosrun socketcan_interface socketcan_dump can0

and you should see something like:

s 70b	1 5
s 70b	1 5
s 70b	1 5
...