Posts by RoboticsMan

"How does your current algorithm pick one currently?"

We find an initial solution with an analytical solver. We have limited the solution space by not allowing the robot to flip wrist, elbow etc (joint limits are automatically generated in our software when the DH parameters are determined). This means that there generally only is one solution (except for the cases where A6 can be turned 360 degrees and still be within joint limits. In that case we have an algorithm for which solution to choose).

In our new software, we would like to avoid limiting the joints like that, we want to be able to use the robot it its entire working range.

Quote from SkyeFire

A few years ago, I cam across an open-source SciLab library for building DH models and doing inverse and forward kinematics. Didn't get time to play with it much.

The main issue here is that you're going to have to build DH models for every variety of arm design (look at the wrist of a Fanuc R-2000 vs the wrist of a UR-10, for example). And then parameterize those models for every variation that falls under the differnt DH model.

Hi,

We already developed code that can determine DH models and do forward and inverse kinematics. It works fine for both Fanuc and UR robots. The problem is just that we want to be able to derive ALL of the solutions for a given target coordinate, and our algorithms are not able to do that.

/RoboticsMan

Hi,

Thanks for the answer.

We are coding in C++, so the library would have to be in C++, or we would have to make a C++ wrapper.

With regards to how many types of robots - well... ideally all 6-axis robots?

And we already did make a solver (both analytical and numerical plus an algorithm for deducing the DH parameters from a physical robot) ourselves, and it works well with more or less any 6-axis robot (any KUKA, FANUC, ABB, UR etc), but it has some limitations that we would like to avoid in the new project - and it would be nice not to have to have to maintain a solver library ourselves going forward. We have switched to ROS and MOVEIT, but so far we are less than impressed, and are looking at what other options there are.

/RoboticsMan

Hi,

I have noticed that in RoboDK, one can see a list of all of the possible configurations of the robot for the current pose.

Do any of you know a software library that can generate a list of all of the inverse kinematics solutions like that? Finding one inverse kinematics solution is not a problem, but I want to be sure that I have all of the solutions, so that I can choose the one that fits the use case best. The library should work with both robots with spherical wrists (e.g. KUKA), but also robots like UR. So far we have used different solvers from ROS, but none of them give us all solutions, only one solution.

Ideally we would like to use the solvers that RoboDK uses, but I suspect that they are not willing to let people use the RoboDK solver in other products.

Thanks in advance!

/RoboticsMan

I know that a manual from the KRC1/KRC2 times is hardly up to date, but since the behavior described in the manual aligns with what I observed up until software version 8.3, I thought that it was fair to assume that the behavior would still be the same in 8.5. That it is no longer mentioned in the manual I find less important, since KUKA sometimes seems to omit some things in some manuals.

I have emailed my contact at KUKA asking whether they have change-logs, so let's see what that brings.

But anyways, I managed to solve my problem using an interrupt that is triggered by a cyclical flag that is defined like this:

