Modify the URDF file to an XACRO file, and analyze the shaking of the mechanical arm and the factors of falling to the ground

how to say! The URDF file is indeed a very important manipulator joint description file, but it is not flexible enough. We can upgrade it to an XACRO file ( in fact, it really needs to be modified to this type of file ), adding some code!

During the modification process, I will point out some of the points that need attention, and the reasons why the robot arm collapses and trembles!

We open the urdf file in the src folder as follows:

 We make a copy, and can directly modify the suffix, and modify it to robot2600_20_simulation.xacro, as shown below:

First , we double-click to open robot2600_20_simulation.xacro, and modify the beginning.

before fixing:

<robot

  name="robot2600_20">

 After modification:

<robot name="robot2600_20" xmlns:xacro="http://ros.org/wiki/xacro">

Secondly , add a virtual world coordinate, as shown in the figure below, and let it be fixed with the base_link . You must add this virtual fixed coordinate, because you want to prevent your robotic arm from flying in the sky or falling down as a whole. Of course, after you add it, the base_link will not fall down, but the robotic arm cannot be lifted temporarily! Don't worry and watch the follow-up!

<link name="world"/>


<joint name="fixed_base_joint" type="fixed">

    <parent link="world"/>

    <child link="base_link"/>

</joint>

 Then, add the transmission tag used by gazebo to each joint. ( This piece of code is very long, but it should be very easy to understand. ) You can understand that it adds a driving device to each joint simulation. There must be an actuator before it can be driven. .

  <xacro:macro name="transmission_block" params="tran_name joint_name motor_name">

    <transmission name="${tran_name}">

        <type>transmission_interface/SimpleTransmission</type>

        <joint name="${joint_name}">

            <hardwareInterface>hardware_interface/PositionJointInterface</hardwareInterface>

        </joint>

        <actuator name="$motor_name">

            <hardwareInterface>hardware_interface/PositionJointInterface</hardwareInterface>

            <mechanicalReduction>1</mechanicalReduction>

        </actuator>

    </transmission>

  </xacro:macro>


  <xacro:transmission_block tran_name="tran1" joint_name="joint1" motor_name="motor1"/>

  <xacro:transmission_block tran_name="tran2" joint_name="joint2" motor_name="motor2"/>

  <xacro:transmission_block tran_name="tran3" joint_name="joint3" motor_name="motor3"/>

  <xacro:transmission_block tran_name="tran4" joint_name="joint4" motor_name="motor4"/>

  <xacro:transmission_block tran_name="tran5" joint_name="joint5" motor_name="motor5"/>

  <xacro:transmission_block tran_name="tran6" joint_name="joint8_left" motor_name="motor6"/>

  <xacro:transmission_block tran_name="tran7" joint_name="joint8_right" motor_name="motor7"/>

Be sure to pay attention here:

<hardwareInterface>hardware_interface/PositionJointInterface</hardwareInterface>

Some friends wrote this:

<hardwareInterface>hardwareInterface/EffortJointInterface</hardwareInterface>

What is the difference between the two? The first is the position control of the joint, and the second is the torque control of the joint. If we choose the first one, then we are more concerned about the position of the joint movement of the robot arm, and ignore the torque driven by each joint. In fact, we really want to care more about the position than the trajectory, which is enough!

If you choose the first one , then congratulations, the back of your robotic arm can hardly be lifted up , hehe!

If you choose the second option , you need to care about whether the parameters in the inertia are correct. You may ask, where is the inertia?

<inertial>

      <origin

        xyz="-0.08155265 0.00029774 0.09394993"

        rpy="0 0 0" />

      <mass

        value="0.00001" />

      <inertia

        ixx="0.47864391"

        ixy="0.00366749"

        ixz="0.02583563"

        iyy="0.93676866"

        iyz="0.00048946"

        izz="1.20994094" />
</inertial>

The following two parameters need to be concerned:

First: mass parameter , this is the quality that is automatically evaluated for each link when the URD file is exported in Solidworks. If you click too fast, you may forget this. The unit is Kg. If this value is very large, such as 33.656Kg, then this joint will be very heavy, and your joint torque cannot drive this joint, then even if you add transmission and control parts, the mechanical arm will also present a kind of semi-depressed state. This is a factor that the mechanical arm cannot lift.

How to do it? Easy to handle, like me, if the request is not too big, just change it to 0.00001!

Second: inertia parameter , what is this? This is the inertia matrix, and the inaccuracy of this parameter is an important factor that causes the shaking of the robotic arm. How to modify this thing? It cannot be expanded here, and the quality assessment function in Solidworks should be used .

Note : If it is the robot arm we downloaded from the official website, each joint has been divided, and the evaluation is relatively accurate. If it is a non-standard mechanism drawn by ourselves and added, for example, I added a self-drawn one here. For mechanical grippers, the automatic evaluation is not very accurate. We need to evaluate and modify it ourselves to optimize it. This reduces jitter.


Again , add the gazebo_ros_control plug-in to connect ros and gazebo, the code is as follows:

I added a color to each Link, haha! Might look better! OCD!

  <gazebo>

    <plugin name="gazebo_ros_control" filename="libgazebo_ros_control.so">

        <robotNamespace>/robot2600_20</robotNamespace>

        <legacyModeNS>true</legacyModeNS>

    </plugin>

  </gazebo>



  <gazebo reference="base_link">

    <material>Gazebo/White</material>

  </gazebo>



  <gazebo reference="link1">

    <material>Gazebo/Orange</material>

  </gazebo>



  <gazebo reference="link2">

    <material>Gazebo/White</material>

  </gazebo>



  <gazebo reference="link3">

    <material>Gazebo/Orange</material>

  </gazebo>



  <gazebo reference="link4">

    <material>Gazebo/White</material>

  </gazebo>



  <gazebo reference="link5">

    <material>Gazebo/Orange</material>

  </gazebo>



  <gazebo reference="link6">

    <material>Gazebo/White</material>

  </gazebo>



  <gazebo reference="link7">

    <material>Gazebo/White</material>

  </gazebo>



  <gazebo reference="link8_left">

    <material>Gazebo/Orange</material>

  </gazebo>



  <gazebo reference="link8_right">

    <material>Gazebo/Orange</material>

  </gazebo>

