ros_industrial

[akjay]

Since this drive has require of the AS version, did Kawasaki has plan to create a driver use ros_industrial ?

[d-nakamichi]

No, currently we have no plan for using ros_industrial.
To control our robot arms, it needs our robot controller and this khi_robot

[gavanderhoorn]

Perhaps @akjay could clarify what he understands to be drivers "which use ros_industrial"?

[akjay]

Perhaps @akjay could clarify what he understands to be drivers "which use ros_industrial"?

OK,so far as I know,the khi_robot has minimum requirements ,for OpenAS series controller must be higher than ASE401010XX3S version,this because the communication between ROS_PC and robot_controller via libkrnx need to be,otherwise,the connection cannot be successful.
While,ros_industrial implement a interface that we can just use basic TCP/IP socket to recevive joint_cmd and feedback joint data.And for every robot,the basic TCP/IP socket is the same, no version requirements, so I think a driver use ros_industrial can be widely used in most Kawasaki robots.
Actually,because my robot RS020N can't satisfy the minimum requirements of controller version,as I talked via email with @d-nakamichi before, I tried to write a basic demo via this method.Use Moveit! plan a trajectory,and then I send the trajectory data to robot via TCP write by myself,on the robot_controller, parse the data,and construct motion command such as "MOVEJ #point" in pg program,while in background pc program, feedback the joint position periodically.In this way,the robot now can execute Moveit! trajectory,but a little bit pity is that at every path point, the robot will stop, I looks like a little silly, not smooth.I want the execute result is robot not stop at every path point,only stop at the end point of the path.
I forked ”kawasaki_experimental“ from your repo, it seems that this project is stop updating now,and only have some moveit_config files.

[gavanderhoorn]

Ok, now I understand.

The repository you found was part of an early attempt to create something like what you describe. It uses regular TCP/IP sockets to publish joint states and execute motions.

Due to some internal changes in staffing, we never really finished it, but the communication infrastructure did get used in another project: G-Paris/kawapai (AS side here). This is not finished, but perhaps the protocol (partial documentation) could be used for what you mention.

Perhaps the main author (@G-Paris) would be interested in continuing or at least giving some guidance.

Note: this does not use the simple_message protocol. We did start with that, but it turned out there were some limitations in AS (IIRC) which made that a bit more work than we had time. In the end, we created a simple, text-based protocol which is similar to simple_message, but not identical (and thus not compatible).

but a little bit pity is that at every path point, the robot will stop, I looks like a little silly, not smooth.I want the execute result is robot not stop at every path point,only stop at the end point of the path.

It's been a while, but I remember we either had plans to add support for blending, or it was actually implemented. I'm not sure any more.

Note: the repository I link to is not a replacement of khi_robot. In fact, one of the other reasons we stopped working on that project was the release of khi_robot.

[akjay]

OK, Thank you.
Firstly I tried to use khi_robot, but my robot can't satisfy the OpenAS version, and after talk with my dealer, it's a little complex for update.
I will checkout this project you mention to learn how to use it,Thank you!

[G-Paris]

Hello Gijs, Akjay, We did implement "blending" in the Kawapai implementation. Using Kawasaki's CP (Continuous path) motion, this feature is well documented in Kawasaki's AS-language manual. The motion described by Akjay should be possible. Kawapai was also privately hacked by some of our students and used in one of the SMR projects: Tetrisrobot <https://www.robotminor.nl/tetrisbot/>, as you can see in the clip the motions were fluid. Time is limited but I can offer some guidance if there are questions regarding Kawapai/Kawasaki. Kind regards, Guus Op wo 13 jan. 2021 om 09:35 schreef G.A. vd. Hoorn <[email protected]

…

: Ok, now I understand. The repository you found was part of an early attempt to create something like what you describe. It uses regular TCP/IP sockets to publish joint states and execute motions. Due to some internal changes in staffing, we never really finished it, but the communication infrastructure did get used in another project: G-Paris/kawapai <https://github.com/G-Paris/kawapai/tree/develop> (AS side here <https://github.com/G-Paris/kawapai/blob/develop/kawapai/kawasaki_side.as>). This is not finished, but perhaps the protocol (partial documentation <https://github.com/G-Paris/kawapai/blob/develop/protocol.md>) could be used for what you mention. Perhaps the main author ***@***.*** <https://github.com/G-Paris>) would be interested in continuing or at least giving some guidance. Note: this does not use the simple_message protocol. We did start with that, but it turned out there were some limitations in AS (IIRC) which made that a bit more work than we had time. In the end, we created a simple, text-based protocol which is similar to simple_message, but not identical (and thus not compatible). but a little bit pity is that at every path point, the robot will stop, I looks like a little silly, not smooth.I want the execute result is robot not stop at every path point,only stop at the end point of the path. It's been a while, but I remember we either had plans to add support for blending, or it was actually implemented. I'm not sure any more. Note: the repository I link to is not a replacement of khi_robot. In fact, one of the other reasons we stopped working on that project was the release of khi_robot. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF4WMCPOOKPDS3I3IA7RFFTSZVLNTANCNFSM4V5JA6AA> .

[gavanderhoorn]

@G-Paris: did those students make any improvements? Did those improvements end up in the main repository?

[G-Paris]

Improvements=Some hacks, but no, asked them multiple times, but sadly I think possible improvements are lost. Op wo 13 jan. 2021 om 15:57 schreef G.A. vd. Hoorn <[email protected]

…

: @G-Paris <https://github.com/G-Paris>: did those students make any improvements? Did those improvements end up in the main repository? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF4WMCIE7SSODVE2I7BIFGDSZWYHDANCNFSM4V5JA6AA> .