JadTawil's profile - activity

roscanopen's driver initilization service call is failing with error message:

success: False message: Transition timeout; Could not enable motor

After looking at the source code, it seems like a timeout is occuring when the driver is attempting to change the state of the controller from: Switch_On_Disabled -> Ready_To_Switch_On -> Switched_On -> Operation_Enable

It is timing out when trying to change the state from Switch_On_Disabled -> Ready_To_Switch_On.

I am able to operate the controller via canbus using the manufacturer's software, and the fact that ros-canopen is able to read the initial state of the controller (Switch_On_Disabled) means that the bus communication is up and running functionally. So i highly doubt this is a hardware issue. The controller im using is a Nanotec N5-5-2 which is DS402.

The steps i took to prepare the driver included changing the control word RPDO transmission type to 1 (every sync), and the status word TPDO transmission type to 1. Also, i added a target velocity RPDO with transmission type 1 and a Current velocity TPDO with transmission type 1 for feedback in order to run the controller in profile velocity mode via ros-canopen.

sudo ip link can0 up type can bitrate 1000000

The baudrate in the controller and Node ID are set to 1Mbps, and 1, respectively (using DIP switches).

The following is the configuration of the driver, and the output of candump after the initialize service is called. I hope someone can spot the issue. I will repeat, transitioning states is functional with the manufacturer's software, but it seems like ros-canopen is failing to get the states changed.

My configuration parameters:

bus:

  device: can0

sync:

  interval_ms: 10

  overflow: 0

defaults:

  eds_pkg: my_pkg

  eds_file: "config/N5-2-2.eds"

  vel_to_device: "rint((vel))"

nodes:

  wheel_joint:

  id: 1

joint_names: [fr_wheel_joint]

joint_state_controller:

  type: joint_state_controller/JointStateController

  publish_rate: 50

wheel_joint_velocity_controller:

  type: velocity_controllers/JointVelocityController

  joint: fr_drive_joint

  required_drive_mode: 3

More importantly, here is the candump output when the initialization service of ros_canopen is called:

can0 000 [2] 82 01

can0 701 [1] 00

can0 601 [8] 2B 17 10 00 00 00 00 00

can0 581 [8] 60 17 10 00 00 00 00 00

can0 000 [2] 01 01

can0 701 [1] 05

can0 181 [3] 40 06 03

can0 281 [4] AC FF FF FF

can0 381 [2] 00 00

can0 481 [4] 00 00 00 00

can0 601 [8] 40 61 60 00 00 00 00 00

can0 581 [8] 4F 61 60 00 03 00 00 00

can0 201 [7] 00 01 03 00 00 00 00

can0 601 [8] 40 61 60 00 00 00 00 00

can0 581 [8] 4F 61 60 00 03 00 00 00

can0 080 [0]

can0 181 [3] 40 06 03

can0 481 [4] 00 00 00 00

can0 601 [8] 40 61 60 00 00 00 00 00

can0 581 [8] 4F 61 60 00 03 00 00 00

can0 201 [7] 06 01 03 00 00 00 00

//This Block Repeats for a certain period

can0 080 [0]

can0 181 [3] 40 ... (more)

Hello all. I am attempting to run my controller in IP mode using ros-canopen but the motor fails to start motion. I am using a joint_trajectory_controller to command the controller. The controller works as expected in PP and PV modes.

I am troubleshooting by publishing the object 60C1sub1 (interpolation data record) and 6062 (Position demand value).

In PP mode, object 607A updates and 6062 updates to reflect the commanded postion shortly after. The motor moves, as expected.

In IP mode, 60C1sub1 updates as expected when a trajectory is commanded via the joint_trajectory_controller topic interface, however, 6062 does not update, and consequently, the motor never moves.

I attempted to change the RPDO transmission type of 60C1sub1 from FF to 01. Both produce the same result however.

I am using a SYNC interval of 10 ms, and i have the interpolation time period set to 10 ms as well. I tried raising it to 50 ms, but that does not change the result.

To add, i am publishing the control word and status words using the SDO troubleshooting mechanism provided by ros-canopen (6040! and 6041!). Bit 4 in the control word, which activaltes the interpolation seems to be set. Bit 12 in the status word, which indicates interpolation active/inactive, is never set. So it seems that setting the interpolation to active is being a problem. Interestingly, the target reached bit is always set... Would this be preventing motion? Also, i tried running it through the action interface, via the terminal by publishing to /goal topic, and the goal status reported is 1 active, then 3 succeeded... but the motor never moves as the position demand value never changes. how can the trajectory controller report success if the joint_states never indicated that? that seems weird. could it be transmission types of PDO's?

I am able to run IP Mode via the software of the manufacturer. The only difference i perceive is that in that software, i am writing 1 value to the data record that is very far from the current value, the controller does the interpolation and goes there. However, through ROS, i am writing the values on a ramp via the traj controller and so overwriting the value constantly. This shouldn't be a problem tho, could it be...?

The maximum buffer size of the controller i am using is 1. Could this be an issue?

Essentially, when the drive initializes, it sets bit4 in control word, which is correct, but bit 12 in status word,which indicates that ip mode is active, is never set ...

See below the terminal output of the statusword, control word, and mode display, as printed using the periodic printing provided by ros-canopen for debugging. The init service is called, and the following is outputted:

Status      Control    Mode Display

data: 38455 data: 271   data: 6   #Operation Enabled, Interpolation active

data: 38455 data: 271   data: 6

data: 38455 data: 271   data: 6

data: 38455 data: 271   data: 6

data: 38455 data: 271   data: 6

data ...