-
Notifications
You must be signed in to change notification settings - Fork 84
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
Add a function to store the xarmX-moveit_config package #73
Comments
Hi, thanks for your feedback and suggestion, we understand the inconvenience you encountered and we will see if there is any better solutions we can come up with. The thing is we started ROS2 support at a very early stage and there were no moveit configs builder, even no setup assistant available for Moveit2 at that time, we have to do a lot of hand codings in order to make everything work, this is part of the reason we had this structure. We will take some time to do assessments and code studies, will let you know if the function you mentioned can be implemented. Thanks. |
we are also in a need for setup assistant support, please advise how to proceed. |
I agree with @gaspatxo here. I appreciate the effort you guys put into making this package easy to use. However, when more customization is needed, it becomes very challenging with the current setup. For instance, in our case, we have a custom gripper with several TCPs, which means we cannot simply add it using your Now, we want to switch from |
Hi, I really appreciate all your efforts into making a generalised package for your whole suite of products, it is great code what you have written. However, I invite you to reflect on the fundamental design choices of the package through the following reflections.
Why reinvent the standard? ROS already comes with clear ways to configure and use robot arms, the
*_moveit_config
package which should correspond to one arm. Modifying these by the user is usually an easy task thanks to official tools such as moviet_setup_assistant and plenty of documentation. By creating a custom-made solution, users have to learn a new way of going about things; when things do not work or are unclear, what could have been a quick query on a browser becomes an issue in this repository, which delays the user and creates unnecessary work for you.Is generalization that important? Not only is it already easy to change arms in the standard moveit way of doing things, but is it even the average need for a user? I reckon most of your clients do not have a lot of arms and different models at the same time, with the same code having to run on all of them; it feels like this solution is tailored to the devs, not the users.
Is it really generalized? It actually constrains software development efforts from folks like me, who are developing software that should work for any ros-enabled robotic arm, this software package has forced me to invest weeks of development on finding/implementing solutions for the xarm7, when I intend to make a package that should work (with as little tweaks as possible) with any robot arm, be it UFactory, Fanuc, Motoman, UR, etc. Again, this issue comes from chosing not to use the already established standard by Moveit2.
Now, I do not mean any of this as an attack, I understand some of the efforts behind the package and it is undeniable how easy you made it to configure end effectors and scenes. And I believe that there is a solution that takes the best of both worlds: a function in
MoveItConfigsBuilder
that generates the package and files. This allows for the ease-of-use of everything developed so far, but also allows for the further customization and standard usage of Moveit2.Please let me know your thoughts on this issue. I am happy to answer any questions from the perspective of a user if you have interest in it.
The text was updated successfully, but these errors were encountered: