Kuka Robot

• Download Torsten's FRILibrary
• Plug in the ethernet cable from Kuka to Computer
• Turn on the Kuka Robot (0 to 1 on red dial)
• Switch key to point in the 7 o'clock position
• Increase speed to 100% (upper right)
• Run validate_load_data
• Press button on back to make I turn green
• While holding back button, press green clockwise button
• If not working, hit acknowledge all in bottom window (otherwise, nothing can start)
• Hold both buttons until it hits correct position (candle)
• Repeat until it goes to side position
• Repeat until it goes back to candle
• Program > Cancel Program
• run fricontrol
• switch key to 11 o'clock position
• Press the 1 button to turn it on
• Press green button (clockwise) twice (should say FRI successfully opened)
• Run FRILibrary/Linux/x64/release/bin/FastResearchInterfaceTest
• q to quit and turn off kuka
• Restart if you get "bad communication error"

Incomplete Class Map of Dynamics3d:

Chai Classes - Quick Definitions/Purposes (Alphabetized)

cDynamicBase: represents a robot overall

cDynamicContact: contains the visual representation of a contact point (its position, force, etc.). Also contains the link that is in contact. There are two cDynamicContacts per contact point (one for each of the two links).

cDynamicJoint: represents the joint of the robot. Joints are to the parent link. Only has one corresponding link.

cDynamicLink: represents a link of the robot. Can contain multiple joints. Contains inertia and mass information. Stores the mesh information and uses it to build collision model.

cDynContact: modified so that you can extract pairs of contacting surfaces. Each pair has a list of cDynContactPoints. However, if you contact on different objects in a multimesh, duplicate pairings will exist - the contactpoints will be different (corresponding to each of the different objects in the multimesh). For example, if multimesh A has two parts, and a single mesh B touches A in the two different parts, then pairing AB will occur twice: one with the contacts on the part of A and another with the contacts on the other part of A.

cDynContactPoint: seems to store much more information than its cDynamicContact counterpart. There is no way to go from cDynamicContact<--->cDynContactPoint easily though.

cDynObject: seems to be the underlying basic object for dynamics.

-------------------------------------------------------------------------------------------------------

SCL/Chai3d Integration Tasks

Collisions: The XML file should specify whether any given link should build no collision model, bounding box, collision hull, or triangles. (Bug: the SCLparser doesn't seem to correctly read the XML file and update what type of collision).

Prismatic/Revolute Joints: Functional. The position, velocity, acceleration, and torque (Q, dQ, ddQ, and Tau) are all represented as doubles. First, the integrator passes the values from SCL (Tau passes the torque given by controllers) to Chai3d. Then it calls on the chai3d world to update the simulation and passes back the values to SCL, which will then update the graphical representation.

In Progress: Spherical Joints. Collisions on non-fileobj meshes.

• My version of SCL keeps many extra vectors to store Q, dQ, ddQ. Controllers are not yet implemented.
• Collisions, as of now, only are of type collision hull. Must implement bounding box and triangles
• However, Chai makes it so that every link, not mesh, specifies collisions. However, SCL wants it so that each graphical mesh can specify its own collision. Is there a way to do this?

Problems: Energy issues on multi-link robots. Collisions on multi-link robots. Have collision type specified by the mesh and not the entire link.

Potential Issues: Potential problem could occur if there are multiple robots - for every N robots, on each timestep, the dynamics update will happen N times rather than once.

Efficiency ToDos (maybe): Right now two different collision models are created for the graphics and dynamics. Could be combined?

-------------------------------------------------------------------------------------------------------

SCL/Chai3d Integration Notes

Basically there are two major stages: the creation of the nodes/model (C3dRepCreator) and the integration (C3dDynamics) itself.

C3dRepCreator - creates the SCL model within Chai

• Creates a chai world and a dynamic world that will be used by the dynamic engine.
• Creates a cDynamicBase (robot container) at position specified by the root.
• From SCL, iterates over the links and joints, building a similar tree-like structure in chai.
• At each link, we must set the local position/rotation of the frame. Also mass properties (mass, center of mass, inertia) must be set in chai.
• Makes sure that the link structure is preserved. Every parent-child link relationship is important.
• For joints, we read the type from SCL and create that specific type of joint for its respective link. Joints for a link specify the degree(s) of freedom of that link inside its parent link.
• Furthermore, if needed, collision models are also created within the links. Collision models are read from the XML/OBJ/3DS files and are based on graphic meshes.

C3dDynamics - update on each timestep

• Init
  • Calls the RepCreator to make the robot to use for chai's dynamics calculations.
  • Manually calculates the dof of the robot (adds 1 for each prismatic/revolute and 3 for spherical joint)
• Integration
  • Grabs the Q and dQ from SCL and updates it in chai. Makes Chai's Tau equal to the controller's (make sure that Tau is part of the actuators rather than the sensors).
  • Zeroes out the ddQ - no external force.
  • We can now update the dynamics in chai, moving it one timestep forward. SCL specifies this timestep.
  • Now we move Q, dQ, ddQ, and Tau back into SCL (make sure that the Tau is part of the sensors rather than the actuators)
  • This now allows SCL to have an updated Q and dQ of each link, which is what it needs to determine the state of the world (for graphics).
• Potential energy and Kinetic energy
  • Determined by simply calling the respective function in Chai on the entire robot (cDynamicBase).
• Given a link name, can find that link; link names are assigned in the RepCreator.
• Also has methods (consistency_check) to ensure that the RepCreator made the model within Chai that matches with SCL.