Replies: 44 comments 2 replies
-
|
Hi @yijiangh: thanks for starting discussion on an mxAutomation driver/interface. As I also wrote in my reply to your post to the ROS-Industrial mailing list, I'd be interested in getting such a package included in this repository. Unfortunately though I don't have access to any hardware that supports this, so any development would have to be contributed by community members such as you. I can support you with my experience with the ROS-side of all of this though. Do you already have more concrete plans for this, or are you still just gathering input? Btw:
I'm not quite sure this is true. As also stated by @BrettHemes in the ROS-Industrial mailing list post you linked to, as far as I'm aware, RSI should still be available, but it may not be too present in KUKA's marketing material now with the availability of mxAutomation. I've just sent an email to a contact at KUKA to see whether we can get a clear answer on the status of RSI. |
Beta Was this translation helpful? Give feedback.
-
|
I can find very little public documentation on mxAutomation btw, so if you have anything you can share that would make discussion a bit more meaningful. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @gavanderhoorn , thanks for your reply.
Currently no, actually my lab are negotiating with kuka to get MxA. Also I'm still open and gathering inputs.
Sure, here're some papers [1, 2, 3] related to MxA-related experiments in creative industry and documentation [4] for KUKA.PLC mxAutomation 2.1. [1] Brell-Cokcan, S and Braumann, J 2015, ‘Towards Adaptive Robot Control Strategies’, Proceedings of the 35th ACADIA Conference, Cincinnati, USA [pdf] [2] Braumann, J and Brell-Cokcan, S 2015, ‘Adaptive Robot Control’, Proceedings of the 33rd eCAADe Conference, Vienna, Austria [pdf] [3] Munz, Heinrich, Johannes Braumann, and Sigrid Brell-Cokcan. "Direct Robot Control with mxAutomation: A New Approach to Simple Software Integration of Robots in Production Machinery, Automation Systems, and New Parametric Environments." Robotic Fabrication in Architecture, Art and Design 2016. Springer International Publishing, 2016. 440-447. [4] CODESYS Library for KUKA.PLC mxAutomation 2.1 [pdf] |
Beta Was this translation helpful? Give feedback.
-
|
I was looking more for public documentation on the protocol or the way PLC vendors are supposed to integrate with mxAutomation supporting motion controllers. The papers you link are very high-level descriptions of what should be / is possible with the interface, and the CODESYS library doc seems to be just that, a reference for using the CODESYS mxAutomation library. I can't really find any OSS implementations of mxAutomation compatible libraries (or any implementations really, apart from automation vendors), so that would seem to be a first major issue to tackle. Documentation on the protocol - if any - would certainly help with that. The KUKA|prc devs appear to have implemented something, but I can't see what they are doing as the source does not seem available. |
Beta Was this translation helpful? Give feedback.
-
@yijiangh: I've just had it confirmed by my KUKA contacts that RSI is still available and here to stay. mxAutomation is not a replacement and does not sit in the same niche as RSI. The fact that you may not be able to find it on the website is a content management issue, apparently. |
Beta Was this translation helpful? Give feedback.
-
|
@yijiangh: have you had any chance to look into this? mxAutomation support is still of interest, but without access to the required hardware & software is going to depend on a community contribution. |
Beta Was this translation helpful? Give feedback.
-
|
@gavanderhoorn : Sorry for not updating for so long, my lab is still working on acquiring it from KUKA. will update as soon as we get it! |
Beta Was this translation helpful? Give feedback.
-
|
@gavanderhoorn @yijiangh I have started talking with our Kuka reps about this and learned that the newest version of mxAutomation provides C# and C++ API's for PC interfacing, however, they are currently distributed only as Windows binaries.... I will continue to look into this as I see it as a potential happy middle-ground between the EKI and RSI approaches (i.e., should be higher-performance than the EKI while also relaxing the (hard) real-time constraints of the RSI approach due to buffering of incoming trajectory points). Reading some of the KUKA|prc stuff seemed to imply that the source is available from Kuka but requires a confidentially agreement... not sure how that would work out in the scope of ROS [edit]: RSI, not SPI... |
Beta Was this translation helpful? Give feedback.
-
RSI you mean?
well .. we'd either need some kind of protocol spec, or there would need to be a library available for Linux that does the protocol handling. If neither of those are available, reverse engineering the protocol spec could be an option, but only as a last resort. How do PLC vendors interface with this? Is that all by incorporating some binary blob from KUKA? Or are they covered by the NDA? Perhaps we could try and get KUKA interested in this? Would your KUKA rep be in a position to facilitate anything? |
Beta Was this translation helpful? Give feedback.
-
|
@yijiangh: now that @BrettHemes has submitted a candidate EKI driver, I'm curious to know whether you've had any chance to take a look at mxAutomation in the meantime. @BrettHemes: you mention that you wanted to look into the libraries provided by KUKA. Have you had a chance to do that? We may be able to decompile the C# libs - provided they don't just wrap the C++ ones. |
Beta Was this translation helpful? Give feedback.
-
|
@gavanderhoorn Thanks for the follow-up. Due to funding issues, I think my lab won't be able to acquire MxAutomation before September, 2018. So I am sorry to say that I won't be able to offer any real hardware-based experiments to contribute to our efforts here at this moment. However, even if I don't have the hardware to test it, I did manage to acquire the C# source code (with MxAutomation 2.1.3 dll library) for a windows-based UDP server to connect to the MxAutomation client running in kuka controller box. I was told that this approach has been tested on real hardware and it worked like our familiar joint state publisher in ROS. I have to keep the source in private repo due to confidential issues but I've invited @gavanderhoorn and @BrettHemes to the repo. Maybe we can try on decompiling the dll library to see if there is any direction that we can work something out. |
Beta Was this translation helpful? Give feedback.
-
|
From what I've seen so far there appears to be very little actual native (ie: Win32) code in there. As we have .net core on Linux these days, it might be worthwhile to try and run the application in your repository directly. If we can do that, and it works with an actual robot, we could potentially create a driver in .net, with the KUKA assembly doing all the heavy lifting. That would also mean that we can just distribute the driver sans KUKA proprietary mxAutomation lib, which would then have to be procured by users themselves. This would be similar to how many KUKA FRI software components are distributed, and avoids licensing and various other legal issues completely. I'd be very interested in getting something like that to work, however I don't have any hardware to test anything. @BrettHemes: do you have access to any mxAutomation hardware? |
Beta Was this translation helpful? Give feedback.
-
|
Looking through the example application included, it looks like the actual mxAutomation functionality is completely encapsulated by the provided assembly. Data coming from the controller is read from a UDP socket and the buffer is then passed to the assembly for parsing. Setting new axis goal positions, toggling IOs, etc is all done on the same assembly objects, and those actions are then serialised into an application provided byte buffer which is sent to the controller again over the same socket. Such a design makes sense, as it completely decouples the transport from the proprietary mxAutomation IP and protocol (de)serialisers. It also makes application design relatively straightforward, as there is only a very simple interface between an application and the mxAutomation assembly. Control over data going in and out of the application is also completely left to the application, with the assembly objects control flow being driven by that same application. Conceptually this looks like the following: while True:
buf = read_socket(..)
mxa_in.data = buf
mxa_in.update()
# insert application logic here, sets properties of mxa_out based on state of mxa_in
out_buf = mxa_out.update()
write_socket(out_buf, ..)
sleep(..)Being a native .net DLL might actually make the idea I posted in my previous comment possible: it doesn't look like the assembly uses anything apart from standard .net functionality, which should be supported by the .net core runtime. |
Beta Was this translation helpful? Give feedback.
-
|
Linking this here for future reference: mono/Embeddinator-4000. |
Beta Was this translation helpful? Give feedback.
-
|
I've done some minimal tests (got nerd-sniped) with .net core 2 and a very minimal c# prog (basically a stripped version of the As I have no robot to test with that is all I can do. If anyone is interested in continuing this post a comment here and we'll see how we can collaborate. If you are in Europe and are interested in this, this could be a good ROSIN FTP. |
Beta Was this translation helpful? Give feedback.
-
|
I assumed such... thanks for the heads up. I will continue digging. |
Beta Was this translation helpful? Give feedback.
-
|
I just learned that we do actually have a KRC4 with mxAutomation here at the university, so I may be able to test some things in the near future. As I have a lot of other things as well, it may be some time before I can do anything, so my offer of assisting interested parties stands. |
Beta Was this translation helpful? Give feedback.
-
|
@yijiangh: any updates here? |
Beta Was this translation helpful? Give feedback.
-
|
@gavanderhoorn Trying to push my lab for a purchase of the MxAutomation package during the summer! I'll come back and report as soon as we have it. |
Beta Was this translation helpful? Give feedback.
-
As long as it's not on our behalf :) |
Beta Was this translation helpful? Give feedback.
-
|
@gavanderhoorn oh definitely not... There are some requests from our student on using this too. So in this case, it's a purchase qualified for both research and educational purposes :) |
Beta Was this translation helpful? Give feedback.
-
|
@gavanderhoorn Sorry I am just being told that my lab does not have a plan to acquire MxAutomation in short term. Thus, I have to say that the development in MxAutomation support can't get very far on our side without the hardware. 😢 |
Beta Was this translation helpful? Give feedback.
-
|
That is unfortunate. We'll keep this open for a little while longer (so as to keep the issue visible), but we'll close it if there are no further updates. @BrettHemes: any updates from your side? |
Beta Was this translation helpful? Give feedback.
-
|
I would be interested in helping with this in some capacity. We have a KR60-3 with KRC4 and an mxAutomation license (also just purchased an RSI license EDIT: and EKI license). I have yet to do any substantial testing of mxA, and I am new to ROS, but I am eager to immerse myself as this may be foundational to our research going forward. It would be great to be able to leverage ROS with our KUKA platform. |
Beta Was this translation helpful? Give feedback.
-
|
That would be great @daneisinger. For a driver not a lot of ROS knowledge/experience would be needed, although for testing it you'd probably need something of a working setup. The first task would probably be to get a feeling for what mxAutomation can and cannot do. Typicaly ROS robot drivers expose a The other functionality might be worth exposing as well, but we can look into that at a later time. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, non-Cartesian motions are definitely possible through the KRC_MoveAxisAbsolute function block. There are also function blocks for reading current axis positions (and other info) and doing I/O.
I believe I have the same software (the mxAutomation_Example UDP server) and I'm curious--what functionality did you see in the software that did not appear to be covered in the manual? |
Beta Was this translation helpful? Give feedback.
-
|
@daneisinger wrote:
This was some time ago, and I don't have my notes with me. I was looking at the provided assemblies at the time using a CLR disassembler and I believe I found references to (internal) things that did not appear to be documented. Whether those are things we want to use, not sure. |
Beta Was this translation helpful? Give feedback.
-
|
Any news on this topic? I'm interested in controling KUKA with mxAutomation over PROFINET. Based on this document there is already an implemented PROFINET interpreter for mxAutomation . What I have found in KUKA documentations is information about the PLC-OPEN block diagrams ready to use with Siemens S7. And based on the above mentioned document, it is possible to control the Kuka robot with S7 over Telegram 2032 (programming visually in TIA portal). As I have already integrated PROFINET over Siemens CP1626 inside my ROS platform, I'm interested to control the arm also over PROFINET as an IO device. My current blocking point is some missing information about the mapping between Telegram 2032 Bytes and I/O data used in the PLC-OPEN block diagrams. Any Idea? @daneisinger : Are you using UDP for mxAutomation communication? Any advancement on the implementation? I'm also interested to contribute. Regards, |
Beta Was this translation helpful? Give feedback.
-
|
I'm not aware of any progress on this front. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any news concerning the integration of mxAutomation ? My organisation is considering buying the option to try it out. |
Beta Was this translation helpful? Give feedback.
-
|
No. No updates. It would also probably not really 'fit' with the |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your reply ! |
Beta Was this translation helpful? Give feedback.
-
Refer to the discussion in swri-ros-pkg-dev google group discussion.
I'm proposing the development of support for kuka mxautomation[3, 4], a new interface package provided by kuka. It seems like kuka has stopped selling rsi package and we cannot find it on their website anymore.
The attached pictures are some of the quick glimpse on mxautomation's feature.
Happy to hear opinions and suggestions.
Best,
Yijiang
Reference:
[1] Munz, Heinrich, Johannes Braumann, and Sigrid Brell-Cokcan. "Direct Robot Control with mxAutomation: A New Approach to Simple Software Integration of Robots in Production Machinery, Automation Systems, and New Parametric Environments." Robotic Fabrication in Architecture, Art and Design 2016. Springer International Publishing, 2016. 440-447.
[2] Braumann, Johannes, and Sigrid Brell-Cokcan. "Adaptive Robot Control." Proceedings of the 33rd eCAADe Conference, Vienna, Austria. 2015.
[3] https://www.kuka.com/en-us/products/robotics-systems/software/hub-technologies/kuka,-d-,plc-mxautomation
[4] http://store.codesys.com/mxautomation.html?___store=en&___from_store=default
Figure 1 - mxAutomation control concept. Software components provided by KUKA are marked orange. (Picture courtesy from [1])
Figure 2 - Location of command logic: Entirely on the robot controller for regular control data files (SRC), entirely on the external controller for real-time controllers (RSI), distributed command logic (NEW) (Picture courtesy from [2])
Beta Was this translation helpful? Give feedback.
All reactions