JuliusGel's profile - activity

All the current distributions of ROS are compiled using C++03. You can compile your own packages using c++11 by adding

You could try SET_SOURCE_FILES_PROPERTIES( foo.cpp PROPERTIES COMPILE_FLAGS -std=c++11). I have, however, not tried this

We have found the issue, the main problem was that at the moment ros_canopen does not allow to map the same object in multiple PDO. Related issue here.

I have updated the eds and added updated candump here

Adding ParameterValue to 6060 and 6040 helped to get rid of 081 emergency message. The problem is that I still get the same error: Transition timeout; Could not enable motor; Transition timeout. Maybe you know what other issues I might have?

I am trying to control Trinamic PD-1160 motor using ros_canopen. The motor is DS402 complient. The CANopen manual of this motor is located here. I have configured the canopen_motor_node using the following eds and yaml files.

The canopen_motor_node starts successfully using this configuration file but initialization service fails with the following error:

Transition timeout; Could not enable motor; Transition timeout

Here is a short snippet of candump output that I get when initializing the canopen_motor_node:

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  601   [8]  40 41 60 00 00 00 00 00
can0  581   [8]  4B 41 60 00 18 06 00 00
can0  601   [8]  40 61 60 00 00 00 00 00
can0  581   [8]  4F 61 60 00 00 00 00 00
can0  601   [8]  40 64 60 00 00 00 00 00
can0  581   [8]  43 64 60 00 00 00 00 00
can0  601   [8]  40 6C 60 00 00 00 00 00
can0  581   [8]  43 6C 60 00 00 00 00 00
can0  601   [8]  40 44 60 00 00 00 00 00
can0  581   [8]  4B 44 60 00 00 00 00 00
can0  601   [8]  40 40 60 00 00 00 00 00
can0  581   [8]  4B 40 60 00 00 00 00 00
can0  601   [8]  40 FF 60 00 00 00 00 00
can0  581   [8]  43 FF 60 00 00 00 00 00
can0  000   [2]  01 01
can0  181   [2]  18 06
can0  281   [3]  18 06 00
can0  601   [8]  40 01 10 00 00 00 00 00
can0  581   [8]  4F 01 10 00 00 00 00 00
can0  601   [8]  40 01 10 00 00 00 00 00
can0  581   [8]  4F 01 10 00 00 00 00 00
can0  301   [3]  00 00 00
can0  081   [8]  20 63 01 00 FF 00 00 00
can0  080   [0] 
can0  381   [6]  18 06 00 00 00 00
can0  000   [2]  02 01

From this I see that the first control word and operation mode is all 00 (message 301). The motor responds with emergency message to this. From the motors documentation this error message is:

Parameter error
The data in the received PDO is either wrong or cannot be accepted due to the
internal state of the drive.

My question is weather this is a configuration issue or a bug in ros_canopen. The motor documentation has a section describing that in order to move the motor its operation mode has to be changed first and only then the state switching should occur. Note that I have changed the switching_state parameter to 2 but this did not have any effect on init function behavior.

I believe indigo-devel should be the most up to date code.

I assume you are using this USB-to-CAN device. You are right ros_canopen only supports SocketCAN interface. If you want to use another kernel driver i.e. ECI you will have to implement a custom driver plugin. You could have a look at how socketcan_interface is implemented in ros_canopen here.

That being said it seems that your USB-to-CAN device also supports SocketCAN. The driver is located here. So you could have a look at it.

Another question is does your robot use OpenCAN protocol? If it does not then ros_canopen package might not be suitable for you at all. And even if your robot does support OpenCAN you might have to implement additional profiles because ros_canopen for now only supports basic (301) and motion control (402) profiles. But I can not comment on that more without knowing what robot you are trying to control.

Hopefully that helps to clarify things a bit.

The problem is camera sync. Your cameras are not synchronized and the processor never receives two images that would have the same time stamp and therefore never start processing images. By default stereo_image_proc uses exact sync strategy. This can by changed by modifying the stereo_image_proc.launch file.

The default file has this:

  <node pkg="nodelet" type="nodelet" name="disparity"
    args="load stereo_image_proc/disparity $(arg manager) $(arg bond)"
    respawn="$(arg respawn)" />

This should be changed to:

  <node pkg="nodelet" type="nodelet" name="disparity"
    args="load stereo_image_proc/disparity $(arg manager) $(arg bond)"
    respawn="$(arg respawn)">
     <param name="approximate_sync" value="True" />
  </node>

This will make sure that the two images are processed as soon as they are received.

Effort is the type of control of your joints where the commands that you specify for your joint are for example voltage or power. For example you could have a power controlled joint where the controller of joint motor can receive commands from 0 to 1000 (when controller receives 0 the motor would not move and when controller receives 1000 the motor of that joint would move at its maximal power).

If you had a stepper motor controller that can be only controlled using effort you would then need to specify a EffortJointInterface and the joint_trajectory_controller would internally run a PID loop to control the position of your joints using effort. Your case is different you already have a stepper controller that can be controlled using target position. You therefore have a PositionJointInterface and in this case the joint_trajectory_controller only works by forwarding the target positions directly to stepper motor controller. You can read more about different modes of joint_trajectory_controller here.

So specifying the VelocityJointInterface and EffortJointInterface in your case does not make sense.

Now in terms of trying to improve the cartesian path there are several things you could try doing. First would be to try tweaking the parameters of the stepper motor controller. This is highly dependent on the actual motor controller that you have. If this controller has a PID loop internaly you might have to tweak PID parameters etc.

All the current distributions of ROS are compiled using C++03.

You can compile your own packages using c++11 by adding the following line to the CMakeLists.txt of your project:

add_compile_options(-std=c++11)

Note that it is recomended to have checks for c++11 features at configure time and provide equivalent functionality with extra compiler features. This is only required if you are planning to release the ROS packages that you develop. If you are only planning to use your packages yourself then you can just c++11 functionality. You can read more about ROS and C++11 here: link text