# Introduction

Note: this post is not yet complete. What is described in it allows to do some simple tests between CAN and 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 a previous post, 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.

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”.

## 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. 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"

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.

# 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
#
# Initialize SocketCAN
#
# set -x
echo "Initialize SocketCAN"
sudo slcand -o -c -f -s4 /dev/canbus can0
sudo ifconfig can0 up

Note: the KYDBL 2430-1E brushless controller seems to have some difficulties wit high CAN bus bit rate. Therefore we limited it to 125 kbps (-s4) for the time being

# Checking if CANOpen is working

Now it is time to test if ROS can see CANOpen device. My systems configuration are the following:

• Ubuntu 16.04
• ROS Lunar installed. I’m using the official Ubuntu distribution
• 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

If everything has been configured, turn brush-less controller power on and type:

rosrun socketcan_interface socketcan_dump can0

You should now see the keep alive packets arriving.

# Sending a command to the controller

Now the keep alive packets are arriving: this is telling that the brushless controller is working and that we have configured the network correctly. The next test is sending a command to the controller.

I connected a brushless motor to the controller, tested it with the Keya software. We will send a command to run the motor.

The motor will run at his maximum speed: so be very careful and make sure no objects are near the moving parts and make sure the motor is attached.

Type the following command (assuming the brushless controller is configured as above):

cansend can0 70B#23.00.20.01.e8.03.00.00

Normally, the motor will run, and stop a small while after. To keep the motor running, the command has to be send periodically.

# Sending commands via ROS canopen_motor_node

In order to send commands to motors and make the robot moving, we needs to configure  canopen_motor_node. This ros node requires several configuration files:

• One eds configuration file per controller or controller type.
• One or more yaml configuration files. You can put everything in one file, but, depending on the robot complexity, it might be easier to split configuration between files.

## EDS file

The eds file (Electronic Data Sheet) contains the description of the capabilities of the CANOpen device. After deep search, I did not find a correct file for the Keya 2430-1E brush-less controller: therefore I created my own eds file that can be found here. This Electronic Data Sheet contains the minimum require information to get canopen_motor_node running.

# More will come soon

1. wow, thx alot for this post.
i’m in the process of purchasing dual channel controller, 30A from jinan keya to handle 2 BLDC motor. that blue one.

it is said already support CANopen. after reading your post, i can go with this with confident.

just wondering how ROS talk to this controller? create node or topic for each command?

Simba
1. Hello,
First of all, I can only speak for the single channel (the red one) as I did not test the other.
Yes, it is CANOpen ready, however, it is not activated by default: you have to sold two jumper on the board of the KYDBL 2430-1E ( I don’t know for the other.)
There is a software to configure the Jinan Keya devices, but it is not directly available on their web site: you have to ask for it.
There is an EDS file, but you also have to ask for it.
It seems that the KYDBL 2430-1E has some issue with high bandwidth CAN operation: at the time being, I’m using it at 125 kbps.
I’m trying to use ros_canopen, but did not test yet: the doc is a bit light. I’m working on it and will update that post soon.

2. Hey thanks for the post, so useful!

Also, I am trying to do the same application with other motors and I was wondering, do you have to configure canopen_master first? what’s the difference between canopen_master, canopen_chain_mode and canopen_motor_node? I have taken a look to the documentation but I still don’t get it. Thanks!!

Felipe
1. Hello Felipe,

According to my understanding, canopen_motor_node is sufficient to control a motor. My configuration files are in https://github.com/gribot-robotics/gribot_ros. However, I put the configuration on old for the time being and commented the canopen_motor_node in the configuration as I had other issues to solve first. As soon as I will have a working canopen configuration I’ll update this post with it.

1. Thank you very much, I will check it out, also if I can develop something functional I will let you know!

Felipe

This site uses Akismet to reduce spam. Learn how your comment data is processed.