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.

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

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

Future readings

• KYDBL 2430-1E
• ROS
• SocketCAN
• CANOpen
• canopen_motor_node