No motion with SIA20F, FS100, alpha60 #395
Answered
by
gavanderhoorn
ashwinsnambiar
asked this question in
Troubleshooting
-
|
I have been trying to setup the SIA20F robot with the FS100 with alpha60 version of the MotoRos2 binary. I am currently able to start and stop the servos of the robot via the /start_traj_mode and stop_traj_mode service calls. But, when I tried moving the robot with an action client, it did not receive any response from the action server. To make sure that it was not an error with the client, I tried to send requests with |
Beta Was this translation helpful? Give feedback.
Answered by
gavanderhoorn
Mar 20, 2025
Replies: 2 comments 9 replies
-
|
To get it out of the way -- and perhaps/probably reiterate it: Caution the binary you are using is essentially unsupported. It was / is a development build solely intended for MotoROS2 developers to test the (then) state of the FS100 port that was in progress. As #227 (comment) made clear, the port was not completed and is not guaranteed to actually work. Having written all of that, and if you still wish to continue debugging the issue you are running into, I would recommend you start an instance of the debug listener and restart your FS100. Keep the logger active and try again to enable the trajectory mode, then submitting a goal. The logger should show you what MotoROS2 is (trying to) do(ing). Post the output of the logger here, verbatim in a fenced code block or attach the If using any custom code (ie: an action client), please also include that in your post. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Yes, I understand very well that the version is still in the development phase and might not work properly. I'm ready to try debugging the issue. I've already tried starting an instance of the debugging tool. It did not register any logs when I tried to run the action client and even with the |
Beta Was this translation helpful? Give feedback.
-
|
I was trying to reproduce the error again today. But, surprisingly, the action server responds now to both the direct requests via There was an initial issue yesterday with an old MotoRos Few things, I noticed while running the debug_listener from the rebooting the controller,
Click to expandI'm trying to get the robot configured with MoveIt2 planner, next. Will keep updating! Thanks for the quick response!!! |
Beta Was this translation helpful? Give feedback.
8 replies
-
Another similar thing, regarding the joint positions I wanted to point out, was the order in which the joints were printed out on calling the |
Beta Was this translation helpful? Give feedback.
-
|
That's as expected. Internal Motoman order has the 7th axis as the 7th joint, but that joint is physically / logically the 3rd. On the ROS side we use the 'logical' order (ie: starting with the first joint, follow the chain of joints along the arm until you get to the flange). So If your question/comment was about As long as all consumers avoid making assumptions about order of elements in the various arrays/lists in |
Beta Was this translation helpful? Give feedback.
-
|
That clears my confusion regarding the joint names, its order and the naming nomenclature. That just leaves the time synchronisation part. When I try using MoveIt, it says cannot fetch the current joint states at the required time. Could you help in debugging this problem? |
Beta Was this translation helpful? Give feedback.
-
|
This could be due to the broken timestamps on I'd suggest to check the QoS settings in the config file. |
Beta Was this translation helpful? Give feedback.
Answer selected by
ashwinsnambiar
-
|
Thank you @gavanderhoorn. Changing the QoS setting for the |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This could be due to the broken timestamps on
JointStatemessages, but could also be due to MoveIt not receiving any messages caused by QoS mismatch.I'd suggest to check the QoS settings in the config file.