-
Notifications
You must be signed in to change notification settings - Fork 179
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
start_time - amount of motors multiplies the amount of time it takes to execute a joint_trajectory #341
Comments
Hi @jan-krueger |
This is still happening for me as well, and seems to be related to #306 from 2020, and appears to have actually been fixed in PR #238 from 2019. @ROBOTIS-Will When can we expect to see a resolution here? This is a particularly critical bug to fix because it fundamentally breaks JointTrajectory commands with multiple motors. |
Hi @jan-krueger @cbteeple The issue arises because the motors are being processed sequentially rather than running in parallel. I agree with @ROBOTIS-Will's perspective. If you're using multiple motors, I would not recommend using our controller example. Additionally, I believe that using sync read and bulk read is the proper approach instead of the method suggested in the PR. Could you please elaborate further on why you think the code in the PR is the correct approach? |
This issue will be closed due to prolonged inactivity. If the problem persists, feel free to reopen it, and we will address it promptly. Thank you for your understanding! |
Before you open issue, please refer to ROBOTIS e-Manual
How to setup? N/A - I think
Which Dynamixel have you used? and how many? (Please describe below format to all connected Dynamixels)
Write down the commands you used in order
I launch a custom launch file that looks like this:
Please, describe detailedly what difficulty you are in
I use this code to move to two different positions, and this works fine. So the kinematics are correct. The issue is that when I set e.g. the time_from_start to 2.5, 5, 10 seconds (it doesn't really matter) it always takes time_from_start * n (where n is the amount of motors that are being commanded) to actually execute the trajectory. I have tested this by adding a fourth motor and then it would multiply the time by before. I could fix this by simply dividing the time by the amount of motors but that seems hacky, and I am not sure what is going wrong.
In the sample output I set the time to 2.5/3 to test my theory, and it took 2.5s to move the arm in total.
The text was updated successfully, but these errors were encountered: