Posts by JLoop

I know you say you've tried changing stiffness and additional force, but that does sound like the standard way to approach the problem you have. If that doesn't work with the sensitivity you need I expect you may be near too the robot limits of sensitivity. That said, it's worth considering exactly how best to set up your impedance mode.

So we can get better understanding of your process, how much force are you looking to apply?

Stiffness, damping and additional forces in an impedance control mode are applied in the direction of the tool coordinate frame, rather than base or world. Make sure you have configured the TCP orientation and set up your CartesianImpedanceControlMode correctly. As you want to follow the surface with a constant force, you don't want a significant contribution to the TCP force to be based on displacement from the 'hold' position, as such you want a very low Stiffness in the working direction. Damping is probably fine as the default. All of the work you want to be done by an AdditionalControlForce in the tool working direction.

It's worth considering the robot pose you are using during the operation. Near to any singularities the torque sensors become less accurate at calculating the TCP force. A quick way to do this is to set up a program with an endless while loop that prints the Force/Torque and ForceInaccuracy (ForceSensorData.getForceInaccuracy()), then jog the robot around. Limit your print outputs to every 500ms.

It might be worth spinning up your tool and seeing what effect that has on the recorded forces/torques. Gyroscopic effects and all sorts might be throwing off the force readings. Also, thinking about it, you must be running with some sort of powerchain up the robot flange - that is likely to be harming your force accuracy if it's strapped to the iiwa along it's length.

If you aren't able to get the results you need just using an impedance mode position hold, you could try mounting a roller/low friction surface on your tool and recording the positions that makes with the surface as the turntable rotates. You could use a higher force to ensure that surface contact is maintained. This would require either knowing the absolute position of the turntable, or being able to synchronise the movement. You could then actively drive the robot to match those positions.

I have also experienced a corrupted RoboticsAPI.data.xml. For me this happened when powercycling, turning the power back on to the controller before it had finished switching off. This was likely in an older Sunrise OS, I haven't had it happen in 1.11, although now I always wait for it to fully switch off.

I am using the standard Kuka implementation, as described in the Sunrise OS 1.11 System Integrator manual chapter 12.3.

The client we have built in C#, however the sample code provided by Kuka in the manual exhibits the same failure.

import java.net.*;
class UdpSample
{
    public static void main(String args[]) throws Exception
    {
        DatagramSocket mySocket = new DatagramSocket(30333);


        // robot address (please adjust IP!)
        InetSocketAddress robotAddress =
                new InetSocketAddress("172.31.1.147", 30300);


        // get robot state
        byte[] msg = String.format(
                "%d;0;Get_State;true", System.currentTimeMillis())
                .getBytes("UTF-8");
        mySocket.send(new DatagramPacket(
                msg, msg.length, robotAddress));


        // receive answer state message
        byte[] receiveData = new byte[508];
        DatagramPacket receivePacket = new DatagramPacket(
                receiveData, receiveData.length);
        mySocket.receive(receivePacket);


        // extract counter
        String[] stateMessage = new String(
                receivePacket.getData()).split(";");
        long counter = Long.parseLong(stateMessage[2]);


        // start application by sending a rising edge
        // (false->true) for App_Start
        msg = String.format("%d;%d;App_Start;false",
                System.currentTimeMillis(), ++counter)
                .getBytes("UTF-8");
        mySocket.send(new DatagramPacket(
                msg, msg.length, robotAddress));
        msg = String.format("%d;%d;App_Start;true",
                System.currentTimeMillis(), ++counter)
                .getBytes("UTF-8");
        mySocket.send(new DatagramPacket(
                msg, msg.length, robotAddress));


        mySocket.receive(receivePacket);
        stateMessage = new String(
                receivePacket.getData()).split(";");
    }
}

Running this short program starts the robot moving fine. You can stop it from the pendant and run the program again and it picks up the correct packet count and starts the robot program going again. Once you change the operating mode then put it back to AUT, or deploy a project, the robot returns -3 error in the response packet.

Iiwa 7 R800
Sunrise OS 1.11

When using external control over UDP, it stops working after changing the robot mode, or deploying an updated project.

AUT over UDP works fine when starting from a zero received packet count, the robot starts and stops as expected, incrementing packet counters as expected. This works fine even after changing mode or deploying projects - so long as you haven't run by UDP before since boot.

The only way to get it working again seems to be rebooting the controller, which resets the received packet count to zero.