$cycflag[4] = ($PRO_STATE1 == #P_ACTIVE) AND (STOP_REQUESTED == TRUE)

The STOP_REQUESTED variable is then set from the SPS.

Because we use $PRO_STATE1 (program state) in the cyclical flag, the rising edge that triggers the interrupt will never come while the program is stopped, only when it is started again. I have now implemented it and tested it multiple times, and it works!

I am pretty satisfied with that solution, unfortunately I didn't come up with it myself, one of my colleagues suggested it.

Quote from Fubini

After the resume of interrupt_handler.

Fubini

Oook? But I don't have any movements in the interrupt, so I am not sure how that will change anything. Especially since my problem is that the interrupt is triggered later than I want. But sure, I'll try it out.

Update: I tried it, didn't change anything.

Quote from panic mode

Program looks ok to me. I think the issue is with testing conditions. Do not stop program... Keep it running... do not pause to trigger the interrupt. And make sure input is off before each test.

Well, ok. But is should have worked, even if the program was paused. At least it used to in earlier versions (e.g. v8.3). I found the proof that it used to be the way I want in an old manual that you shared in another thread in this forum.

The document is :

"SOFTWARE

KR C1 / KR C2 / KR C3
Reference Guide
Release 4.1"

And in section 2.2.27.3 on page 84 it says:

"Each declared and activated interrupt can be detected once during an operator stop. After

restarting the system, the interrupts that have occurred are executed in order of their priority
(if they are enabled). The program is subsequently continued."

This is exactly the behavior I want have have observed in older versions, but don't see anymore in v8.5. So KUKA must have changed something related to that. This was why I was asking about change-logs.

I have a former colleague that now works at KUKA, so I think I'll give him a call to find out if the change in v8.5 is intended or not.

"Do not stop program... Keep it running... do not pause to trigger the interrupt."

This is unfortunately not realistic for use case we have. The user will be using the robot in T1 mode a lot of the time during setup and run in, and might release the stop button at any point.

The robot receives coordinates from a software that runs on the PC. At any point the user might decide to change the program flow on the PC and start over. When this happens, the PC sends a stop signal that tells the robot to stop the current movement and skip any other movements that have been queued up. This is handled by the SPS. The PC software will then ask the robot where it currently is, and take it from there. Unfortunately, the interrupt that is triggered by the SPS only works properly if the robot is moving when the stop signal comes. If the robot program was temporarily paused, then the interrupt handler will only be run AFTER the current movement.

Quote from Fubini

You should take care that the advance run pointer stays inside the Interrupt. This has been discussed multiple times in this forum and is a common programming error with Interrupts.

Fubini

Just to be sure, when you say "inside the Interrupt", do you mean that I should have an advance pointer stop before I disable the interrupt? Because I have that in line 38, in move_func().

Well, I cannot show you the original code, since that is part of a bigger system. So I have now boiled it down to a small example, and tested this on both robots. The test gave the same result as I mentioned earlier.

I had to redo the movements on the robot with KSS 8.3, (since it didn't understand the movements in the file from KSS 8.5) but otherwise the program is the same.

The code:

DEF interrupt_test( )
;FOLD INI;%{PE}
;FOLD BASISTECH INI
GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
INTERRUPT ON 3
BAS (#INITMOV,0 )
;ENDFOLD (BASISTECH INI)
;FOLD USER INI
;Make your modifications here
;ENDFOLD (USER INI)
;ENDFOLD (INI)

;FOLD PTP HOME Vel=100 % DEFAULT;%{PE}
WAIT SEC 0.0

; Flag used to see if interrupt has been triggered
$FLAG[10] = FALSE

; input 3 can be triggered manually
INTERRUPT DECL 10 WHEN $in[3] DO interrupt_handler()
INTERRUPT ON 10

; Wait time to make sure interrupt is ready
WAIT SEC 0.1

move_func()

INTERRUPT OFF 10
;FOLD PTP HOME Vel=100 % PDAT1;%{PE}

END


def move_func()

;FOLD PTP P1 Vel=10 % PDAT2 Tool[1]:Tcp_Tool Base[0];%{PE}
;FOLD LIN P2 Vel=0.5 m/s CPDAT1 Tool[1]:Tcp_Tool Base[0] ;%{PE}
WAIT SEC 0

end


def interrupt_handler()
BRAKE
INTERRUPT OFF 10
$FLAG[10] = TRUE
RESUME
end

Hi,

I know this is an old topic, but have a similar problem as the original poster, so I can add some details. Maybe this can help other people that may encounter it.

I have made a test where I make a linear movement between two points. Lets call them P1 and P2. Before P1 I enable an interrupt. The interrupt handler calls BRAKE, so if the interrupt is triggered between P1 and P2, the robot will not finish the movement. So far, so good.

In our office we have two KRC4 robots. A KR6 running KSS 8.3.174 and a KR10 running KSS 8.5.385

During the test I release the run button while the program is between P1 and P2 (I am running in T1 mode) so that the program stops. I then manually trigger the interrupt condition (by pushing a piston back).

The behavior is not the same on the two robots. On the one running KSS 8.3, the interrupt routine will be activated as soon as I press the run button again (this is what I want!).

On the one running KSS 8.5, the interrupt routine will be triggered at the end of the movement, so in P2 - and it doesn't matter if the interrupt signal is switched on and off several times on the way from the "stop" point to P2.

However, if I on the KSS 8.5 robot release the run button, and press it again without triggering the interrupt, and then trigger the interrupt when the program is running again, then it works as it should (robot stops immediately).

As far as I remember, the behavior on our KRC2 robots is the same as on the KSS 8.3 robot (I haven't tested this recently).

I find this difference in behavior between KSS 8.3 and 8.5 pretty weird. Does KUKA release changelogs/ release notes for the KSS software, so that one can see what the differences are between the different versions?

/RoboticsMan

Ok, thanks!

Hi,

It is possible to pass arguments when calling a TP program from a TP program. It is also possible when calling a Karel program from a TP program. But what about when calling a TP program from a Karel program?

So far I have not been able to find a way (other than doing it indirectly via registers). Maybe it is not supported?

Thanks in advance!

/ RoboticsMan

No, unfortunately there was no backup. In the end I was able to write all of the code again in about 3 days. It sucks to have to do that, but at least it was not close to a deadline.

One of my colleagues accidentally did an I-Start on a robot running on a production line at a car factory. Fortunately they were able to get it back up and running with a backup, but it is really horrible user interface design, that there isn't more of a warning when doing I-Start. I think I will contact ABB and ask them to improve this.

Hi,

Ok, I know this is a long shot. I have been working on a robot program in RobotStudio for a while now. So far everything has been done in the virtual environment. Today I wanted to do a warm-start, but must have mis-clicked and performed an I-start. When the virtual robot controller booted up again, all the files were lost. Is there any way to recover them, or do I have to start over? (that's my guess).

Im trying Windows File recovery, but I have not found anything so far.

Thanks in advance!

/RoboticsMan

Hello,

I am trying to make an analytical inverse kinematics solver for the Fanuc CRX-10iA robot. I already made such a solver for "normal" 6-axis robots with spherical wrists (spherical = axis 4-5-6 intersect in the same point), and for UR-style robots.

For robots with spherical wrist, I use the flange->wrist offset to determine the location of the center of the wrist. The A1, A2, and A3 angles can then be found using a little geometry. A4, A5 and A6 angles are found using ZYZ Euler angles.

The UR robot does not have a spherical wrist, but I know that A4 is parallel with A2 and that both A4 and A6 are perpendicular to A5. So I can find the A5-A6 intersection, calculate an initial angle to that one (first guess for A1), compensate for the A4 offset to get the correct A1 angle, then subtract the A4 offset to find the intersection between A4-A5. This point is then used for the formulas to derive the A1-A3 angles, and the A4-A5-A6 angles are derived using ZYZ Euler angles like I did for the robots with spherical wrists.

But now I want to make an analytical solver for the Fanuc CRX-10iA robot. It is in many ways like a robot with a spherical wrist, only the wrist axes do not all intersect in the same point. See attached picture. Do any of you have a good idea for how to solve this using geometry? I know that I can find a solution using the jacobian method, but I want to use the analytical solver to find a good starting guess for the jacobian solver.

Thanks in advance!

Thanks for the answers so far! I think the robot was running a pretty new version of RW. Unfortunately I no longer have access to the robot, but I will keep it in mind the next time I get my hands on a robot with the same problem.

Quote from Lemster68

That is probably an instance of the built in safety signals.

Sooo.... is there anything one can do? It works on some robots, so it is not that it only works in the simulator.

Hi!

I am trying to make a program that can read the names of the available inputs and outputs on the robot, using the "ReadCfgData" command. The names are then displayed in a list, so that the user can choose which inputs/outputs to use for what, when the robot program is set up.

This works fine when it is simulated in RobotStudio, but on some real robots it doesn't work. We recently had a case where it gave us the following error message:

"

40747: Access Error

Description

Task T_ROB1

Cannot read or write to the system parameter Attribute. The parameter is internal and protected from reading and writing.

Program ref: /SBase/GetExistingIONames/ReadCFGData/4747

Actions

Recovery: ERR_CFG_INTERNAL

"

The code for reading the signal names looks like this:

FOR nIndex FROM 1 TO nMaxSignalIndex DO
  ReadCfgData "/EIO/EIO_SIGNAL/SignalType/"+sSignalTypeString,"Name",sSignalName\ListNo:=nListIndex;
  ReadCfgData "/EIO/EIO_SIGNAL/"+sSignalName,"Device",sDeviceName;
  IF (sDeviceName<>"PANEL") AND (sDeviceName<>"DRV_1") AND (sSignalName<>"") THEN
    sSignalList{nSignalsRead}:=sSignalName;
  ELSE
    Decr nSignalsRead;
  ENDIF

  IF (nListIndex=-1) THEN
    RETURN nSignalsRead;
  ENDIF
  Incr nSignalsRead;
ENDFOR

sSignalTypeString will have one of the values "DI", "DO", "GI", "GO", "AI", "AO". In this particular case (where it failed), the value was "DO".

We have not been able to figure out what the problem is, and how to solve it. Is it a system setting that we need to change?

Any help would be greatly appreciated. Thanks in advance!

/RoboticsMan

EDIT: Added information: It fails on the first call to ReadCfgData

I found the solution. RoboDK was apparently running on the wrong graphics card. I had the same problem in another program, but there I actually got a warning saying that the headset had to be running on the same graphicscard as the main monitor. In Windows it is possible to specify on an app-per-app basis what graphicscard it should be running on. Once I did that for RoboDK, it worked fine.

/RoboticsMan

Hi

I am experimenting with Virtual Reality, I would like to be able to see our cell layouts that we made in RoboDK in my Oculus Quest 2 headset. The headset is connected to the PC via Virtual Desktop. Steam VR is running on the PC, it is working fine. I start RoboDK and tell it to connect to the headset. A window pops up on the PC, showing the view of the headset, and I can see it tracks the movements correctly. But within the headset itself, in SteamVR, it just stays at "Next: RoboDK", and I never get to see the virtual view. It doesnt matter how long I wait. Any clues what could be going on here? I have not tried Oculus Link, since that does not work with my computer for some reason. But Virtual Desktop seems to be working fine for other applications, so I assumed it would be here, too.

Thanks for any suggestions in advance!

/RoboticsMan