Again : Modify the display.launch file so that it can be displayed in Rviz

  <param name="robot_description"
    command="$(find xacro)/xacro --inorder '$(find robot2600_20)/urdf/robot2600_20_simulation.xacro'" />

Again and again : Modify the gazebo.launch file

Add the following code in the header:

<param name="robot_description"
    command="$(find xacro)/xacro --inorder '$(find robot2600_20)/urdf/robot2600_20_simulation.xacro'" />

Then modify the args in the "spawn_model" node,

before fixing:

<node

    name="spawn_model"

    pkg="gazebo_ros"

    type="spawn_model"

    args="-file $(find robot2600_20)/urdf/robot2600_20.urdf -urdf -model robot2600_20"

    output="screen" />

After modification:

<node

    name="spawn_model"

    pkg="gazebo_ros"

    type="spawn_model"

    args="-urdf -model robot2600_20 -param robot_description"

    output="screen" />

Again and again : Let's run the display.launch file and the gazebo.launch file separately to see if they can be displayed normally.


 The display.launch file can of course be run! Needless to say, but the picture above is the effect after running the gazebo.launch file , and it is the effect after selecting hardware_interface/PositionJointInterface to run. If you choose the second option, and the corresponding parameters have been adjusted, the phenomenon after opening is: the mechanical arm is lifted up, but gradually sluggish , more and more sluggish, and finally fall down! Of course I didn't imply anything, hehe!

What is the solution to the gradual collapse ? It's not about the method either! Regardless of whether you choose position control or torque control, you must add the content of the following control part , just to say that after adding, for friends who choose position control for the first type, there is no visible phenomenon, but for friends who choose the second type of torque control, It will be found that the robotic arm will not gradually fall down, but will remain lifted.


Create control package

We create a function package under the src folder. You should know this step, as follows:

cd ~/catkin_ws/src
catkin_create_pkg robot2600_20_control controller_manager joint_state_controller robot_state_publisher
cd robot2600_20_control
mkdir config
mkdir launch

Again and again: We create the robot2600_20_control.yaml file under the config folder of robot2600_20_control, and the file with this suffix is ​​the parameter file. After opening the file write:

robot2600_20:
  joint_state_controller:
    type: joint_state_controller/JointStateController
    publish_rate: 50  

  joint1_position_controller:
    type: position_controllers/JointPositionController
    joint: joint1
    pid: {p: 100.0, i: 0.01, d: 10.0}
  joint2_position_controller:
    type: position_controllers/JointPositionController
    joint: joint2
    pid: {p: 100.0, i: 0.01, d: 10.0}
  joint3_position_controller:
    type: position_controllers/JointPositionController
    joint: joint3
    pid: {p: 100.0, i: 0.01, d: 10.0}
  joint4_position_controller:
    type: position_controllers/JointPositionController
    joint: joint4
    pid: {p: 100.0, i: 0.01, d: 10.0}
  joint5_position_controller:
    type: position_controllers/JointPositionController
    joint: joint5
    pid: {p: 100.0, i: 0.01, d: 10.0}
  joint8left_position_controller:
    type: position_controllers/JointPositionController
    joint: joint8_left
    pid: {p: 1, i: 0.001, d: 0.002}
  joint8right_position_controller:
    type: position_controllers/JointPositionController
    joint: joint8_right
    pid: {p: 1, i: 0.001, d: 0.002}

Don’t write the joints wrong here, especially if you choose the first Type like me, you must write position_controllers/JointPositionController correspondingly, because this corresponds to the transmission in the xacro file.

Choose the second and write effort_controllers/JointPositionController

Again and again: create a robot2600_20_control.launch file under the launch folder of robot2600_20_control, and note that the suffix is ​​the launch file. After opening write:

<launch>

  <rosparam file="$(find robot2600_20_control)/config/robot2600_20_control.yaml" command="load"/>

  <node name="controller_spawner" pkg="controller_manager" type="spawner" respawn="false"
    output="screen" ns="/robot2600_20" args="joint1_position_controller joint2_position_controller joint3_position_controller joint4_position_controller joint5_position_controller joint8left_position_controller joint8right_position_controller joint_state_controller"/>

  <node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher"
    respawn="false" output="screen">
    <remap from="/joint_states" to="/robot2600_20/joint_states" />
  </node>

</launch>

Again and again: Add the following code to the gazebo.launch file in the launch folder of robot2600_20:

<include file="$(find robot2600_20_control)/launch/robot2600_20_control.launch" />

It means that while running the gazebo.launch simulation file, run the control file.


Finally, compile it under the root directory of catkin_ws. So far, you're done!

When testing, just run roslaunch robot2600_20 gazebo.launch


One more point, for friends who choose the first position control method, they find that there is no phenomenon after adding the control file, but for friends who choose the second torque control method, they will find that your robotic arm will no longer gradually slump. For example, you can make your robotic arm sluggish half first and then run the control file separately, and you will find that your robotic arm remains at half sluggish position, which should be the effect of PID control.

Well, it's over, bye!

Guess you like

Origin blog.csdn.net/shdhckcjc/article/details/129351249