Hi.
Did you solved your problem?
I have the same issue right now...
Regards,
tammoj
Hi.
Did you solved your problem?
I have the same issue right now...
Regards,
tammoj
Hi.
I'm trying to use the hand guiding within a RobotApplication of an iiwa 7 R800. My code looks as following:
...
import static com.kuka.roboticsAPI.motionModel.HRCMotions.*;
public class HandGuidedScanning extends RoboticsAPIApplication{
...
public void run() {
robot.setESMState("1"); // ESM1 = stop (path-maintaining) if hand guiding is active
robot.move(ptp(homePos).setJointVelocityRel(Config.VELOCITY_NORMAL_JOINT));
robot.setESMState("2"); // ESM2 = stop (path-maintaining) if hand guiding is inactive
logger.info("Ready for hand guiding...");
robot.move(handGuiding());
logger.info("Hand guiding finished!");
robot.setESMState("1"); // ESM1 = stop (path-maintaining) if hand guiding is active
robot.move(ptp(homePos).setJointVelocityRel(Config.VELOCITY_SLOW_JOINT));
}
}
Display More
When I run this application the robot moves to the home position and on the smartPad "Ready for hand guiding..." is printed as expected.
But in the manual is written that the robot should not be fall in pause mode after handGuiding() is called. But this is what happens. Moreover the whole app is crashed because I cannot restart the app nor any other app. Only a restart of the whole robot works.
What I'm doing wrong?
Thanks for any reply,
tammoj
Hi NullReference again.
I forgot to answer your advise:
QuoteIf you want to know more about the kinematic redundancy of the iiwa robots then check the systems integrator manual, it covers this concept fairly well.
If you mean with "systems integrator manual" the "KUKA Sunrise.OS and KUKA Sunrise.Workbench" manual* I did read the section over redundany more than twice. It only explains Status, Turn and Singularities but not how to handle the usage of the redundancy (joint J3) others than taught frames (which I'm not interested in).
The only hint that the iiwa will not take the redundancy in account for programmatically calculated frames is written at page 320:
Quote
The following applies for all motions:
- The redundancy angle of the end frame is taken into account when the robot that was used when teaching the frame also executes the motion command. In particular, the robot name defined in the station configuration must match the device specified in the frame properties.
- If the robot do not match or if calculated frames are used, the redundancy angle given at the start of motion by the axis configuration is retained.
But does this mean the IK will never use the jonit J3 for its calculations and there is no way to use the redundancy programmatically? If I understand the lines above right, the IK knows the current positions of J3 to calculate all other positions (J1, J2 and J4 - J7) but will not calculate any positions for J3 and there will never make use of the redundancy itself.
This can't be true than otherwise it would depend on the previous position of J3 if the iiwa could reach a frame or not.
So I'm still hoping for an answer for my initial question.
Hi NullReference.
Thanks for the fast reply. I'm not meaning the method robot.getInverseKinematicFromFrame[AndRedundancy](frame).
What I mean are BasicMotions* (like ptp, linRel, ...) in general. So if I call e.g.
the IK will only calculate values for the joints J1, J2 and J4 - J7 but not for J3. The redundancy joint J3 will just stay unchanged, which means the position will be the same as it was before.
Sometimes this leads to a "Software Axis Limit Violation", which is absolute reasonable for me because one of the joints J1, J2 or J4 - J7 hits its axis limits (see status quo example above).
Immediately after the "Software Axis Limit Violation" occurs I take a look at the smartPad/smartHMI. I manually play around (i.e. changing) only the position for J3 (while leaving all other joints as they are) so that the joint which caused the problem is not anymore close to its limit. By doing so the initial unreachable frame becomes reachable and I can continue the program without any problems.
In the end this means the iiwa is capable to move to this specific frame with the use of the redundancy joint J3.
My question is why the iiwa is not using this joint J3 by default and how to enable "robot.move(ptp(frame))" to take also the joint J3 in account.
Hope I could clarify my intention.
*com.kuka.roboticsAPI.motionModel.BasicMotions
Hi.
I'm using a LBR iiwa 7 which owns a redundancy axis J3.
My question is if it is possible that the IK (inverse kinematic) takes this redundant axis in account?
If not I would like to know how to deal with it programmatically.
Status quo:
At the moment only the joints J1, J2 and J4 - J7 are used from the IK. J3 remains unaffected. This causes a "Software Axis Limit Violation" for quite a lot frames which I expected should be easy to reach because other surrounding frames are no problem at all.
By inspecting the current joint positions for this problematic frame I see that at least one joint hits its axis limit.
The thing is if I adjust J3 manually (which obviously implicates that other joint positions are changing as well) I can find easily an angle for J3 so that all joints are far enough from theirs limits. And of course now the desired frame gets reachable when the program continues.
In summary I am looking for a way to enable the automatically usage of the redundancy or at least make this adjustment programmatically.
Any suggestions?
Hi razzo.
Sending the message from the background task over udp to another device (i.e. my laptop) is what I'm already doing. But this not what I'm looking for because I need to print/forward the message on/to the SmartHMI.
What do you mean with:
Quoteyou can connect to the controller to read it.
Is this a possibility to do so?
Greetings,
Tammo
Hi.
I'm working with a LBR iiwa 7 together with the roboticsAPI 1.15.1.7.
Since a long time I'm searching for a possibility to use the ITaskLogger within a background task.
Does someone know how to use it?
Cheers,
Tammo
After talking with the KUKA support I figured out a suitable solution to work cooperatively within a team.
Here is our setup:
We setup a external (i.e. normal) GIT repo - called teamRepo.
That teamRepo is selected as the workspace directory for the Sunrise Workbench.
We imported the existing project SunriseProject from the KUKA Cabinet - called kukaRepo.
So the structure looks like:
Workspace/.git <-- teamRepo
Workspace/.gitignore
Workspace/.metadata
Workspace/SunriseProjekt
Workspace/SunriseProjekt/.git <-- kukaRepo (only used internally from Sunrise Workbench to perform a synchronization)
Workspace/SunriseProjekt/bin
Workspace/SunriseProjekt/src
Workspace/SunriseProjekt/…
Within the teamRepo's .gitignore (i.e. Workspace/.gitignore) we added:
SunriseProject/.git*
# using "SunriseProject/bin/**/*" to override a potential "!bin/" within SunriseProject's .gitignore
SunriseProject/bin/**/*
Be ensure that:
Never perform any git-actions within the kukaRepo!
The kukaRepo may not be recognized as a git submodule of the teamRepo! For that temporally rename the SunriseProject/.git directory before you preform the first commit in the teamRepo.
(see also https://stackoverflow.com/questions/2317…hout-submodules)
Every teammate's laptop has a Sunrise Workbench installation.
Each laptop is connected via a LAN/switch to the iiwa (aka Sunrise Cabinet) to synchronize. (*)
The teamRepo keeps track of all source files within the SunriseProject so you can use git-pull,- push and -merge cooperatively.
(*) To establish a direct connection from your laptop to the Sunrise Cabinet a LAN connection (via a switch) is necessary. The kukaRepo on your laptop (Workspace/SunriseProject) is connected to the remote kukaRepo on the Sunirse Cabinet over this LAN. The LAN uses the IP range 172.31.*.*. The Sunrise Cabinet IP address is 172.32.1.147 and should not be changed. Your machine must be connected to this switch via an extra Ethernet adapter configured with a unique IP address within that range.
[hr]
Alternative you also may use a separat pc which is the only connected pc to the Sunrise Cabinet. This pc is setup up like described above.
To get your modification from you laptop to the iiwa every laptop must push to the teamRepo. At the pc pull from the teamRepo to synchronize (by using the Sunrise Workbench) to the Sunrise Cabinet.
If you do modifications on the pc (e.g. quick testing) you must push them back on the pc to the teamRepo.
[hr]
My initial question about how to modify the kukaRepo itself to fit my requirements is not recommended at all. (The KUKA support told me so!) Using a separated git repository which tracks all files (excepted git and binary files) with the kukaRepo is the only way!
Hope this will help one or the other.
Cheers,
Tammo
Hi everyone.
I'm working as a software engineer within a team with an iiwa 7 R800.
My question is about how to work cooperatively with a team on a KUKA robot.
We have to work together on the same piece of code for a research project. The only way to access the robot (i.e. push and pull our code) is to use the SunriseWorkbench - 1.11.0.7.
We know that this synchronization is done using GIT.
The problem is that the SunriseWorkbench offers no merge functionality! The synchronization (using the button "synchronize project" within the SunriseWorkbench) allows only to replace/override your local working tree with the remote (or visa verse) but not to merge commits.
So at the moment we haven't figure out to work together, which is a fundamental requirement for our project.
I already tried to realize the merge manually through a shell by performing a fetch to merge afterwards. Unfortunately the fetch fails because there isn't a remote given within the .git/config.
Just to add the "_KROS_Controller_" as a remote didn't work out. The "_KROS_Controller_" is the remote git repository within the Sunrise Cabinet/Controller.
[remote "_KROS_Controller_"]
url = http://172.31.1.147:23457/git
fetch = +refs/heads/*:refs/remotes/_KROS_Controller_/*
If I tried to fetch I got the error "fatal: Couldn't find remote ref refs/remotes/_KROS_Controller_/master".
My question is how to configure the git repository to be able to access the remote "_KROS_Controller_" from the sunrise cabinet/controller - this means to be able to fetch and merge manually.
Does anybody know a better solution to work cooperatively?
Thanks for any suggestions.