Research "Denavit-Hartenberg" and "Forward kinematics."
Posts by SkyeFire
-
-
"We used TCP/IP function to sync pendant and PC". This... tells me NOTHING. What did you use?
Do you have RSI installed on your KRC4? What version?
To perform any RSI-over-TCP/IP operation, you first must choose if the robot will be a server or client. Usually, it's best to have the robot serve as a client.
You will need a sever application running (under MATLAB, I assume) on your PC. This server application will need to be clear to accept client requests every 12ms or 4ms (depending on your IPO mode), so it will need to be coded tightly and not get "hung".
The RSI directory under D:\KUKA_OPT on the robot will include an example C server program that you can use as a template.RSI operates very simply over TCP/IP, but very quickly. It's a simple port-open, send/receive handshake operation. The data needs to be formatted in XML schema, but the sample program shows how to do this.
-
I've never tried superposing RSI atop a PTP motion. Have you tried it with a LIN motion?
Please post your KRL code containing the RSI configuration and activation/deactivation logic.
You still aren't providing any details of HOW it "doesn't work" -- does it move but ignore the RSI inputs? Does it fail to move at all? Does it generate any error messages? What do the RSIMon traces look like?
In general RSI should work like:
-
It seems indeed as if some software function or configuration blocks teaching while the safety gate is open no matter in what mode. But it might be a good idea to measure everything as well, in case I can't find something like that.Well, there's no software configuration that can influence the X11 safety signals -- they're pure hardware (the ESC board has some firmware on it, but that's ironclad from the factory).
It's possible that your safety-gate wiring is actually breaking that "silent failure in T1" signal I mentioned. Unlikely, but not impossible.Nothing obvious is occurring to me... in the file PROGRESS.INI, what is the value of KUNDEN_VERSION set to? (shot in the dark, here)
-
Yes, a "fail safe" signal configuration -- aka, "block if false" -- is generally the best way to do this.
Usually we use some sort of combinatorial logic to avoid any Catch-22s or deadlocks as you describe -- for example, the Robot 1 receives a Clear if Robot 2 is sending the Clear signal, or the Home signal (Home position, by definition, should be clear of EVERYTHING).
I like using the Workspace signals for my final "safety net" between the robots, simply b/c that provides one last safety against someone jogging the robot into the collision zone and then forcing the Clear signal on (or achieving the same effect by jumping around between lines in the program. Sometimes there just aren't enough Workspaces, though -- I once had one project where the "geniuses" in charge of defining the line process created something that ended up requiring 21 separate interference zones to completely avoid deadlocking.
As a general rule of thumb, interference zones should be kept as small as possible, and robot dwell times inside them should be minimized. Whenever practical, it's better to program longer, slower routes around potential interference zones and avoid collision risk entirely. If a real risk of getting "stuck" at an interference zone boundary cannot be avoided, then the decision logic at the zone entry should include an option branch to back away and return the robot safely home. But that's largely a procedural thing -- a well-designed line should include options for "emptying" the system such that no robot is left hanging/waiting, or holding onto parts.
-
Without $advance=1..5 declared no aproximation will happen?
If I understood well from manual.And noone said if aproximation parameter affect in any way robot accuracy of positioning.
$ADVANCE controls how many motion steps the system can "look ahead." With a value of 0, it's impossible to look ahead and, as such, no approximation is possible.
Approximation will only effect the accuracy of positions that have approximated motion -- C_PTP, C_DIS, etc. Motions that have no approximation on their motion will be entirely unaffected by the $APO values.
-
That link goes nowhere.
You aren't looking for synchronization, you're looking for collision zone logic. Which is used daily across millions of robots throughout industry. Basically, each robot asserts a signal that it is "clear" of the potential collision zone, and waits for that signal from the other robot before entering the zone. Usually includes "safety net" logic where both robots halt if at any time both "clear" signals are false. Edge timing can be a bit tricky, but this is essentially a solved problem in industry.
-
If you are confused about RSI/XML setup, how did you create the client/server test program? What Tech Package is that using?
When you say "control from MATLAB," are you referring to using the KUKA Control Toolkit? That is well-documented and comes with all the setup files, IIRC.
What, specifically, is your issue?
-
Before anything else, what bus system are you using? The KRC can work with nearly any type of I/O device, but any instructions we can offer on how depend entirely on your bus configuration, due to the number of available options.
Beyond that... RSI? You're going to have to guarantee that your sensor updates at 12ms or faster, including all conversion and bus lags.
-
Did you read READ FIRST topic?
KRC model?
KSS version?
RSI version?You say "does not work," but provide no details.
"works if I use MOVECORR in free space but does not work if I use a PTP command." What does this mean? Are you contrasting sensor-guided motion with superposed motion?
-
... as long as the target position of a ptp is not teached cartesian inside a singularity.But in that case, I would expect to see the entire wrist flip over, and A4&A6 both to rotate 180deg in opposite directions. This sounds like A6 is rotating 360deg, by itself.
Hm... what is the relationship between A6 at the starting position, the final position, and your SOFTx_END[6] values? If your calculated FRAME variable would drive A6 past a limit going the "short" way, then the motion planner might go the long way around, which would force A6 to rotate ~360deg while leaving A4 and A5 untouched.
Is there any chance A6 has been set to Endless mode, rather than Rotational?
-
The LPDN errors need to be resolved in your DNSC config files. You need to remove any slaves that are not physically present from the scan list for that channel. Also, any channels you are not using should also be disabled entirely -- errors on CH1 will not affect CH2-6, but will produce errors that may confuse any troubleshooting efforts.
The "switched" and "un-switched" power lines are part of the standard, but making them work that way depends on how they are wired at the power source. If both +24VDC lines in the cable are wired directly into the power supply with no switching relays, or if only the "un-switched" line is wired, you should not need to do anything else. I was imprecise before -- the slaves do not (normally) choose which power line to use, they simply draw all power from the un-switched line, and making them "safe" requires the integrator to wire in switching relays at the power source (and sometimes some creative breakout wiring at the remote end).
-
Well, let's back up a bit.
1. When you switch to T1, what status/error messages remain on the pendant after you press Ack-All?
2. In T1 mode, when you squeeze the deadman switch, do the motors come on?
3. If you open the cabinet, and squeeze the deadman, you should see/here a small relay (or 2) on the safety board cycle. Does it?If everything passes those tests.... I once had a very tricky issue on a KRC2 years ago that had similar symptoms. It turned out that my X11 jumper plug had one safety signal (of a linked pair) mis-wired. And mis-wiring this one signal would block the robot from operating in Teach mode, but with no error messages, and would allow operation in Auto mode. Bizarre. It eventually took me going through the entire X11 plug pin-by-pin with a continuity tester to track it down.
(if the other signal of that pair was broken, it would produce an error message in Teach. Go figure)All of the safety signals are pure hardware. However, (just to confuse people), there are a few "soft" signals that have the same name as some of those hardware signals, and produce the same error messages. Motion Enable is the one that trips people up most often. These soft signals are part of the Auto-External configuration, and generally you will need to set the "soft" Motion Enable to Input 1025 (a special "always True" system input) in order to operate the robot without any external I/O. I emphasize that these "soft" signals are NOT safety-rated, despite having duplicate names with some of the "hard" safety signals.
Now, as to jogging with the gates open in T2, that generally depends on the external safety logic. Given the inherent risks of T2, I've often seen safety logic on the far end of the X11 cable which would require the gates be closed before allowing T2. But when using a "bypass" X11 plug, I don't think much distinction is made between T1 and T2.
-
The DEF_* parameters are only set by, IIRC, BAS(#INIT). If you set the $APO values during your SRC program, those values will become active and be retained until the next SRC command that changes them -- either your command, or a call to BAS(#INIT).
-
Simplest approach is to open the inline-form fold and look at the raw KRL code contained inside it.
-
Generally, DeviceNet I/O modules receive power on two different cables. The 5-pin Communication cable consists of +24VDC, 0VDC, CAN+, CAN-, and Shield/Ground. Power for Inputs is usually derived from this cable. Power for outputs is carried on pins of the "Aux Power" cable. Generally, one of these power lines is "unswitched" --that is, 24VDC is always present-- and the other is "switched" -- usually tied into a safety circuit, in order to safely disable dangerous motions when (for example) the safety gates are open.
The standard is flexible, though -- I've seen at least one brand of DN units that, for some bizarre reason, drew their communications power from the Unswitched line on the Aux cable.
The DN bus will not operate unless the bus has zero errors. If your pendant is displaying errors for the DN bus driver, none of the I/O will work. Forcing signals using Simulation mode is purely internal to the robot -- it "cheats" and ignores any bus hardware errors.
So, before anything else, it is necessary to resolve any errors being reported by the DN bus driver.
-
1: Not directly. It is possible to open files, read/write them, rename them, and delete them, so it should be possible to to "copy" or "move" a file from one location to another using roundabout means. But even then, most of the C drive is deliberately protected from the KRL file commands.
2: the math involved here is very non-trivial -- on the surface, it looks like a simple least-squares-fit, but making it work properly with "noisy" data and still give a decent result rather than a divide-by-zero error is not simple. A lot of the basic underlying math (VERY basic) is available in the KUKA_WEG module, which you may still find buried somewhere in the KRC, or can find copies on here on the forum.
-
I honestly don't understand what you mean by "can't see the motor from the controller." That makes no sense. Either it's connected, or it's not. KSS version has nothing to do with it.
Start with this: https://www.robot-forum.com/robotforum/man…84203/#msg84203
I've never done external kinematics on a VKRC, so there may be some Volkswagen-specific elements, at least at the menu/password level, that you will need to figure out.
You will need to locate the data plate for the motor first, and use that to find the matching motor DTM catalog element to import it. Then you will need to calibrate $RAT_MOT_AX for the axis. After that, you will need to work out the kinematic relationship, as shown in the manual. When performed properly, you should be able to jog the E1 axis while the robot holds the TCP at a fixed point in space, "perfectly" counteracting each motion of the E1 axis.
-
Did you read the READ FIRST topic?
Controller version?
KSS version?
Kinematic integration or not?
KUKA-made linear axis, or 3rd-party axis with a KUKA motor on it?
Did the robot come with this external axis, or is your company integrating it? -
The correct configuration of your inputs and outputs is entirely dependent on your hardware and fieldbus configuration. Without that information, it is impossible to make any useful suggestions.
It sounds as if this ISRA system is already set up for your parts. Who configured this system? Why didn't they set it up to your specification, or provide documentation providing these details?