Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
tutorials:pycram:own_robot [2021/02/11 10:14] – jdech | tutorials:pycram:own_robot [2021/02/11 12:44] – [A robot description for your robot] jdech | ||
---|---|---|---|
Line 4: | Line 4: | ||
* A description for the robot. | * A description for the robot. | ||
* Process modules for this robot. | * Process modules for this robot. | ||
+ | |||
+ | ==== The URDF file for your robot ==== | ||
+ | To load your robot in the PyCRAM simulation environment you need a URDF representation of your robot. | ||
+ | Most manufacturers of robots provide an URDF file to the respective robot. If there is no URDF file for your robot you have to create one yourself, for this please look at the tutorials in the ROS wiki [[http:// | ||
Line 13: | Line 17: | ||
* Joint configurations, | * Joint configurations, | ||
=== Initialization === | === Initialization === | ||
- | In PyCRAM the robot description is a class which extends the RobotDescription class. The attributes to initialize are moistly self explanatory. | + | In PyCRAM the robot description is a class which extends the RobotDescription class. The attributes to initialize |
+ | * Name is the general name of the robot | ||
+ | * base_frame is the origin of the URDF while base_link is the base link in the URDf | ||
+ | * torso_link and torso_joint are the names of the torso joint and link, if there are any | ||
+ | * ik_joints means all non-fixed joints this is used for ik resolution and has to be given. | ||
+ | * Optionally an odom frame and the corresponding joints can also be specified. | ||
+ | This then looks like this: | ||
< | < | ||
Line 21: | Line 31: | ||
" | " | ||
| | ||
+ | This example is the robot description for the boxy robot of the Institute for Artificial Intelligence. | ||
+ | |||
=== Joint Chains === | === Joint Chains === | ||
Now the joint chains can be added, to add a joint chain you first need to create an object of the ChainDescription class, this needs a name for this chain as well as all joints and all links in this chain. | Now the joint chains can be added, to add a joint chain you first need to create an object of the ChainDescription class, this needs a name for this chain as well as all joints and all links in this chain. | ||
Line 35: | Line 47: | ||
=== Cameras === | === Cameras === | ||
- | In addition to the joint chains the camera or cameras if there are more than one can also be specified in the robot description. | + | In addition to the joint chains the camera or cameras if there are more than one, can also be specified in the robot description. |
- | This is, like the chain description, | + | This is, similar to the chain description, |
- | < | + | * the link name of the camera in the URDF |
- | maximal_height = 1.60 | + | * horizontal -and vertical angle |
- | | + | * minimal -and maximal height. |
- | vertical_angle = 0.75049 | + | The heights as well as the angles are optional arguments and don't have to be given. |
- | kinect = CameraDescription("head_mount_kinect_rgb_optical_frame", | + | An example on how to do this can be seen below. |
- | horizontal_angle=horizontal_angle, | + | < |
- | minimal_height=minimal_height, | + | minimal_height=0.0, maximal_height=2.5, |
+ | | ||
+ | self.add_camera("camera", | ||
| | ||
=== Additional Info === | === Additional Info === | ||
- | For more examples or a full implementation of a robot description please referee to the already implemented descriptions [[https:// | + | For more examples or a full implementation of a robot description please referee to the already implemented descriptions [[https:// |
| | ||
==== Process Modules for your robot ==== | ==== Process Modules for your robot ==== | ||
Line 73: | Line 87: | ||
This is just an example on how the code could look like for an robot in the simulation environment, | This is just an example on how the code could look like for an robot in the simulation environment, | ||
+ | |||
+ | === Registration === | ||
+ | For PyCRAM to be able to choose the right process modules the process modules has to be registered. The registration basically tells PyCRAM which process modules are available and for which kind of designator they are intended. If a desiginator is performed PyCRAM then queries this registration to choose the right process module for this designator. | ||
+ | |||
+ | To register your implemented process modules to PyCRAM you need to create a new class which extends the PyCRAM ProcessModules class, don't confuse this with the ProcessModule class which is for implementing the process modules. | ||
+ | |||
+ | The constructor of this class takes the objects of the process modules as arguments, the rest of choosing the right process modules is done by PyCRAM in the background. The constructor takes the process modules in the following order: | ||
+ | * navigation | ||
+ | * pick_up | ||
+ | * place | ||
+ | * accessing | ||
+ | * park_arms | ||
+ | * move_head | ||
+ | * opening_gripper | ||
+ | * closing_gripper | ||
+ | * detecting | ||
+ | * move_tcp | ||
+ | * move_joints | ||
+ | * world_state_detecting | ||
+ | At the moment the process modules have to be in this order, so PyCRAM can find the right process module for the respective designator. You don't have to provide all process modules and can always write None instead of the process module, but keep in mind that in this case the execution of the respective designator would fail. | ||
+ | Here is how this looks like for the boxy robot. | ||
+ | < | ||
+ | |||
+ | def __init__(self): | ||
+ | if not BoxyProcessModules.initialized: | ||
+ | super().__init__(BoxyNavigation(), | ||
+ | | ||
+ | | ||
+ | </ |