Posts by fishku

    How would I use the rotation matrix to generate an interpolation between two orientations?


    I would also be interested in pseudo code that explains, conceptually, what is going on when doing a linear interpolation between two orientations.

    As you probably know, KRL uses Euler angles to represent orientations and rotations. I wish to do a linear interpolation between two rotations.
    However, I run into many problems related to direct linear interpolation (lambda * a.angle + (1-lambda) * b.angle) of Euler angles. Problems include wrapping around +/- 180 degrees, interpolation not giving the shortest path between two orientations, etc.


    Has someone solved linear interpolation between Kuka Euler angles in a nice fashion?


    I am thinking about converting the Euler angles to quaternions, where linear interpolation is beautiful and simple with no issues. However, the conversion itself is not so beautiful, and I need to be careful with the coordinate systems. Has anyone done the conversion from a KRL Frame to quaternions for orientation / rotation before?


    Thanks!

    Sorry, can't share the code.
    It is a rather simple system though: Basically, I have a "state" variable that can switch between different states such as "moving", "waiting", "move request", etc. On the PC side, I can update a position variable, then I set the state to "move request". The KRL script running on the robot has a "WAIT FOR STATE <> #WAITING" line. After changing the variable to "move request", it will read the position variable and move to it.

    It seems like you are simply running the JOSV script wrongly: You have to specify the IP and the port in 2 separate runtime arguments. Depending on your setup, you have to specify this in the java code, or using the command line version, you would have to write something like:

    Code
    java -jar path/to/JOSV-script.jar 172.31.1.147 7000


    Make sure you can ping the 172.31.1.147 IP from your PC:

    Code
    ping 172.31.1.147


    And that you can ping 172.31.1.150 from your robot. On the kuka smartpad, you might need to "minimize HMI" to reach the windows OS, then ping from there.

    To update on this topic, we are now using JOpenShowVar. I have implemented a rather convoluted system which interfaces the JOpenShowVar console application using C++ on the PC side. On the robot side, I have programmed a custom KRL script which listens to different commands from the PC and executes them, using a very simple state machine. I can communicate at around 10 commands / second, which is enough for our purposes.

    Hi all!


    I have a situation in my KRL program where I try to move "forward" (+x in my situation) with respect to the current hand orientation, meaning the robot should move in the direction that the tool on the hand is pointing. I have two questions:
    1. How do I do this? I have tried setting the $TOOL variable's a, b and c rotations to hold the values of the $POS_ACT variable. In my mind, this should rotate the tool to be aligned with the current hand orientation. However, when I do a relative PTP command after that, it will move relative to the world axes (while also doing a slight rotation, which I do not comprehend). If I do not change the $TOOL variable at all, the relative PTP command will also result in a movement relative to the world axes (while not doing any rotation).
    2. When jogging in T1 mode, using the +x button does exactly what I want to do. It moves relative to the current hand orientation. When watching the "current position" window while doing the jogging, I can however see that it does a complex change in x, y and z coordinates. Why is the behavior of T1 mode different than in the program, using relative PTP commands?


    I think I am missing some fundamental property of the way coordinate systems are handled in jogging vs. automatic mode. Please enlighten me!


    RSI is not what you want, unless you expect to be doing hard-realtime vision corrections at 12ms or better.


    EthernetKRL, or EKI, is about the only way to get a KRC4 to talk to a PC directly. The good news there is that from the PC side, it's a simple port-based data transfer, little different from sending data between two PCs, and the EKI installer comes with an example C "server" program that can send/receive data from an EKI process.


    Thank you. Indeed, it seems like RSI is overkill for what I want to do, as the timing constraints are much higher, and are only soft constraints.



    Well opc server is another option but setup can be challenging, i would probably go with EthernetKRL it seems easier to most people....


    I'm checking all the options, thanks. Another option seems to be the open source alternative "JOpenShowVar", which is based on the seemingly-outdated "OpenShowVar". Do you have any experience with it?

    Hi all


    I want to remote control a KR6 R900 from my laptop (Mac OS X). More specifically, I want mount a camera on the robot (connecting to the laptop via a long USB cable), then analyze the images on the laptop, and from this generate the new positions for the arm.


    We have a KR C4 compact controller (KSS V8.3). I have connected the laptop and the C4 with an ethernet cable, plugging it into the X66 port of the C4. The KLI port on the C4 is occupied and there's a cable leading inside the case.
    Is X66 the correct port for my endeavor?
    Pinging between the laptop and the C4 works fine.


    Now, I am not clear on how to proceed on the software side either. I have searched the forums, and it seems like there are (at least) 3 options:
    - RSI Ethernet, sending binary data (?)
    - Ethernet RSI XML, sending commands in XML data packages
    - Ethernet KRL, sending KRL commands (?)
    Which of these would you recommend, also in terms of available ease of setup, documentation, example programs, etc.? Then, how can I proceed with the setup?


    I have also found a couple of open source implementations which would run on the laptop. One example is "KCT", "KUKA Control Toolbox", which would use Matlab. From what I understand, KUKA switched from TCP to UDP as a transmission protocol in a recent version change, meaning that older software like the KCT is not usable anymore. Is this correct?


    Thanks a lot!