Checking the packets with wireshark I can see that I am sending the correct incremented counter value (n, for example), exactly as I am when it is working. The robot is replying to each packet with an error -3 (Incorrect data packet counter) with a 'Data Packet Counter' value at (n-1).

Has anyone else encountered this?

Without any examples as to when, or why you want to end your run() method, it's difficult to determine exactly what functionality you want.

When running in T1 mode, the application (okay actually only the movements, any logic code will carry on) will stop whenever you take your finger off the play button. The stop button will do as you require and stop the application running when in Auto. It is not accessible to the programmer by any means I know of, with the exception of the .net services which can be used to make plugins (I haven't used these on sunrise but expect they look to be similar to what is on a KRC4).

A simple

return;

would end your loop and method. If you want to stop the program mid movement by some logic you would need to use conditions via the .breakWhen(ICondition condition) method of a motion object. The manual makes these quite clear.

You're correct in that there is currently no way to automatically display a user key bar.

I've cracked it. The robot only opens the socket on port 30300 while in AUT mode. If you're in teach and try sending a Get_State request it won't be received.

Thanks greengrape83, that's the correct range of available ports for using in a robot application or background task. As far as I can tell that is entirely separate from the external control UDP socket. I've found the KLI configuration XML file on the sunrise which includes all of those ports, and 30300 and 30301 for ext control, to be redirected through the virtual network across the KLI. I've added an inbound firewall rule on the robot for port 303000 in case that was blocking it but it made no difference.

I'm unable to send external control UDP messages to the sunrise controller. I can receive the status messages to the IP address and port configured, when they are sent such as a change of operating mode. These messages show a zero count in the 'valid packets received by client', so I know my messages aren't getting through.

Monitoring any sent UDP controller messages to the robot in Wireshark, I get an ICMP Destination unreachable (Port Unreachable) message. I am sending to port 30300 as described in the sunrise OS manual, with the IP address configured correctly in the external control settings (as shown by receiving status messages).

Port 30300 outgoing has been allowed through my firewall on the control PC, does anything need to be done to the port on the Sunrise?

The controller is running Sunrise OS1.11.

The IO Pneumatic media flange has no control of the pneumatic outlets, they are plumbed direct through to the base of the robot. There is an IO Valve Pneumatic media flange, which has two 3/2 valves and a direct feed.

I recall facing a similar problem, and scratched my head for a while as to why the robot was moving in a completely different direction than I planned.

You are both right - sort of. The complication arises because of the parent/child relationship of frames. In regular KRL, you define your base, you define your tool, and you have a frame (POS or E6Pos) that specifies the spatial relationship between the two. In sunrise you aren't limited/protected by such simplifications, as I'm sure you know you can have many nested frames, for bases and tools, with all of them effectively being objects of type 'Frame' or 'ObjectFrame' if you need to control them. The resulting overall transformation relative to the robroot (world, if you like) is determined by applying each transformation from the top down.

For simple cases, you are able to manipulate the individual xyzabc values and achieve the effect you are after. When you have nested points (which can be very useful when moves are relative to a fixed point so only one point needs to be touched up, or one point added to complete a process in a new location) when you call Frame.getBetaRad() for example you are only getting the Beta for that frame - which doesn't include all of the transformations which have taken place in the frames above it in the tree.

Fortunately there is a clean and safe alternative, which allows exactly what you are wanting. That is the transform() method of the ObjectFrame class. Now this allows you to transform not just in world, but in any frame orientation you define. Unfortunately, this means a simple 'world' transformation requires a little extra code.

Transformation offset = Transformation.ofDeg(0, 15, 0, 0, 0, 0);
Frame nullframe = getApplicationData().getFrame("/Nullframe").copy();
Frame newPosition = getApplicationData().getFrame("/ExampleBase/NestedPoint/TaughtFrame").copyWithRedundancy().transform(nullframe, offset);

I haven't found a way of initialising a new Frame object which works, to get around this I have created a 'Nullframe' base at the root of the frame tree. In practice having this has been helpful for other things too, like if you want to store points just in the world base without making a mess of the tree.

From the title it looks like you are using impedance mode, with a low/zero stiffness. You're better off using the dedicated mode handGuiding(), as this includes the functionality you are after, the stiffness of each axis ramps up near to the soft limit, which means the limits are then obvious to a user and cannot be exceeded (without excessive force which should probably trigger an ESM anyway).

The activation of this mode is different depending on which Sunrise OS you have, on the more recent ones you'll need to have the HRC (Human Robot Collaboration) installed, and imported into your application, then call e.g.

Quote

robot.move(handGuiding());

There's quite a long thread on the forum here where various people try and explain how to get it operating, it is in the Sunrise OS System Integrator manual.

The impedance control mode isn't really designed for HRC, at least not for the user to take the robot and move it somewhere new - it's more to allow the robot to be guided slightly flexibly, or to be compliant to other moving/docking things around the cell.

I was faced with a similar problem recently. Kuka Support Areas in Germany eventually were able to modify my PID to include a kinematically linked external axis in the positionally accurate model. The robot was new, had not been installed, and was purchased with a motor for external axis - so Kuka may not be as forthcoming for an older robot.

Unless the machining feed rate is critical, or you need the track kinematically linked for safe operation or some other reason, I would use the track unlinked. Unless you got a PID that included the characteristics of your particular track, which would require laser calibration, the track would be treated as ideal by the positionally accurate model anyway. Which would have the same level of accuracy as a positionally accurate robot not linked to the track.

I'd be inclined to avoid machining a full reach from one E1 position, then moving along and doing another full reach. Without knowing the nature of your application, I'd expect any inaccuracies with continuous E1 movement would be subtle and probably not noticeable. Taking discrete positions along E1 could leave you with steps between sections.

You need to use dependency injection, keyword "@Inject".

This also means you don't have to instantiate the IO groups with the new constructor method.

Try this:

class stuff not listed
///
@Inject   
MediaFlangeIOGroup IOInPort;
@Inject
OmronGXIOGroup I_Anal;




IOInPort.setOutput1(true); //Should now work
long Data =I_Anal.getA_in_1(); //should now Work

You'll probably also need to import the library for javax.inject

I've had only limited success using IO configured not as bools, if it works in the pendant then that's a good sign.
Why they haven't put any error handling on this I don't know - I expect it's a fairly common mistake.

Thanks to various threads in this forum, I have handguiding working. This is without the touch media flange, using a safe input as handguide enable switch.

I would like to use handguide mode to teach positions, or ideally to teach a path. I can't see any method to save a position so that it could be used in a different application. I could use dialogues to control the capture of position data, but the getApplicationData() only contains get accessors for frames. Is there some other available method to touch up/save frames, or is there an alternative means of data storage?

Kuka made a nice video showing teaching by handguiding, but I can't find anything about it in the documentation.

Thank you panic mode and kr16_2 for confirming that it should work. I tried using the same program versions and the same steps but on a different laptop and it worked just fine.

A colleague with a similar laptop to mine was trying to configure profinet recently on a krc4 and WoV kept crashing just like my laptop, so I think it may be a hardware problem with our laptops.

Sorry tjacks12, I think your problem sounds quite different to what I was experiencing, it might be worth starting a new thread if you haven't got it solved.

I'm having some trouble getting profinet working on an IIWA. Really I seem to have two problems:
1: Using the most current WorkVisual provided by Kuka 4.0.17 and described as being compatible in the Sunrise OS v1.11 documentation. If I create a new sunrise project, open up the IOConfiguration in workvisual, and add a profinet interface to the controller, as soon as I try and configure that interface by double clicking, or right clicking and selecting settings, WorkVisual Immediately crashes. I've tried several fresh WorkVisual installs, including deleting the c:/ProgramData Kuka files which contain the option installations (such as the sunrise export utility).

WorkVisual 4.0.17 (and any version I have after 4.0.6) crashes when trying to configure profinet in any project, not just sunrise ones. Does anyone else's version do this? I've done some searching and found nothing. I've tried copying the DTMs from a working version among other things but no joy.

2: Using the most recent WorkVisual that allows me to configure profinet (this is on a different laptop) with v 4.0.6, but still sunrise v1.11 and the WorkVisual sunrise export utility that came with it. When I synchronise this project to the sunrise controller, when it reboots the red bar at the top of the pendant remains on. The safety has error "Safety Control Startup Failed". The fieldbus window does not indicate any fieldbus issues. This suggests to me that the profinet bus isn't even starting. I have installed the profinet option package to the sunrise controller, through the StationSetup.cat.

Has anyone managed to commission a sunrise controller with profinet? I don't even mind if the safety is still over X11, I just need the IO by profinet. The safety over profisafe would be cleaner if I can get it, I expect once profinet works at all the safety will be straightforward.

I'd be most grateful for any solutions, or even suggestions of something else to try.