-
Notifications
You must be signed in to change notification settings - Fork 39
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
Comments
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. So, something is happens in those functions. I will try to search more |
I have find these instructions inside epos.cpp:
These are the ones that slow down all the process to update the /joint_states |
@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? |
Hi, I notice this problem too. Thanks for your issue and hope someone, maybe you, fix it and push. |
Hi @JamieHuang28 and @indraneelpatil, I have not found any solution to this problem. |
@grafoteka and @JamieHuang28 As far as I remember there was no software fix for this problem. 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. |
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 ***@***.***> 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.
|
@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. |
@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. |
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. |
@JamieHuang28 So when you are trying to use these C++ driver commands in ROS to read and write data from the motors listed here Then you will notice that the frequency can go up to 10 to 20 Hz. Hope this helps! |
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.
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
The text was updated successfully, but these errors were encountered: