joint_state too slow

[grafoteka]

Hi, finally I'm working with this package, but I have a problem. When I try to show the motor position in RViz, the representation of the motor is too slow. When the physical motor has reached the position, the motor in RViz has not started to move, and then it jumps to another position.

I have look in the code, but I have not found where the epos_hardware_node.cpp publish to joint_states.

Also, in the launch file this line is commented:

remap from="epos_hardware/joint_states" to="joint_states"

But there is not any topic called epos_hardware/joint_states and also, epos_hardware is publishing in /joint_states.

jorge@i7:~$ rosnode info /epos_hardware 
--------------------------------------------------------------------------------
Node [/epos_hardware]
Publications: 
 * /diagnostics [diagnostic_msgs/DiagnosticArray]
 * /joint_states [sensor_msgs/JointState]
 * /rosout [rosgraph_msgs/Log]

Subscriptions: 
 * /position_controller_1/command [unknown type]
 * /position_controller_2/command [unknown type]
 * /position_controller_3/command [unknown type]
 * /position_controller_4/command [unknown type]
 * /position_controller_5/command [unknown type]
 * /position_controller_6/command [unknown type]

Services: 
 * /controller_manager/list_controller_types
 * /controller_manager/list_controllers
 * /controller_manager/load_controller
 * /controller_manager/reload_controller_libraries
 * /controller_manager/switch_controller
 * /controller_manager/unload_controller
 * /epos_hardware/get_loggers
 * /epos_hardware/set_logger_level

And when I ask for the rate (rostopiz hz /joint_states) of /joint_states is only 3Hz Could someone help to find out where the package publish and with which rate?

Thank you

Kinds regards, Jorge

[grafoteka]

Ok, so I have try to comment robot.write() and robot.read() in epos_hardware_node.cpp

If I comment one of both, the publish rate is like 10Hz. If I comment both, the publish rate can reach 1000Hz.

So, something is happens in those functions. I will try to search more

[grafoteka]

I have find these instructions inside epos.cpp:

  VCS_GetObject(node_handle_->device_handle->ptr, node_handle_->node_id, 0x6041, 0x00, &statusword_, 2, &bytes_read, &error_code);

  VCS_GetPositionIs(node_handle_->device_handle->ptr, node_handle_->node_id, &position_raw, &error_code);
  VCS_GetVelocityIs(node_handle_->device_handle->ptr, node_handle_->node_id, &velocity_raw, &error_code);
  VCS_GetCurrentIs(node_handle_->device_handle->ptr, node_handle_->node_id, &current_raw, &error_code);

These are the ones that slow down all the process to update the /joint_states But I don't know how to modify them or change

[indraneelpatil]

@grafoteka Hello! Have you found any solution to this? I have the same problem. I am not able to increase the frequency of joint_states topic. Any help?

[JamieHuang28]

Hi, I notice this problem too. Thanks for your issue and hope someone, maybe you, fix it and push.

[grafoteka]

Hi @JamieHuang28 and @indraneelpatil,

I have not found any solution to this problem.

[indraneelpatil]

@grafoteka and @JamieHuang28 As far as I remember there was no software fix for this problem. Because of USB's inherent latency, the frequency of the joint_states topic could not be increased beyond a certain limit (20 Hz).

Anyone in search for a better sampling frequency is advised to switch to another communication protocol like CAN bus. Just putting this out there for anyone who runs into this issue in the future.

[grafoteka]

Hi Indraneel,

Have you get a good connection with this package and CanBUS?

Enviado desde mi iPhone

El 1 feb 2019, a las 14:42, Indraneel Patil notifications@github.com escribió:

@grafoteka and @JamieHuang28 As far as I remember there was no software fix for this problem. Because of USB's inherent latency, the frequency of the joint_states topic could not be increased beyond a certain limit (20 Hz).

Anyone in search for a better sampling frequency is advised to switch to another communication protocol like CAN bus. Just putting this out there for anyone who runs into this issue in the future.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[indraneelpatil]

@grafoteka So I had contacted EPOS Technical support regarding this issue and they suggested CAN interface to me to improve sampling frequency by about 10 times.

Unluckily since I could not get my hands on the USB to CAN converter I have not tested the hypothesis myself and I do not have better news for you. Really sorry about that.

[grafoteka]

@indraneelpatil I try with the IXAAT Can adapter, but with this package it was impossible to config this connection, and then with the ROS CAN packages I couldn't.

[JamieHuang28]

When running epos_hardware, I found the upper limit of frequency is about 3Hz. However, I had made programs in LabVIEW and in Visual Studio with given API, both of them can log the states of motor up to 50Hz successfully.

[indraneelpatil]

@JamieHuang28 So when you are trying to use these C++ driver commands in ROS to read and write data from the motors listed here http://docs.ros.org/indigo/api/epos_library/html/Definitions_8h_source.html You will notice that each command has a latency which will be distinct from the other. So what I would suggest you to do is to go through the epos_hardware code and comment out the driver commands which aren't useful in your application.

Then you will notice that the frequency can go up to 10 to 20 Hz. Hope this helps!