-
Notifications
You must be signed in to change notification settings - Fork 0
1. Read me first
The E-STOP buttons on the KCP is a local ESTOP. It will only stop the robot that it is connected to.
Before starting the robot, make sure the fenced area is clear of all obstacles. Make sure the overhead crane is not parked over the fenced area. Carry out a visual inspection of the robots.
The robot should be parked in a position where the overhead crane can pass over the gantry arm. Remember to lock the emergency stop before leaving.
The controllers are outfitted with batteries to ensure a safe shutdown during power loss. During shutdown the controller runs off these batteries from you turn the switch until it is completely powered down. Excessive power cycling of the robots should be avoided otherwise the batteries will be depleted. Under normal operation, leave the controller on for at least 12 hours after power on. Dead batteries on power-off will result in loss of mastering/calibration. The controllers should not be powered down for more than 6 months at a time, or the batteries will be depleted due to self discharge.
We have the dial-gauge mastering tool. Stefano knows where it is. The mastering procedure is described in KUKA System Software manual. Only jogging in T1 is possible if mastering data is lost.
The mastering process sets encoder values to a predefined exact position for individual joints. The KRC keeps track of encoder ticks from this position, and uses this to calculate the actual joint position. In essence it allows the robot to calculate it's own position with regard to the robot base or external kinematic system root. ($ROBROOT or $ERSYSROOT)
Calibration is done after mastering, and is used to determine the exact position of the TCP or a work object with regard to a coordinate system. (usually $WORLD, $BASE or $TOOL)
Due to the way the robots are controlled when using RSI, they can move at full speed regardless of speed settings on the KCP. Programming errors can become expensive or deadly if you smash the robots into something or someone at full speed.
$ROBROOT and $ERSYSROOT have been set so both robots share the same WORLD frame. This also coincides with ROS root frame from robotlab_support. This is aligned along the gantry axes, <X, Y, Z> <-> <-E1, -E2, E3>. Unfortunately the direction of E1 and E2 does not coincide with X and Y.
Potential fix: Rotate $ROBROOT, $ERSYSROOT and ROS root, requires updating all workspaces and ros_rsi_hw_interface at the same time.