Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

joint_state too slow #23

Open
grafoteka opened this issue Mar 15, 2018 · 11 comments
Open

joint_state too slow #23

grafoteka opened this issue Mar 15, 2018 · 11 comments

Comments

@grafoteka
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link

@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
Copy link

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

@grafoteka
Copy link
Author

Hi @JamieHuang28 and @indraneelpatil,

I have not found any solution to this problem.

@indraneelpatil
Copy link

@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
Copy link
Author

grafoteka commented Feb 1, 2019 via email

@indraneelpatil
Copy link

@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
Copy link
Author

@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
Copy link

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
Copy link

indraneelpatil commented Feb 27, 2019

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants