-
Notifications
You must be signed in to change notification settings - Fork 181
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
increase max number of joints in simple_message/joint_data.h #147
Comments
@tstoyanov thanks for the question. As our support has grown for dual arm-ed manipulators this limitation has become clear. We created a ROS Enhancement Proposal (REP), here to address this, and we have a prototype implementation that hasn't been released. As you point out, the robot clients would also have to be updated. As for your specific issue, there are two possible approaches:
|
Personally, I not sure whether changing that constant in the current version of the Secondly: increasing As @shaun-edwards mentions, there is a REP for an extension of Simple Message that changes the messages used from fixed-size to dynamically-sized, complete with fields for encoding the exact nr of joints in a motion group. While the robot controller may still have a fixed maximum nr, the protocol does not make any assumptions anymore and allows for 2^31-1 (signed 32 bit integer) groups, each with 2^31-1 joints in a single message. Controllers that need it can use as many as they want, while simpler setups would actually see reduced msg sizes and network traffic. My preference would be for all robot drivers in ROS-Industrial to move to the new messages, instead of upping the value of |
ros-industrial/rep#13 is a PR that intends to update |
@shaun-edwards @gavanderhoorn |
@tstoyanov, the client (ROS) side code is available, but it would require development on the ABB side to handle the new, dynamically sized , simple messages. Would you be willing to do this development? |
I have some experience writing the server side for the IRCv2, so I could assist. |
I can give it a try, sure. I have some idea about rapid and I have access to an irc5 for testing. How do I get the ros side code? |
@shaun-edwards can provide it to you. If we do this, I'd very much appreciate it if we can first discuss your implementation approach a bit. Just to streamline development and to avoid unnecessary duplication of effort and frustration later on. |
I'm certainly in favor of avoiding frustration :) Drop me a line at |
@JeremyZoss, can you help me out with this while I'm on vacation. Let's talk in the office tomorrow (Tuesday). |
I just added my Please let me know if you have questions or difficulty with these new packages. It may be a bit tough to dig in, since documentation is slim, but usage is similar to the previous |
Is there any reason which prevents initializing the number of joints within the init function? It could be defaulted to 10 to remain backwards compatible. |
Technically I don't think there is a reason, but it wouldn't really address the issue of all the (implicit) assumptions in existing robot drivers and user code we don't know about. Are you looking to increase the max nr of joints like @tstoyanov? |
@Karsten1987, are you looking to reuse the message or simply compile a ROS-Industrial client that supports more joints? I originally made it "hard" to change the number of joints because it would cause issues with standard ROS-I serviers on the controllers (as @gavanderhoorn mentioned above). I assumed if anybody wanted to do anything special, they would fork the library as @tstoyanov did. As mentioned above, we'd like to move toward a the dynamically sized message set. If you are interested in a more flexible robot client, that could be achieved by setting the number of joints by a ROS param (with 10 as the default). This would also require passing the number of joints through several classes. |
@tstoyanov Yes, I have pretty much exactly the same use case. As for now, I can live with forking the simple_message and yumi package and apply my modifications locally. Nevertheless, I am looking forward to the dynamically sized message. |
Seeing as |
Hi,
I am using the simple_message and industrial_robot_client packages for creating interfaces to the ABB YuMi robot. The packages work rather fine and I have MoveIt and basic ros_control support integrated, over the ros_industrial communication protocol (see https://github.com/rtkg/yumi).
The issue I had to work around though is that currently the maximum payload in a joint message is limited to 10 joints, while YuMi has two 7 DoF manipulators. There are two ways to solve this: either treat the manipulators separately and run two trajectory downloaders, or change the static define in simple_message/joint_data.h, e.g.:
static const industrial::shared_types::shared_int MAX_NUM_JOINTS = 20;
I know this would require a corresponding change on the robot controller side for most supported robots. In case of higher DoF robots however, this is the only option if we want to execute synchronized motion for all joints.
What is the general opinion, would you agree to such a change?
The text was updated successfully, but these errors were encountered: