Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
tutorials:pycram:own_robot [2021/02/11 11:54] – [A robot description for your robot] jdech | tutorials:pycram:own_robot [2021/02/11 12:44] (current) – jdech | ||
---|---|---|---|
Line 17: | 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 | + | * 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 | + | * 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 | + | * 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. | + | * 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. | * Optionally an odom frame and the corresponding joints can also be specified. | ||
This then looks like this: | This then looks like this: | ||
Line 87: | 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(), | ||
+ | | ||
+ | | ||
+ | </ |