ros-industrial / ros_canopen

CANopen driver framework for ROS (http://wiki.ros.org/ros_canopen)
GNU Lesser General Public License v3.0
336 stars 271 forks source link

Can Not Ready Issue #376

Closed JadTawil-theonly closed 4 years ago

JadTawil-theonly commented 4 years ago

Hello,

I am using the SV2D10-C-CE canopen controller from Applied Motion: https://www.applied-motion.com/produc...

After performing the configuration of the motor parameters with their supplied software, i am attempting to control it through ros-canopen. I made sure to provide the EDS that reflects the parameters in the controller; namely, the PDO mappings (communication and mapping params). The following is the error i am getting from the terminal, when the init service is called.

[ INFO] [1578945169.300230801]: Using fixed control period: 0.010000000

[ INFO] [1578945173.151896023]: Current state: 1 device error: system:0 internal_error: 0 (OK) [ INFO] [1578945173.152116183]: Current state: 2 device error: system:0 internal_error: 0 (OK) [ INFO] [1578945183.856832324]: Current state: 2 device error: system:125 internal_error: 0 (OK) [ INFO] [1578945183.856974071]: Current state: 0 device error: system:125 internal_error: 0 (OK) [ INFO] [1578945183.857054082]: Current state: 0 device error: system:0 internal_error: 0 (OK) [ INFO] [1578945183.857178004]: Current state: 0 device error: system:0 internal_error: 0 (OK) [ERROR] [1578945183.857954723]: Initializing failed: Transition timeout; Could not enable motor; Transition timeout

The following text file contains the contents of "candump can0": https://drive.google.com/open?id=1_8BhBX1DEYX754bl5KkWXsFsBdKNMLUQ


A few details about the controller i am using:

>     SV200 servo drivesare compliant to CiA 301 and CiA 402 and uses the CAN 2.0B passive physical layer.

Is the ros-canopen driver programmed to support CAN 2.0B physical layer? I am aware that 2.0B protocol uses 29 bit CAN-ids, as opposed to the 11 bit CAN-ids that protocol 2.0A uses.

Can this be the problem?

Id like to add, i have been using this driver for years with CanOpen controllers that use the 2.0A protocol, which is leading to suspect that this may be the issue here

Contents of the config files:

> 
> defaults:
>   eds_pkg: applied_motion
>   motor_layer:
>     switching_state: 5
> 
> nodes:
>   
>   wheel_joint:
>     id: 1
>     eds_file: "config/eds/CAN_EDS_212E_SV200.eds"
>     vel_to_device: "rint((vel/0.0042))"
>     vel_from_device: "(obj606C*0.0042)"

Also, the following is my TPDO/RPDO configuration (EDS file reflects this).

> RPDO1:
> transmission: 255
> mapped:
>        0x60400010
>        0x60600008
> RPDO2:
> transmission: 255
> mapped:
>        0x607A0020
>        0x60840020
> RPDO3:
> transmission: 255
> mapped:
>        0x60FF0020
> 
> TPDO1:
> transmission: 01
> mapped:
>       0x60410010
>       0x60610008
> TPDO2:
> transmission: 01
> mapped:
>       0x60640020
> TPDO3:
> transmission: 01
> mapped:
>       0x606C0020
JadBatmobile commented 4 years ago

What is confusing about the candump is this part:

 can0  601   [8]  40 61 60 00 00 00 00 00
 can0  581   [8]  4F 61 60 00 00 00 00 00

Which means that there is a SDO read request for object 6061 (Operation mode display), and the response is 00, which makes no sense since 0 is not a valid mode; the modes are:

1 Profile Position Mode
3 Profile Velocity Mode
4 Torque Profile Mode (Servo only)
6 Homing Mode

Doesn't this driver set the mode of operation on initialization? Perhaps it is hanging because it is getting a non-sense response for modes of operation.

Furthremore, the line in the candump: can0 201 [2] 00 01

Suggests that 2 bytes are being transmitted to be received by RPDO1, which is not consisten with my device mapping, which has the control word and modes of operation as RPDO1, which should sum up to 3 bytes, instead of two (what is shown in the dump).

gavanderhoorn commented 4 years ago

Cross posted to ROS Answers: Can Not Ready Error

JadTawil-theonly commented 4 years ago

Is cross posting frowned on? :/ @gavanderhoorn

gavanderhoorn commented 4 years ago

Yes.

Cross-posting is always bad. At best it leads to split discussions, worst-case it leads to duplication of effort.

For you -- as the cross-poster -- having two discussions / diagnostic sessions may seem like a good thing: potentially more people helping you. But for everyone else it's just wasted time and effort.

JadTawil-theonly commented 4 years ago

@gavanderhoorn won't happen again!