答:
This is happening for two reasons:

An "inertia" element within each "link" element must be properly specified and configured.

Maybe you don't have any proper controller for each joint. See http://wiki.ros.org/ros_control

Title: Why my robot is lying down in gazebo simulator?

Body:
this is my first post about ROS and Gazebo also I am new in ROS.
I spawn KUKA robot in Gazebo using urdf file from KUKA github repository
following answer from this question I spawned my urdf file in gazebo simulator and KUKA robot appeared in simulator but problem is that is lying down like is attached on floor for some reason.
Here is picture in Gazebo:

This is my launch file:

```<code><launch>
<!-- We resume the logic in empty_world.launch, changing only the name of the world to be launched -->
<include file="<span class="math-container">$(find gazebo_ros)/launch/empty_world.launch">
  <arg name="paused" value="false"/>
  <arg name="use_sim_time" value="true"/>
  <arg name="gui" value="true"/>
  <arg name="headless" value="false"/>
  <arg name="debug" value="false"/>
</include>
<node name="spawn_urdf" pkg="gazebo_ros" type="spawn_model" args="-file $</span>(find kuka_kr210_support)/urdf/kr210l150.urdf -urdf -z 1 -model baxter" />
</launch>
</code>```

EDIT:
I fixed base link for the world, added transmission, controllers for each axis and gazebo plugin. now my urdf file looks like this:

```<code><?xml version="1.0" ?>
<!-- =================================================================================== -->
<!-- |    This document was autogenerated by xacro from kr16_2.xacro                   | -->
<!-- |    EDITING THIS FILE BY HAND IS NOT RECOMMENDED                                 | -->
<!-- =================================================================================== -->
<!--Generates a urdf from the macro in kr16_2_macro.xacro -->
<robot name="kuka_kr16_2" xmlns:xacro="http://wiki.ros.org/xacro">
  <!-- LINKS -->

  <!-- base link -->
  <link name="base_link">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/base_link.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/base_link.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 1 (A1) -->
  <link name="link_1">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_1.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_1.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 2 -->
  <link name="link_2">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_2.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_2.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 3 -->
  <link name="link_3">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_3.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_3.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 4 -->
  <link name="link_4">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_4.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_4.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 5 -->
  <link name="link_5">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_5.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_5.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 6 -->
  <link name="link_6">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_6.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_6.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- tool 0 -->
  <!-- This frame corresponds to the $FLANGE coordinate system in KUKA KRC controllers.
  <link name="tool0"/> -->

  <!-- END LINKS -->
  <!-- JOINTS -->
  <!-- joint 1 (A1) -->
  <joint name="joint_a1" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0.675"/>
    <parent link="base_link"/>
    <child link="link_1"/>
    <axis xyz="0 0 -1"/>
    <limit effort="0" lower="-3.22885911619" upper="3.22885911619" velocity="2.72271363311"/>
  </joint>

   <transmission name="trans_joint_a1">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a1">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a1">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 2 (A2) -->
  <joint name="joint_a2" type="revolute">
    <origin rpy="0 0 0" xyz="0.26 0 0"/>
    <parent link="link_1"/>
    <child link="link_2"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.70526034059" upper="0.610865238198" velocity="2.72271363311"/>
  </joint>

   <transmission name="trans_joint_a2">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a2">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a2">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 3 (A3) -->
  <joint name="joint_a3" type="revolute">
    <origin rpy="0 0 0" xyz="0.68 0 0"/>
    <parent link="link_2"/>
    <child link="link_3"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.26892802759" upper="2.68780704807" velocity="2.72271363311"/>
  </joint>

   <transmission name="trans_joint_a3">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a3">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a3">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 4 (A4) -->
  <joint name="joint_a4" type="revolute">
    <origin rpy="0 0 0" xyz="0.67 0 -0.035"/>
    <parent link="link_3"/>
    <child link="link_4"/>
    <axis xyz="-1 0 0"/>
    <limit effort="0" lower="-6.10865238198" upper="6.10865238198" velocity="5.75958653158"/>
  </joint>

   <transmission name="trans_joint_a4">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a4">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a4">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 5 (A5) -->
  <joint name="joint_a5" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="link_4"/>
    <child link="link_5"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.26892802759" upper="2.26892802759" velocity="5.75958653158"/>
  </joint>

   <transmission name="trans_joint_a5">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a5">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a5">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 6 (A6) -->
  <joint name="joint_a6" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="link_5"/>
    <child link="link_6"/>
    <axis xyz="-1 0 0"/>
    <limit effort="0" lower="-6.10865238198" upper="6.10865238198" velocity="10.7337748998"/>
  </joint>

   <transmission name="trans_joint_a6">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a6">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a6">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- tool frame - fixed frame
  <joint name="joint_a6-tool0" type="fixed">
    <parent link="link_6"/>
    <child link="tool0"/>
    <origin rpy="0 1.57079632679 0" xyz="0.158 0 0"/>
  </joint>

   <transmission name="trans_joint_a6-tool0">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a6-tool0">
        <hardwareInterface>EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a6-tool0">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission> -->

  <!-- END JOINTS -->
  <!-- ROS base_link to KUKA $ROBROOT coordinate system transform -->
  <link name="base"/>
  <joint name="base_link-base" type="fixed">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="base_link"/>
    <child link="base"/>
  </joint>

  <!-- Gazebo world joint -->
  <!-- Used for fixing robot to Gazebo 'base_link' -->
  <link name="world"/>

  <joint name="fixed" type="fixed">
    <parent link="world"/>
    <child link="base_link"/>
  </joint>

<gazebo>
  <plugin name="gazebo_ros_control" filename="libgazebo_ros_control.so">
    <robotNamespace>/kr16_2_gazebo</robotNamespace>
  </plugin>
</gazebo>

</robot>
</code>```

This is controller yaml:

```<code># Publish all joint states -----------------------------------
joint_state_controller:
  type: joint_state_controller/JointStateController
  publish_rate: 50

# Position Controllers ---------------------------------------
joint1_position_controller:
  type: effort_controllers/JointPositionController
  #joint: base_link__link_01
  joint: joint_a1
  pid: {p: 100, i: 100, d: 500.0}
joint2_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_01__link_02
  joint: joint_a2
  pid: {p: 100.0, i: 100, d: 2000.0}
joint3_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_02__link_03
  joint: joint_a3
  pid: {p: 100.0, i: 50, d: 1000.0}
joint4_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_03__link_04
  joint: joint_a4
  pid: {p: 100.0, i: 50, d: 200.0}
joint5_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_04__link_05
  joint: joint_a5
  pid: {p: 100.0, i: 50, d: 70.0}
joint6_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_05__link_06
  joint: joint_a6
  pid: {p: 100.0, i: 50, d: 70.0}
tool0_position_controller:
  type: effort_controllers/JointPositionController
  joint: link_06__tool0
  #joint: joint1
  pid: {p: 100.0, i: 50, d: 70.0}
</code>```

and this is my launch file:

```<code><?xml version="1.0"?>
<launch>

  <arg name="paused" default="false"/>
  <arg name="gazebo_gui" default="true"/>
  <arg name="urdf_path" default="$(find kuka_kr16_support)/urdf/kr16_2_gazebo.urdf"/>

  <!-- startup simulated world -->
  <include file="<span class="math-container">$(find gazebo_ros)/launch/empty_world.launch">
    <arg name="world_name" default="worlds/empty.world"/>
    <arg name="paused" value="$</span>(arg paused)"/>
    <arg name="gui" value="$(arg gazebo_gui)"/>
  </include>

  <!-- send robot urdf to param server -->
  <param name="robot_description" textfile="$(arg urdf_path)" />

  <!-- Load controllers -->
  <rosparam ns="/kr16_2_gazebo" command="load" file="$(find kuka_kr16_moveit_gazebo)/config/joints.yaml" />

  <!-- push robot_description to factory and spawn robot in gazebo at the origin, change x,y,z arguments to spawn in a different position -->
  <node name="spawn_gazebo_model" pkg="gazebo_ros" type="spawn_model" args="-urdf -param robot_description -model robot -x 0 -y 0 -z 0"
    respawn="false" output="screen" />

  <!-- Controllers -->
  <node name="controller_spawner" pkg="controller_manager" type="spawner"
    respawn="false" output="screen" ns="/kr16_2_gazebo"
    args="--namespace=/kr16_2_gazebo
    joint_state_controller
    joint1_position_controller
    joint2_position_controller
    joint3_position_controller
    joint4_position_controller
    joint5_position_controller
    joint6_position_controller
    --timeout 60">
  </node>

</launch>
</code>```

And when I launch it in terminal this is output:

WARNING: Package name "KUKA_KR16_moveit_Luka1" does not follow the
  naming conventions. It should start with a lower case letter and only
  contain lower case letters, digits, underscores, and dashes. ...
  logging to
  /home/gazebo/.ros/log/133adcf4-5e8d-11e9-8069-000c2911adc8/roslaunch-ubuntu-3085.log
  Checking log directory for disk usage. This may take awhile. Press
  Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB.

WARNING: Package name "KUKA_KR16_moveit_Luka1" does not follow the
  naming conventions. It should start with a lower case letter and only
  contain lower case letters, digits, underscores, and dashes. started
  roslaunch server http://ubuntu:35047/

SUMMARY

PARAMETERS  * /gazebo/enable_ros_network: True  *
  /kr16_2_gazebo/joint1_position_controller/joint: joint_a1  *
  /kr16_2_gazebo/joint1_position_controller/pid/d: 500.0  *
  /kr16_2_gazebo/joint1_position_controller/pid/i: 100  *
  /kr16_2_gazebo/joint1_position_controller/pid/p: 100  *
  /kr16_2_gazebo/joint1_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint2_position_controller/joint: joint_a2  * /kr16_2_gazebo/joint2_position_controller/pid/d: 2000.0  *
  /kr16_2_gazebo/joint2_position_controller/pid/i: 100  *
  /kr16_2_gazebo/joint2_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint2_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint3_position_controller/joint: joint_a3  * /kr16_2_gazebo/joint3_position_controller/pid/d: 1000.0  *
  /kr16_2_gazebo/joint3_position_controller/pid/i: 50  *
  /kr16_2_gazebo/joint3_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint3_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint4_position_controller/joint: joint_a4  * /kr16_2_gazebo/joint4_position_controller/pid/d: 200.0  *
  /kr16_2_gazebo/joint4_position_controller/pid/i: 50  *
  /kr16_2_gazebo/joint4_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint4_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint5_position_controller/joint: joint_a5  * /kr16_2_gazebo/joint5_position_controller/pid/d: 70.0  *
  /kr16_2_gazebo/joint5_position_controller/pid/i: 50  *
  /kr16_2_gazebo/joint5_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint5_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint6_position_controller/joint: joint_a6  * /kr16_2_gazebo/joint6_position_controller/pid/d: 70.0  *
  /kr16_2_gazebo/joint6_position_controller/pid/i: 50  *
  /kr16_2_gazebo/joint6_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint6_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint_state_controller/publish_rate: 50  * /kr16_2_gazebo/joint_state_controller/type: joint_state_contr...  *
  /kr16_2_gazebo/tool0_position_controller/joint: link_06__tool0  *
  /kr16_2_gazebo/tool0_position_controller/pid/d: 70.0  *
  /kr16_2_gazebo/tool0_position_controller/pid/i: 50  *
  /kr16_2_gazebo/tool0_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/tool0_position_controller/type: effort_controller...  *
  /robot_description:

NODES   /kr16_2_gazebo/
      controller_spawner (controller_manager/spawner)   /
      gazebo (gazebo_ros/gzserver)
      gazebo_gui (gazebo_ros/gzclient)
      spawn_gazebo_model (gazebo_ros/spawn_model)

auto-starting new master process[master]: started with pid [3096]
  ROS_MASTER_URI=http://localhost:11311

setting /run_id to 133adcf4-5e8d-11e9-8069-000c2911adc8 WARNING:
  Package name "KUKA_KR16_moveit_Luka1" does not follow the naming
  conventions. It should start with a lower case letter and only contain
  lower case letters, digits, underscores, and dashes.
  process[rosout-1]: started with pid [3107] started core service
  [/rosout] process[gazebo-2]: started with pid [3110]
  process[gazebo_gui-3]: started with pid [3119]
  process[spawn_gazebo_model-4]: started with pid [3124]
  process[kr16_2_gazebo/controller_spawner-5]: started with pid [3125]
  WARNING: Package name "KUKA_KR16_moveit_Luka1" does not follow the
  naming conventions. It should start with a lower case letter and only
  contain lower case letters, digits, underscores, and dashes. WARNING:
  Package name "KUKA_KR16_moveit_Luka1" does not follow the naming
  conventions. It should start with a lower case letter and only contain
  lower case letters, digits, underscores, and dashes. WARNING: Package
  name "KUKA_KR16_moveit_Luka1" does not follow the naming conventions.
  It should start with a lower case letter and only contain lower case
  letters, digits, underscores, and dashes. WARNING: Package name
  "KUKA_KR16_moveit_Luka1" does not follow the naming conventions. It
  should start with a lower case letter and only contain lower case
  letters, digits, underscores, and dashes. [INFO] [1555229566.121403,
  0.000000]: Controller Spawner: Waiting for service /kr16_2_gazebo/controller_manager/load_controller [ INFO]
  [1555229567.920658309]: Finished loading Gazebo ROS API Plugin. [
  INFO] [1555229567.922362082]: waitForService: Service
  [/gazebo_gui/set_physics_properties] has not been advertised,
  waiting... [ INFO] [1555229567.927517546]: Finished loading Gazebo ROS
  API Plugin. [ INFO] [1555229567.928969037]: waitForService: Service
  [/gazebo/set_physics_properties] has not been advertised, waiting...
  [INFO] [1555229569.090114, 0.000000]: Loading model XML from ros
  parameter robot_description [INFO] [1555229569.100970, 0.000000]:
  Waiting for service /gazebo/spawn_urdf_model [INFO]
  [1555229569.708130, 0.000000]: Calling service
  /gazebo/spawn_urdf_model [ INFO] [1555229569.740163120, 0.023000000]:
  waitForService: Service [/gazebo/set_physics_properties] is now
  available. [INFO] [1555229570.489737, 0.159000]: Spawn status:
  SpawnModel: Successfully spawned entity [ INFO] [1555229570.502446729,
  0.159000000]: Physics dynamic reconfigure ready. [ INFO] [1555229570.679725950, 0.159000000]: Loading gazebo_ros_control plugin
  [ INFO] [1555229570.680028318, 0.159000000]: Starting
  gazebo_ros_control plugin in namespace: /kr16_2_gazebo [ INFO]
  [1555229570.680620454, 0.159000000]: gazebo_ros_control plugin is
  waiting for model URDF in parameter [/robot_description] on the ROS
  param server. [spawn_gazebo_model-4] process has finished cleanly log
  file:
  /home/gazebo/.ros/log/133adcf4-5e8d-11e9-8069-000c2911adc8/spawn_gazebo_model-4*.log
  [ INFO] [1555229570.868346785, 0.159000000]: Loaded
  gazebo_ros_control. [INFO] [1555229570.971088, 0.255000]: Controller
  Spawner: Waiting for service
  /kr16_2_gazebo/controller_manager/switch_controller [INFO]
  [1555229570.980829, 0.257000]: Controller Spawner: Waiting for service
  /kr16_2_gazebo/controller_manager/unload_controller [INFO]
  [1555229570.987506, 0.263000]: Loading controller:
  joint_state_controller [INFO] [1555229571.017423, 0.294000]: Loading
  controller: joint1_position_controller [INFO] [1555229571.106571,
  0.377000]: Loading controller: joint2_position_controller [INFO] [1555229571.162822, 0.424000]: Loading controller:
  joint3_position_controller [INFO] [1555229571.229486, 0.475000]:
  Loading controller: joint4_position_controller [INFO]
  [1555229571.288503, 0.515000]: Loading controller:
  joint5_position_controller [INFO] [1555229571.361675, 0.563000]:
  Loading controller: joint6_position_controller [INFO]
  [1555229571.418728, 0.607000]: Controller Spawner: Loaded controllers:
  joint_state_controller, joint1_position_controller,
  joint2_position_controller, joint3_position_controller,
  joint4_position_controller, joint5_position_controller,
  joint6_position_controller [INFO] [1555229571.426332, 0.612000]:
  Started controllers: joint_state_controller,
  joint1_position_controller, joint2_position_controller,
  joint3_position_controller, joint4_position_controller,
  joint5_position_controller, joint6_position_controller

From output I can see that all controllers are loaded,to confirm it here is output of rostopic:

```<code>/clock
/gazebo/link_states
/gazebo/model_states
/gazebo/parameter_descriptions
/gazebo/parameter_updates
/gazebo/set_link_state
/gazebo/set_model_state
/kr16_2_gazebo/joint1_position_controller/command
/kr16_2_gazebo/joint1_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint1_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint1_position_controller/state
/kr16_2_gazebo/joint2_position_controller/command
/kr16_2_gazebo/joint2_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint2_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint2_position_controller/state
/kr16_2_gazebo/joint3_position_controller/command
/kr16_2_gazebo/joint3_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint3_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint3_position_controller/state
/kr16_2_gazebo/joint4_position_controller/command
/kr16_2_gazebo/joint4_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint4_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint4_position_controller/state
/kr16_2_gazebo/joint5_position_controller/command
/kr16_2_gazebo/joint5_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint5_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint5_position_controller/state
/kr16_2_gazebo/joint6_position_controller/command
/kr16_2_gazebo/joint6_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint6_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint6_position_controller/state
/kr16_2_gazebo/joint_states
/rosout
/rosout_agg
</code>```

and robot is just like hanging on base link, because base link is only one which has type=fixed and all other have type=revolute.

here is picture of hanging robot:

When I lift and release robot in gazebo using mouse, robot just fall down and axis are just shaking like there is no motor or any force which keeps them fixed.


问:
Why my robot is lying down in gazebo simulator?
this is my first post about ROS and Gazebo also I am new in ROS.
I spawn KUKA robot in Gazebo using urdf file from KUKA github repository
following answer from this question I spawned my urdf file in gazebo simulator and KUKA robot appeared in simulator but problem is that is lying down like is attached on floor for some reason.
Here is picture in Gazebo:

This is my launch file:

```<code><launch>
<!-- We resume the logic in empty_world.launch, changing only the name of the world to be launched -->
<include file="<span class="math-container">$(find gazebo_ros)/launch/empty_world.launch">
  <arg name="paused" value="false"/>
  <arg name="use_sim_time" value="true"/>
  <arg name="gui" value="true"/>
  <arg name="headless" value="false"/>
  <arg name="debug" value="false"/>
</include>
<node name="spawn_urdf" pkg="gazebo_ros" type="spawn_model" args="-file $</span>(find kuka_kr210_support)/urdf/kr210l150.urdf -urdf -z 1 -model baxter" />
</launch>
</code>```

EDIT:
I fixed base link for the world, added transmission, controllers for each axis and gazebo plugin. now my urdf file looks like this:

```<code><?xml version="1.0" ?>
<!-- =================================================================================== -->
<!-- |    This document was autogenerated by xacro from kr16_2.xacro                   | -->
<!-- |    EDITING THIS FILE BY HAND IS NOT RECOMMENDED                                 | -->
<!-- =================================================================================== -->
<!--Generates a urdf from the macro in kr16_2_macro.xacro -->
<robot name="kuka_kr16_2" xmlns:xacro="http://wiki.ros.org/xacro">
  <!-- LINKS -->

  <!-- base link -->
  <link name="base_link">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/base_link.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/base_link.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 1 (A1) -->
  <link name="link_1">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_1.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_1.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 2 -->
  <link name="link_2">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_2.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_2.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 3 -->
  <link name="link_3">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_3.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_3.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 4 -->
  <link name="link_4">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_4.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_4.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 5 -->
  <link name="link_5">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_5.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_5.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 6 -->
  <link name="link_6">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_6.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_6.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- tool 0 -->
  <!-- This frame corresponds to the $FLANGE coordinate system in KUKA KRC controllers.
  <link name="tool0"/> -->

  <!-- END LINKS -->
  <!-- JOINTS -->
  <!-- joint 1 (A1) -->
  <joint name="joint_a1" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0.675"/>
    <parent link="base_link"/>
    <child link="link_1"/>
    <axis xyz="0 0 -1"/>
    <limit effort="0" lower="-3.22885911619" upper="3.22885911619" velocity="2.72271363311"/>
  </joint>

   <transmission name="trans_joint_a1">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a1">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a1">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 2 (A2) -->
  <joint name="joint_a2" type="revolute">
    <origin rpy="0 0 0" xyz="0.26 0 0"/>
    <parent link="link_1"/>
    <child link="link_2"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.70526034059" upper="0.610865238198" velocity="2.72271363311"/>
  </joint>

   <transmission name="trans_joint_a2">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a2">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a2">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 3 (A3) -->
  <joint name="joint_a3" type="revolute">
    <origin rpy="0 0 0" xyz="0.68 0 0"/>
    <parent link="link_2"/>
    <child link="link_3"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.26892802759" upper="2.68780704807" velocity="2.72271363311"/>
  </joint>

   <transmission name="trans_joint_a3">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a3">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a3">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 4 (A4) -->
  <joint name="joint_a4" type="revolute">
    <origin rpy="0 0 0" xyz="0.67 0 -0.035"/>
    <parent link="link_3"/>
    <child link="link_4"/>
    <axis xyz="-1 0 0"/>
    <limit effort="0" lower="-6.10865238198" upper="6.10865238198" velocity="5.75958653158"/>
  </joint>

   <transmission name="trans_joint_a4">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a4">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a4">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 5 (A5) -->
  <joint name="joint_a5" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="link_4"/>
    <child link="link_5"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.26892802759" upper="2.26892802759" velocity="5.75958653158"/>
  </joint>

   <transmission name="trans_joint_a5">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a5">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a5">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- joint 6 (A6) -->
  <joint name="joint_a6" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="link_5"/>
    <child link="link_6"/>
    <axis xyz="-1 0 0"/>
    <limit effort="0" lower="-6.10865238198" upper="6.10865238198" velocity="10.7337748998"/>
  </joint>

   <transmission name="trans_joint_a6">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a6">
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a6">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission>

  <!-- tool frame - fixed frame
  <joint name="joint_a6-tool0" type="fixed">
    <parent link="link_6"/>
    <child link="tool0"/>
    <origin rpy="0 1.57079632679 0" xyz="0.158 0 0"/>
  </joint>

   <transmission name="trans_joint_a6-tool0">
      <type>transmission_interface/SimpleTransmission</type>
      <joint name="joint_a6-tool0">
        <hardwareInterface>EffortJointInterface</hardwareInterface>
      </joint>
      <actuator name="motor_joint_a6-tool0">
        <mechanicalReduction>1</mechanicalReduction>
        <hardwareInterface>EffortJointInterface</hardwareInterface>
      </actuator>
   </transmission> -->

  <!-- END JOINTS -->
  <!-- ROS base_link to KUKA $ROBROOT coordinate system transform -->
  <link name="base"/>
  <joint name="base_link-base" type="fixed">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="base_link"/>
    <child link="base"/>
  </joint>

  <!-- Gazebo world joint -->
  <!-- Used for fixing robot to Gazebo 'base_link' -->
  <link name="world"/>

  <joint name="fixed" type="fixed">
    <parent link="world"/>
    <child link="base_link"/>
  </joint>

<gazebo>
  <plugin name="gazebo_ros_control" filename="libgazebo_ros_control.so">
    <robotNamespace>/kr16_2_gazebo</robotNamespace>
  </plugin>
</gazebo>

</robot>
</code>```

This is controller yaml:

```<code># Publish all joint states -----------------------------------
joint_state_controller:
  type: joint_state_controller/JointStateController
  publish_rate: 50

# Position Controllers ---------------------------------------
joint1_position_controller:
  type: effort_controllers/JointPositionController
  #joint: base_link__link_01
  joint: joint_a1
  pid: {p: 100, i: 100, d: 500.0}
joint2_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_01__link_02
  joint: joint_a2
  pid: {p: 100.0, i: 100, d: 2000.0}
joint3_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_02__link_03
  joint: joint_a3
  pid: {p: 100.0, i: 50, d: 1000.0}
joint4_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_03__link_04
  joint: joint_a4
  pid: {p: 100.0, i: 50, d: 200.0}
joint5_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_04__link_05
  joint: joint_a5
  pid: {p: 100.0, i: 50, d: 70.0}
joint6_position_controller:
  type: effort_controllers/JointPositionController
  #joint: link_05__link_06
  joint: joint_a6
  pid: {p: 100.0, i: 50, d: 70.0}
tool0_position_controller:
  type: effort_controllers/JointPositionController
  joint: link_06__tool0
  #joint: joint1
  pid: {p: 100.0, i: 50, d: 70.0}
</code>```

and this is my launch file:

```<code><?xml version="1.0"?>
<launch>

  <arg name="paused" default="false"/>
  <arg name="gazebo_gui" default="true"/>
  <arg name="urdf_path" default="$(find kuka_kr16_support)/urdf/kr16_2_gazebo.urdf"/>

  <!-- startup simulated world -->
  <include file="<span class="math-container">$(find gazebo_ros)/launch/empty_world.launch">
    <arg name="world_name" default="worlds/empty.world"/>
    <arg name="paused" value="$</span>(arg paused)"/>
    <arg name="gui" value="$(arg gazebo_gui)"/>
  </include>

  <!-- send robot urdf to param server -->
  <param name="robot_description" textfile="$(arg urdf_path)" />

  <!-- Load controllers -->
  <rosparam ns="/kr16_2_gazebo" command="load" file="$(find kuka_kr16_moveit_gazebo)/config/joints.yaml" />

  <!-- push robot_description to factory and spawn robot in gazebo at the origin, change x,y,z arguments to spawn in a different position -->
  <node name="spawn_gazebo_model" pkg="gazebo_ros" type="spawn_model" args="-urdf -param robot_description -model robot -x 0 -y 0 -z 0"
    respawn="false" output="screen" />

  <!-- Controllers -->
  <node name="controller_spawner" pkg="controller_manager" type="spawner"
    respawn="false" output="screen" ns="/kr16_2_gazebo"
    args="--namespace=/kr16_2_gazebo
    joint_state_controller
    joint1_position_controller
    joint2_position_controller
    joint3_position_controller
    joint4_position_controller
    joint5_position_controller
    joint6_position_controller
    --timeout 60">
  </node>

</launch>
</code>```

And when I launch it in terminal this is output:

WARNING: Package name "KUKA_KR16_moveit_Luka1" does not follow the
  naming conventions. It should start with a lower case letter and only
  contain lower case letters, digits, underscores, and dashes. ...
  logging to
  /home/gazebo/.ros/log/133adcf4-5e8d-11e9-8069-000c2911adc8/roslaunch-ubuntu-3085.log
  Checking log directory for disk usage. This may take awhile. Press
  Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB.

WARNING: Package name "KUKA_KR16_moveit_Luka1" does not follow the
  naming conventions. It should start with a lower case letter and only
  contain lower case letters, digits, underscores, and dashes. started
  roslaunch server http://ubuntu:35047/

SUMMARY

PARAMETERS  * /gazebo/enable_ros_network: True  *
  /kr16_2_gazebo/joint1_position_controller/joint: joint_a1  *
  /kr16_2_gazebo/joint1_position_controller/pid/d: 500.0  *
  /kr16_2_gazebo/joint1_position_controller/pid/i: 100  *
  /kr16_2_gazebo/joint1_position_controller/pid/p: 100  *
  /kr16_2_gazebo/joint1_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint2_position_controller/joint: joint_a2  * /kr16_2_gazebo/joint2_position_controller/pid/d: 2000.0  *
  /kr16_2_gazebo/joint2_position_controller/pid/i: 100  *
  /kr16_2_gazebo/joint2_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint2_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint3_position_controller/joint: joint_a3  * /kr16_2_gazebo/joint3_position_controller/pid/d: 1000.0  *
  /kr16_2_gazebo/joint3_position_controller/pid/i: 50  *
  /kr16_2_gazebo/joint3_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint3_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint4_position_controller/joint: joint_a4  * /kr16_2_gazebo/joint4_position_controller/pid/d: 200.0  *
  /kr16_2_gazebo/joint4_position_controller/pid/i: 50  *
  /kr16_2_gazebo/joint4_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint4_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint5_position_controller/joint: joint_a5  * /kr16_2_gazebo/joint5_position_controller/pid/d: 70.0  *
  /kr16_2_gazebo/joint5_position_controller/pid/i: 50  *
  /kr16_2_gazebo/joint5_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint5_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint6_position_controller/joint: joint_a6  * /kr16_2_gazebo/joint6_position_controller/pid/d: 70.0  *
  /kr16_2_gazebo/joint6_position_controller/pid/i: 50  *
  /kr16_2_gazebo/joint6_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/joint6_position_controller/type: effort_controller...
  * /kr16_2_gazebo/joint_state_controller/publish_rate: 50  * /kr16_2_gazebo/joint_state_controller/type: joint_state_contr...  *
  /kr16_2_gazebo/tool0_position_controller/joint: link_06__tool0  *
  /kr16_2_gazebo/tool0_position_controller/pid/d: 70.0  *
  /kr16_2_gazebo/tool0_position_controller/pid/i: 50  *
  /kr16_2_gazebo/tool0_position_controller/pid/p: 100.0  *
  /kr16_2_gazebo/tool0_position_controller/type: effort_controller...  *
  /robot_description:

NODES   /kr16_2_gazebo/
      controller_spawner (controller_manager/spawner)   /
      gazebo (gazebo_ros/gzserver)
      gazebo_gui (gazebo_ros/gzclient)
      spawn_gazebo_model (gazebo_ros/spawn_model)

auto-starting new master process[master]: started with pid [3096]
  ROS_MASTER_URI=http://localhost:11311

setting /run_id to 133adcf4-5e8d-11e9-8069-000c2911adc8 WARNING:
  Package name "KUKA_KR16_moveit_Luka1" does not follow the naming
  conventions. It should start with a lower case letter and only contain
  lower case letters, digits, underscores, and dashes.
  process[rosout-1]: started with pid [3107] started core service
  [/rosout] process[gazebo-2]: started with pid [3110]
  process[gazebo_gui-3]: started with pid [3119]
  process[spawn_gazebo_model-4]: started with pid [3124]
  process[kr16_2_gazebo/controller_spawner-5]: started with pid [3125]
  WARNING: Package name "KUKA_KR16_moveit_Luka1" does not follow the
  naming conventions. It should start with a lower case letter and only
  contain lower case letters, digits, underscores, and dashes. WARNING:
  Package name "KUKA_KR16_moveit_Luka1" does not follow the naming
  conventions. It should start with a lower case letter and only contain
  lower case letters, digits, underscores, and dashes. WARNING: Package
  name "KUKA_KR16_moveit_Luka1" does not follow the naming conventions.
  It should start with a lower case letter and only contain lower case
  letters, digits, underscores, and dashes. WARNING: Package name
  "KUKA_KR16_moveit_Luka1" does not follow the naming conventions. It
  should start with a lower case letter and only contain lower case
  letters, digits, underscores, and dashes. [INFO] [1555229566.121403,
  0.000000]: Controller Spawner: Waiting for service /kr16_2_gazebo/controller_manager/load_controller [ INFO]
  [1555229567.920658309]: Finished loading Gazebo ROS API Plugin. [
  INFO] [1555229567.922362082]: waitForService: Service
  [/gazebo_gui/set_physics_properties] has not been advertised,
  waiting... [ INFO] [1555229567.927517546]: Finished loading Gazebo ROS
  API Plugin. [ INFO] [1555229567.928969037]: waitForService: Service
  [/gazebo/set_physics_properties] has not been advertised, waiting...
  [INFO] [1555229569.090114, 0.000000]: Loading model XML from ros
  parameter robot_description [INFO] [1555229569.100970, 0.000000]:
  Waiting for service /gazebo/spawn_urdf_model [INFO]
  [1555229569.708130, 0.000000]: Calling service
  /gazebo/spawn_urdf_model [ INFO] [1555229569.740163120, 0.023000000]:
  waitForService: Service [/gazebo/set_physics_properties] is now
  available. [INFO] [1555229570.489737, 0.159000]: Spawn status:
  SpawnModel: Successfully spawned entity [ INFO] [1555229570.502446729,
  0.159000000]: Physics dynamic reconfigure ready. [ INFO] [1555229570.679725950, 0.159000000]: Loading gazebo_ros_control plugin
  [ INFO] [1555229570.680028318, 0.159000000]: Starting
  gazebo_ros_control plugin in namespace: /kr16_2_gazebo [ INFO]
  [1555229570.680620454, 0.159000000]: gazebo_ros_control plugin is
  waiting for model URDF in parameter [/robot_description] on the ROS
  param server. [spawn_gazebo_model-4] process has finished cleanly log
  file:
  /home/gazebo/.ros/log/133adcf4-5e8d-11e9-8069-000c2911adc8/spawn_gazebo_model-4*.log
  [ INFO] [1555229570.868346785, 0.159000000]: Loaded
  gazebo_ros_control. [INFO] [1555229570.971088, 0.255000]: Controller
  Spawner: Waiting for service
  /kr16_2_gazebo/controller_manager/switch_controller [INFO]
  [1555229570.980829, 0.257000]: Controller Spawner: Waiting for service
  /kr16_2_gazebo/controller_manager/unload_controller [INFO]
  [1555229570.987506, 0.263000]: Loading controller:
  joint_state_controller [INFO] [1555229571.017423, 0.294000]: Loading
  controller: joint1_position_controller [INFO] [1555229571.106571,
  0.377000]: Loading controller: joint2_position_controller [INFO] [1555229571.162822, 0.424000]: Loading controller:
  joint3_position_controller [INFO] [1555229571.229486, 0.475000]:
  Loading controller: joint4_position_controller [INFO]
  [1555229571.288503, 0.515000]: Loading controller:
  joint5_position_controller [INFO] [1555229571.361675, 0.563000]:
  Loading controller: joint6_position_controller [INFO]
  [1555229571.418728, 0.607000]: Controller Spawner: Loaded controllers:
  joint_state_controller, joint1_position_controller,
  joint2_position_controller, joint3_position_controller,
  joint4_position_controller, joint5_position_controller,
  joint6_position_controller [INFO] [1555229571.426332, 0.612000]:
  Started controllers: joint_state_controller,
  joint1_position_controller, joint2_position_controller,
  joint3_position_controller, joint4_position_controller,
  joint5_position_controller, joint6_position_controller

From output I can see that all controllers are loaded,to confirm it here is output of rostopic:

```<code>/clock
/gazebo/link_states
/gazebo/model_states
/gazebo/parameter_descriptions
/gazebo/parameter_updates
/gazebo/set_link_state
/gazebo/set_model_state
/kr16_2_gazebo/joint1_position_controller/command
/kr16_2_gazebo/joint1_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint1_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint1_position_controller/state
/kr16_2_gazebo/joint2_position_controller/command
/kr16_2_gazebo/joint2_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint2_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint2_position_controller/state
/kr16_2_gazebo/joint3_position_controller/command
/kr16_2_gazebo/joint3_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint3_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint3_position_controller/state
/kr16_2_gazebo/joint4_position_controller/command
/kr16_2_gazebo/joint4_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint4_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint4_position_controller/state
/kr16_2_gazebo/joint5_position_controller/command
/kr16_2_gazebo/joint5_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint5_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint5_position_controller/state
/kr16_2_gazebo/joint6_position_controller/command
/kr16_2_gazebo/joint6_position_controller/pid/parameter_descriptions
/kr16_2_gazebo/joint6_position_controller/pid/parameter_updates
/kr16_2_gazebo/joint6_position_controller/state
/kr16_2_gazebo/joint_states
/rosout
/rosout_agg
</code>```

and robot is just like hanging on base link, because base link is only one which has type=fixed and all other have type=revolute.

here is picture of hanging robot:

When I lift and release robot in gazebo using mouse, robot just fall down and axis are just shaking like there is no motor or any force which keeps them fixed.

答:
Sorry for late answer but I was little bit busy. Here is my urdf file.</p>

```<code><?xml version="1.0" ?>
<!-- =================================================================================== -->
<!-- |    This document was autogenerated by xacro from kr16_2.xacro                   | -->
<!-- |    EDITING THIS FILE BY HAND IS NOT RECOMMENDED                                 | -->
<!-- =================================================================================== -->
<!--Generates a urdf from the macro in kr16_2_macro.xacro -->
<robot name="kuka_kr16_2" xmlns:xacro="http://wiki.ros.org/xacro">
  <!-- LINKS -->
  <!-- base link -->
  <link name="base_link">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/base_link.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/base_link.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 1 (A1) -->
  <link name="link_1">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_1.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_1.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 2 -->
  <link name="link_2">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_2.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_2.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 3 -->
  <link name="link_3">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_3.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_3.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 4 -->
  <link name="link_4">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_4.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_4.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 5 -->
  <link name="link_5">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_5.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_5.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 6 -->
  <link name="link_6">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_6.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_6.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- tool 0 -->
  <!-- This frame corresponds to the <span class="math-container">$FLANGE coordinate system in KUKA KRC controllers. -->
  <link name="tool0"/>
  <!-- END LINKS -->
  <!-- JOINTS -->
  <!-- joint 1 (A1) -->
  <joint name="joint_a1" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0.675"/>
    <parent link="base_link"/>
    <child link="link_1"/>
    <axis xyz="0 0 -1"/>
    <limit effort="0" lower="-3.22885911619" upper="3.22885911619" velocity="2.72271363311"/>
  </joint>
  <!-- joint 2 (A2) -->
  <joint name="joint_a2" type="revolute">
    <origin rpy="0 0 0" xyz="0.26 0 0"/>
    <parent link="link_1"/>
    <child link="link_2"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.70526034059" upper="0.610865238198" velocity="2.72271363311"/>
  </joint>
  <!-- joint 3 (A3) -->
  <joint name="joint_a3" type="revolute">
    <origin rpy="0 0 0" xyz="0.68 0 0"/>
    <parent link="link_2"/>
    <child link="link_3"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.26892802759" upper="2.68780704807" velocity="2.72271363311"/>
  </joint>
  <!-- joint 4 (A4) -->
  <joint name="joint_a4" type="revolute">
    <origin rpy="0 0 0" xyz="0.67 0 -0.035"/>
    <parent link="link_3"/>
    <child link="link_4"/>
    <axis xyz="-1 0 0"/>
    <limit effort="0" lower="-6.10865238198" upper="6.10865238198" velocity="5.75958653158"/>
  </joint>
  <!-- joint 5 (A5) -->
  <joint name="joint_a5" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="link_4"/>
    <child link="link_5"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.26892802759" upper="2.26892802759" velocity="5.75958653158"/>
  </joint>
  <!-- joint 6 (A6) -->
  <joint name="joint_a6" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="link_5"/>
    <child link="link_6"/>
    <axis xyz="-1 0 0"/>
    <limit effort="0" lower="-6.10865238198" upper="6.10865238198" velocity="10.7337748998"/>
  </joint>
  <!-- tool frame - fixed frame -->
  <joint name="joint_a6-tool0" type="fixed">
    <parent link="link_6"/>
    <child link="tool0"/>
    <origin rpy="0 1.57079632679 0" xyz="0.158 0 0"/>
  </joint>
  <!-- END JOINTS -->
  <!-- ROS base_link to KUKA $</span>ROBROOT coordinate system transform -->
  <link name="base"/>
  <joint name="base_link-base" type="fixed">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="base_link"/>
    <child link="base"/>
  </joint>
</robot>
</code>```

ContentLicense: CC BY-SA 4.0

Body:
Sorry for late answer but I was little bit busy. Here is my urdf file.

<?xml version="1.0" ?>
<!-- =================================================================================== -->
<!-- |    This document was autogenerated by xacro from kr16_2.xacro                   | -->
<!-- |    EDITING THIS FILE BY HAND IS NOT RECOMMENDED                                 | -->
<!-- =================================================================================== -->
<!--Generates a urdf from the macro in kr16_2_macro.xacro -->
<robot name="kuka_kr16_2" xmlns:xacro="http://wiki.ros.org/xacro">
  <!-- LINKS -->
  <!-- base link -->
  <link name="base_link">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/base_link.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/base_link.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 1 (A1) -->
  <link name="link_1">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_1.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_1.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 2 -->
  <link name="link_2">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_2.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_2.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 3 -->
  <link name="link_3">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_3.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_3.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 4 -->
  <link name="link_4">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_4.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_4.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 5 -->
  <link name="link_5">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_5.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_5.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- link 6 -->
  <link name="link_6">
    <inertial>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <mass value="2"/>
      <inertia ixx="0.01" ixy="0" ixz="0" iyy="0.01" iyz="0" izz="0.01"/>
    </inertial>
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/visual/link_6.dae"/>
      </geometry>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://kuka_kr16_support/meshes/kr16_2/collision/link_6.stl"/>
      </geometry>
    </collision>
  </link>
  <!-- tool 0 -->
  <!-- This frame corresponds to the $FLANGE coordinate system in KUKA KRC controllers. -->
  <link name="tool0"/>
  <!-- END LINKS -->
  <!-- JOINTS -->
  <!-- joint 1 (A1) -->
  <joint name="joint_a1" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0.675"/>
    <parent link="base_link"/>
    <child link="link_1"/>
    <axis xyz="0 0 -1"/>
    <limit effort="0" lower="-3.22885911619" upper="3.22885911619" velocity="2.72271363311"/>
  </joint>
  <!-- joint 2 (A2) -->
  <joint name="joint_a2" type="revolute">
    <origin rpy="0 0 0" xyz="0.26 0 0"/>
    <parent link="link_1"/>
    <child link="link_2"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.70526034059" upper="0.610865238198" velocity="2.72271363311"/>
  </joint>
  <!-- joint 3 (A3) -->
  <joint name="joint_a3" type="revolute">
    <origin rpy="0 0 0" xyz="0.68 0 0"/>
    <parent link="link_2"/>
    <child link="link_3"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.26892802759" upper="2.68780704807" velocity="2.72271363311"/>
  </joint>
  <!-- joint 4 (A4) -->
  <joint name="joint_a4" type="revolute">
    <origin rpy="0 0 0" xyz="0.67 0 -0.035"/>
    <parent link="link_3"/>
    <child link="link_4"/>
    <axis xyz="-1 0 0"/>
    <limit effort="0" lower="-6.10865238198" upper="6.10865238198" velocity="5.75958653158"/>
  </joint>
  <!-- joint 5 (A5) -->
  <joint name="joint_a5" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="link_4"/>
    <child link="link_5"/>
    <axis xyz="0 1 0"/>
    <limit effort="0" lower="-2.26892802759" upper="2.26892802759" velocity="5.75958653158"/>
  </joint>
  <!-- joint 6 (A6) -->
  <joint name="joint_a6" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="link_5"/>
    <child link="link_6"/>
    <axis xyz="-1 0 0"/>
    <limit effort="0" lower="-6.10865238198" upper="6.10865238198" velocity="10.7337748998"/>
  </joint>
  <!-- tool frame - fixed frame -->
  <joint name="joint_a6-tool0" type="fixed">
    <parent link="link_6"/>
    <child link="tool0"/>
    <origin rpy="0 1.57079632679 0" xyz="0.158 0 0"/>
  </joint>
  <!-- END JOINTS -->
  <!-- ROS base_link to KUKA $ROBROOT coordinate system transform -->
  <link name="base"/>
  <joint name="base_link-base" type="fixed">
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <parent link="base_link"/>
    <child link="base"/>
  </joint>
</robot>


问:
ROS how to use published data in a python script (darknet_ros)
I'm writing a python script to run with darknet_ros and bebop_autonomy package in order to take the bounding boxes of the detected objects and depending on the position of the detected objects send different flight commands (takeoff, landing, ecc) by using if elif statement.
I'm struggling as I don't know how to take the published data from darknet_ros topic (list with detected objects coordinates) and use it in the python script.

Do you have any suggestion on how to do this?

```<code>import rospy
from sensor_msgs.msg import Image
from darknet_ros_msgs.msg import BoundingBoxes
from std_msgs.msg import Header
from std_msgs.msg import String

def callback(data):
    rospy.loginfo(rospy.get_caller_id() + 'I heard %s', data.data)

def main():
    while not rospy.is_shutdown():
        rospy.init_node('listener', anonymous=True)
        rospy.Subscriber('/darknet_ros/bounding_boxes', BoundingBoxes , callback)
        rospy.spin()

if __name__ == '__main__':
    try :
        main()
    except rospy.ROSInterruptException:
        pass
</code>```

答:
BoundingBoxes message is a custom created msg by darknet_ros package, so due to this information we will have the like following log to get the X and Y:

```<code>def callback(data):
    for box in data.bounding_boxes:
        rospy.loginfo(
            "Xmin: {}, Xmax: {} Ymin: {}, Ymax: {}".format(
                box.xmin, box.xmax, box.ymin, box.ymax
            )
        )
</code>```

Body:
BoundingBoxes message is a custom created msg by darknet_ros package, so due to this information we will have the like following log to get the X and Y:

def callback(data):
    for box in data.bounding_boxes:
        rospy.loginfo(
            "Xmin: {}, Xmax: {} Ymin: {}, Ymax: {}".format(
                box.xmin, box.xmax, box.ymin, box.ymax
            )
        )


问:
Why do 3-axis accelerometers seemingly have a left-handed coordinate system?
Careful inspection of page 35 (figure 58) of the ADXL345 datasheet shows that under gravitational loading only, the chip uses a left-handed coordinate system.  My own experiments with this chip confirm this.

I typically only use the chip to indicate the gravity vector.  So when using this chip, I simply negate the values to get a right handed coordinate system.  But this doesn't seem right.  I assume there is a logical and mathematical explanation for the left-handed coordinate system but i can't figure out what it might be.

答: At the end of the day, you can use a matrix to transform whatever coordinate system was used to your own system. This is typically the case when you have to place parts in a certain direction because of routing difficulties. Using a simple 3x3 matrix you can transform X,Y,Z readings so that they all align on multiple sensors. The matrix will have 0, 1 and -1 values accordingly depending on how the transformation is to be done.</p>

ContentLicense: CC BY-SA 3.0


问:
How to get constant motor RPM regardless of battery voltage?
I have a brushless motor with a propeller attached, driven by an ESC and a LiPo battery. I noticed that as the battery level drops, the motor spins slower, which makes sense. My question is is it possible to get constant performance out of the motor (constant RPM) as the voltage of the battery drops from 4.2 to 3.7V?</p>

答:
If your only goal is a constant speed throughout the charge cycle of the battery, you could drop the voltage to something below the low end of the battery range. If you set the voltage at 3.7 V, you'll draw less current at the high end of the battery charge and more at the low end, but the voltage should stay constant.

Of course, this doesn't give you the maximum speed possible at all times. For that, using something like what Kojoe mentioned is your best bet, but it will drain your battery faster.


问:
How should I create a Pangolin (Armadillo) structure?
I am new to this forum. I want to create a mechanical structure as depicted in the image A pangolin bag. And further wouls like to automate the closing and opening of the bag. But I am facing issues with the design and movements of these layers. One layer is blocking another layer from moving or i must say rotating. They kind of block each other . Is there a sophisticated design to achieve this ?? Simply cutting flaps(layers) of equal length won't work. I think the lowest flap should be of smallest length. But the problem arises when you punch hole these layers by a same amount of length and then try to rotate them. They blocks </p>

答:
I would work backwards, looking at the design when it is closed. From that, you'll see how much larger each piece needs to be than the one below. Each piece is probably connected to the one below it with fabric.

To actuate this, you could simply rotate the top-most piece upwards, which will pull the pieces below with the fabric connectors.


问:
Help in Computing Inverse Kinematics of a 5 DOF Robot Config

Its is a robot config with 5 DOF. We are provided 2 offsets d1 and d2. d1 and d2 are both 0.04 meter.

It is confusing for me alittle bit. I am attending lectures online but I am having trouble figuring out the angle joint configs and their mappings.

Is there a simulation software I can use to visualize and understand its parameters.

答:
Surprisingly, IK for a 5DOF robot arm is much harder than for a 6DOF arm.  The reason is because a 5DOF arm cannot achieve an arbitrary pose in task space.  Pose is typically expressed in terms of a 4x4 homogeneous transformation matrix ($\in SO(3)$) which encodes position (3 task-space DOF) and orientation (3 task-space DOF).  To solve IK for your 5DOF robot you need to decide which task-space DOF you don't care about.  For example you can compute IK that will take the end-effector to the desired position, and perhaps a desired roll and pitch angle, but you have no control over the yaw angle.

I tried to explain this at greater length with examples in a tutorial for the 4DOF case.


问:
Motor vs weight
I hope someone can help me out with please.
Revolving platform on rollers. weight 800kg.
Add car that parks on top . Weight 2000kg
Total weight 2800kg to be rotated.
6x dc motors pushing against the edge of the platform.making it rotate.
motor code TTOEC070240-S2
MOTOR SPECS
24V
0.07 NM
3000rpm
100watt
GEARBOX
MNRV025
60-1 RATIO

100mm rubber wheels attached to gearbox. The wheels push against the platform edge to make it rotate.
Final speed out of gearbox is 50rpm
Platform is 4.4m diameter

Everything works well with current setup but, the gearboxes overheat. Cannot take the 3000rpm input.
My question is,
If I supplied 12v instead of 24v power to the motors, I would be reducing the motor speed to 1500rpm. Which is acceptable to the gearboxes. But I have to change the gearbox ratio to 30-1 so as to keep the final rpm at 50 rpm.
Will there be enough power to push the 2800kg mass?

Thanks in advance

答:
The weight is not really relevant, it is the rolling friction.  In steady state the motor torque $\tau_m$ is equal to the friction torque $\tau_f$ which is related to angular velocity $\omega$ by

$\tau_f = B \omega$

where $B$ is the friction coefficient (which will be proportional to weight).  The power required is

$P = \tau_f \omega = B \omega^2$

so if you halve the input voltage you will need to double the current to provide the same amount of power, ie. to rotate the turntable at the same speed.  This is likely to move the pain from the gearboxes to the motors.  Perhaps add more motors at the original gear ratios so that everything is a bit less stressed -- your components will last longer.

Title: Motor vs weight


问:
Extrinsic calibration of a multicamera-rig mounted rigidly on a mobile robot
We have a set of 8 cameras mounted rigidly on a mobile robot. The cameras are forming an arc, which allows a 360º vision.

I want the extrinsic parameters of them referred to the robot. Is there any ROS package that allows that? If not, how can I do that?

I was thinking of doing some stereo calibrations between the pairs of cameras. Then, refer all the cameras to the same camera system with simple transformations.

Edit: Other option is doing something like in https://www.researchgate.net/publication/329600906_Charuco_Board-Based_Omnidirectional_Camera_Calibration_Method

In this paper they propose a Charuco board-based cube structure to calibrate the camera rig. But the problem is that I must make the cube on my own and can introduce some errors.

Any help?
Thank you!!

答: The ar_track_alvar offers a neat way to locate the pose of each camera relative to multiple marker tags. By aggregating the information from multiple tags you should be able to get a robust measurement. </p>


问:
Position vs Image based visual servoing?
Can anyone explain Image based visual servoing for robotic arm through example?

I can understand Position based based visual servoing like this,

....

there is an object and estimating it 6D Pose relative to camera using feature points(ex. using algorithm like PnP) and give this Pose to controller  directly for pick...

....

but what about Image based servoing?

...

...

Thanks.

答:
The problem in both cases is to move the robot tool to some pose relative to an object.  Let's assume the camera is attached to the end of a robot arm (eye in hand case) so we will consider this a problem in moving the camera.  The tool will always be at a fixed relative pose to the camera.

In PBVS we uses a geometric model of the object, plus known camera parameters, to estimate the pose of the object relative to the camera.  If we know the desired pose of the object relative to the camera it is straightforward to compute the error in pose and then plan a robot motion to correct it.

In IBVS we do not use or need a geometric model of the object, but we do need to be able to find some features in the camera's image of the object.  The features can be the coordinates of points, parameters of lines or ellipses, moments etc.  Let's take the simple example of point features.  The position of the points in the image depends, in a complex way, on the relative pose between the camera and the object, ie. if you move the camera the points on the object move in the image. IBVS requires that we know where the point features are in the camera image when the camera is at the desired pose -- the desired point features.  If the camera is not at the desired pose then the point features will be at different places in the camera image.  IBVS takes the currently observed point features and directly computes the desired velocity of the camera that will move the points to the desired location in the image, and implicitly drive the camera to the desired relative pose.

There are a ton of caveats and extra details, but this is the gist of the difference between PBVS and IBVS.


问:
High power jumping mechanism in small robots
I recently saw this video on YouTube featuring a jumping robot: 5 Fastest Robots In The World

I was curious how this is accomplished mechanically? Do they wind a strong spring or use some sort of air powered piston?

答:
Looks like it uses a propane powered ram to launch itself into the air.

The end of the piston is visible in the back of the vehicle.

This webpage states that source of power is battery and propane

https://bostondynamics.com/sandflea

Also found this patent for a combustion powered linear actuator.

https://patents.google.com/patent/US7263955B1/en


问:
Design a robot that can apply hot glue to paper
I need to automate a process that involves applying hot glue to paper. I own a standard handheld hot glue gun, like this one:

Sticks of room-temperature glue are fed in the right side. Pulling the trigger slightly advances the stick of glue. The orange tip on the left is heated, melting the glue stick, and the pressure of the advancing glue stick causes heated liquid glue to come out of the tip. It quickly cools once it's applied to a surface such as paper, and becomes a room-temperature adhesive within just a few seconds.

Industrial-scale machines exist to apply hot glue to surfaces, but they are very expensive. They don't involve glue sticks and hand-activated triggers; they involve glue beads and some other mechanism for forcing liquid hot glue out of the heated nozzle, and then cutting it off.

Using either the glue gun that I already own, or simply the sticks of glue with another heating-and-pressure mechanism, is there a simple way to robotically apply hot glue to paper?

EDIT: In my application, the paper will be on a flat tray. The 'bot needs to apply a line of glue around the edge of a 1" circle, or a 1" square. Once the application is complete the glue should stop emitting from the gun. There is often a "streamer" of glue after it stops emitting; I want this to be handled without a mess. The paper is then move a few inches, and the 'bot squirts out another circle or square of glue. The process keeps repeating.

答:
The problem I see is that after a while of holding the trigger, you have to let go of the trigger and then squeeze again. This is because the trigger has advanced the stick of glue as far as the travel allows it. So by squeezing it again, the trigger goes further up the glue stick and grips at a new location.

You can either automate this squeeze-release-squeeze-release pattern or look at adding a continuous feed solution (such as these).

You are only after 1" squares or circles so I think the trigger method would suffice. The actuation method could be pneumatic or electric, it doesn't really matter. As long as you can get the squeeze-release motion. At the the time releasing the trigger you would need to stop the motion until you are back into the squeeze part of the cycle again.

A standard X-Y gantry system would be sufficient. These can be cheeply purchased off sites such as AliExpress or Ebay. Like this one.

You will need stepper motors and software (such as Mach 3 or Linux CNC) to drive the stepper motors using G-code.


问:
IMU and encoder fusion
I'm trying to simulate data fusion for a 4-wheeled mobile robot using ekf and am using IMU and wheel encoders as sensors,where IMU measures linear acceleration and angular velocity  and encoder measures left and right wheel linear velocity all in body frame. now I need the measurement data for both sensors in a way that they fit each other(I mean acceleration in IMU is related to left and right velocity in encoder) but can't make the connection .I really appreciate it if anyone can help me with that.</p>

答:
From the encoders you pick "tics" (n) per time unit (t), with this you can calculate the angular velocity ($\omega$) of each wheel.

$\omega = \frac{2\pi n} { N t} $

Where N is the total amount of pulses per revolution.

After calculating the angular velocities you can calculate the linear velocity of each wheel.

$v = \omega * R $, where  R is the wheel radius.

And then with inverse kinematics you are able to calculate the velocity of your vehicle. The problem is that you give too less information about your robot e.g. what kind of wheels you have, can they drive both directions?

Title: IMU and encoder fusion


问:
Calculating the distance of a point from point cloud data
I'm getting the x,y,z values for three points as follows:

x : -0.357200  y: -0.205010  z: 0.940000

x : -0.310266  y: -0.200437  z: 0.961000

x : -0.299289  y: -0.140374  z: 0.927000

and the point cloud :

Why are some of the values negative?

Does z: 0.961000 mean it is 0.961 meter away towards the z axis?

Also, how is the center of these x,y,z axes computed?

答: These values are relative to the camera. Z is always positive as the camera can't see what is behind. X and Y can be positive or negative depending on if an object is left/right or higher/lower than the camera's viewing direction. </p>


问:
Tool calibration- orientation
I'm currently working calibrating a robot's tool. I have found some simple methods to get the tool centre point. But I'm unsure about how to get the tool's orientation relative to the robot's tip (the point where the tool is attached to the robot). The assumption here is that the tool-free robot is calibrated.

I'm looking for a solution which doesn't use camera or expensive sensors.

EDIT:
The robot is 6dof. The accuracy I'm looking at is approximately 0.1mm. The programming will be C language (How is this info related to the calibration method?).

Could someone guide in this aspect?

答:
One method that doesn't require any sensors or cameras, is to use a pointer 'tool', mark some known points and use geometry.

Attach a simple pointer tool (something with a nice point on one end, but that is aligned with the mounting plate but just offset by a known length).

Then, move the robot so that the pointer is touching 3 or 4 points on the workspace surface (for example) and record their Cartesian X,Y,Z position as reported by the robot controller and mark them on the surface (probably best if the pointer tool is sharp enough to make a small point indentation).

Then, mount your tool and jog the robot so that the end-effector reference point is positioned on each of the previously marked points and record the Cartesian X,Y,Z from the controller again.

Now, from the initial pointer, you can subtract the offset to know where the tool mounting plate is in 3D.  Then, using some simple geometry (e.g. on paper), you can use angles of triangles and trigonometry to calculate the angles between the tool end and the tool plate to obtain a rotation angles about X & Y.

Title: Tool calibration- orientation


答:
You are setting up a filter to estimate a overall state of the robot. This state can consist of whatever you choose: orientation, position, velocity, acceleration, temperature, mood, etc. For your purposes, you have very good information to estimate the forward and angular velocity of the robot. (Though you could estimate the orientation and position as well, but this would be less accurate over time as drift accumulates).

It seems like you have an idea of how to get the velocity of the robot from the wheel encoders. You can get similar velocity measurements or estimations from your IMU.

For an example, lets look at the forward velocity of your robot (with zero angular velocity for now). You have two sensor measurements of this to feed into your filter: the wheel encoders and the IMU linear acceleration. The wheel encoders are really the position of the wheels at various update rates, so you're differentiating those positions to get velocity. The linear acceleration can be integrated to also estimate velocity.

vel = vel_prev + accel*dt

Now you have two estimates of forward velocity that can be fed into a filter. You can think of these as correcting each other; velocity measurements from the wheel encoders will give you accurate long-term information, but may be susceptible to wheel slippage. The IMU will give you short term information that is accurate in a global sense, but will quickly accumulate errors.

For angular velocity, you have a direct measurement from the IMU gyros and you have an indirect measurement from the differences in wheel encoder velocities. Again, these can be combined into a filter.

Title: IMU and encoder fusion

Body: I'm trying to simulate data fusion for a 4-wheeled mobile robot using ekf and am using IMU and wheel encoders as sensors,where IMU measures linear acceleration and angular velocity  and encoder measures left and right wheel linear velocity all in body frame. now I need the measurement data for both sensors in a way that they fit each other(I mean acceleration in IMU is related to left and right velocity in encoder) but can't make the connection .I really appreciate it if anyone can help me with that.</p>


问:
Need help calculating the thrust on quadcopter motors
I'm trying to calculate the lifting capability of my four quadcopter motors. I tried using eCalc but it doesn't have battery I'm using. Are there any equations to keep in mind for doing these calculations? Here are some relevant details:

Battery: 2200mAh 3S 25~50C LiPo

ESC: 25A

Motor: 1240kV Brushless

Propeller: 8x4

Any help would be much appreciated, thanks!

答:
There are way too many factors and unknowns that you would have to consider to simply calculate the thrust. The simplest way is to do it empirically - build a rig where you can simply weigh the motor, subtract its weight and start increasing rpm and measuring the thrust in steps and also current and voltage so that you can calculate efficiency. The most important factors that will impact the thrust and efficiency are: the type of the motor, the propeller pitch and diameter and the materials the propeller is made of and how well the motor and propeller are balanced. Generally the motors that have lower RPM/V (KV rating) and can run on higher voltages are more efficient because higher currents mean higher heat loss.

Keep in mind that even with the rig with the scale, your measurements won't be 100% representative because first of all the motors are attached to arms which create drag and energy loss due to non-zero stiffness and when you have several motors running in the same plane next to each other, they interfere and the actual thrust is slightly lower. The closer the tips of the propellers will be to each other, the less efficient it becomes. A recommended separation is at least 1/3 of the propeller diameter.


问:
SLAM from partly occluded LiDAR sensor
I am building my first project which will use 2D LIDAR for SLAM and the robotic platform is a small car. However the LIDAR is hidden inside and it's occluded by 4 cylinders which connect the roof with the floor of the platform. Is it possible to reliably map the environment and the position of the robot when the lidar is occluded like that? I would be very thankful for recommending some of the simplest possible algorithms to handle this problem.

For clarity, I sketched what the robot looks like from 2 sides:

The environment of the robot is not known a priori. The robot only knows the direction and distance to the waypoint and its goal is to navigate to it and plan its motion as it is progressing and discovering new obstacles.

答: This is definitely possible and rather normal. You should set the respective measurements to zero or NaN and most algorithms should be able to handle these cases. Laserscans almost always have incomplete data (e.g. due to maximal distance or a object with very high or low reflectivity)</p>

Title: SLAM from partly occluded LiDAR sensor


问:
What is the difference between the pose of a robot and the configuration of a robot?
Do "configuration" and "pose" means the same thing? If not what is the difference?</p>

答:
Do "configuration" and "pose" means the same thing?

No.

One of the most clear definitions of 'pose' that I've heard is in Peter Corke's Robotics, Vision and Control (RVC).  It states that:

"The position and orientation of a coordinate frame is known as its pose and is shown graphically as a set of coordinate axes. The relative pose of a frame with respect to a reference coordinate frame is denoted by the symbol ξ".

The following figure is figure 2.2 in RVC:

The point P can be described by coordinate vectors relative to either frame {A} or {B}. The pose of {B} relative to {A} is $ ^{A} ξ _{B} $

The 'configuration' of a robot is a set of scalar parameters that specify the positions of all of the robot's points relative to some fixed coordinate system.  This can be expressed as a vector of positions and orientations, for example:

q = ($x$, $y$, $\theta$)

or

q = (($x$, $y$, $z$, $\alpha$, $\beta$, $\gamma$))

The set of all possible configurations is the 'configuration space', or 'C-space'.

If we consider the two-link planar manipulator with 2 revolute joints (2R-arm), shown here (taken from fig 7.3 in RVC):

The configuration can be expressed in terms of just the two joint angles $\theta _{1}$ and $\theta _{2}$, while the configuration space is the set of all possible combinations of the joint angles $\theta _{1}$ and $\theta _{2}$.

Note that configurations are not necessarily unique. For this robot, there are two possible configurations that result in the same end-effector position, but the end effector will have a different orientation in each case.

A worked example using MATLAB can be found in the Analyzing a 2-joint planar robot arm lesson on Peter's QUT Robot academy. This includes a visual description of the 2R-arm shown above.


问:
Uploading a trained ANN to an ESP32 board
I am working on a project that requires training a neural network with humidity and temperature values. After spending a while googling on how to run a neural network on ESP32 (Wemos LOLIN D32 Pro), I came to the conclusion that off-board training and then uploading would be the best option. But I didn't get any resource on doing that.

How can I upload a trained neural network model(TensorFlow, scikit-learn ...) to an ESP32 board?

答: You can printout your weights and bias value from your model in TensorFlow, PyTorch or other deep learning library. If you want to convert your model to ESP32, you must create your own code to define your feed forward network. It's very simple, like create a matrix multiplication program and also create your own activation function. Then, you take weights and bias value from your trained model and define manually in your code as variable or constant. It is should works.</p>


问:
Sensor complement in Drone
I saw a question  posted by @Rocketmagnet (Why do I need a Kalman filter?) about the need for a Kalman filter.  In that question, he says he's designing an UAV and lists the following sensors he will incorporate into the design:

3-axis accelerometer

3-axis gyroscope

3-axis magnetometer

horizon sensor

GPS

downward facing ultrasound.

This list made me question my understanding about a few of these sensors:

My questions as a newbie are :
1) do you need a magnetometer if you have a GPS sensor?
2) Do you need a horizon sensor if you have an accelerometer and a gyroscope

Are some of these sensors listed redundant for the purposes of tracking a UAV's position/orientation/navigation?

Thanks!

答:
1) Yes, a megnetometer is an instrument that measures magnetism — either the magnetization of a magnetic material like a ferromagnet, or the direction, strength, or relative change of a magnetic field at a particular location. I imagine the GPS sensor gives some approximate latitude and longitude - this isn't something a magnetometer could give you.

2) As for the horizon sensor, it seems unlikely that you would need one. However, if calibrated correctly, it does give you an absolute measurement of the horizon. Accelerometers and gyroscopes could be relative to their starting position so it could help in calibrating those sensors - however, newer accelerometers and gyroscopes (MEMS) are able to observe (near-)absolute measurements

Title: Sensor complement in Drone


问:
What is the motor that move like an elbow called
I'm trying to make wings that fold in and open. I want to have the joint of the wing controlled by a motor of some sort but I don't know what I'm looking for is called. </p>

答:
The general term is a rotary actuator, which includes servomotors and hydraulic / pneumatic actuators.

But, being a wing, probably you do not have space for an actuator directly on the elbow, and need a cable + pulley setup with a linear actuator elsewhere. It depends a lot on your space constraints.


答:
Yes, some of the sensors are redundant they complement one another. For example, if you want to do a "position hold" and stay fixed in space the GPS, in theory, should be enough. But the using only GPS you would have to move some number of meters before you notice at the GPS accuracy is measured in meters. But the accelerometer will detect very slight movement. But the accelerometer is so noisy that you can not use it for longer distances. Likewise, the gyros are very sensitive to the rotation but drift badly while the compass is not so sensitive and VERY noise but it has no long term drift

The Kalman filter is very good can be combining complementary sensors and using the strengths of each one. You get much better state estimation if you have a suite of different sensors such that their errors are all from different causes.

AlsoI amVERYsurprized a barometer is not on the list. A downward-looking radar or lidar will have trouble when it flies over a picnic table

But what to use depends on the goals. A high-performance racing drone might us only a gyro and nothing else while a camera drone does not need GPS because the pilot can see the drone. An autonomous drone does need GPS and more.

Title: Sensor complement in Drone

Body:
I saw a question  posted by @Rocketmagnet (Why do I need a Kalman filter?) about the need for a Kalman filter.  In that question, he says he's designing an UAV and lists the following sensors he will incorporate into the design:

3-axis accelerometer

3-axis gyroscope

3-axis magnetometer

horizon sensor

GPS

downward facing ultrasound.

This list made me question my understanding about a few of these sensors:

My questions as a newbie are :
1) do you need a magnetometer if you have a GPS sensor?
2) Do you need a horizon sensor if you have an accelerometer and a gyroscope

Are some of these sensors listed redundant for the purposes of tracking a UAV's position/orientation/navigation?

Thanks!


问:
Roomba Create 2: how to convert steering angle to radius?
I want to set the steering angle for Roomba Create 2, and as far as I understand I can do this by setting a turning radius for the Roomba Create 2.

My question is:

How to convert steering angle to turning radius, so that I can set a correct turning radius for a desired steering angle?

答:
The wheels can't be steered to an angle.  All you can do is make one wheel spin faster and then the robot travels along an arc with a given radius

You can place the center of the arc any place you like along a line that connects the two wheels even between the wheels or a few meters to the side or under one wheel.   Then if you need to turn to say 30 degrees you drive along the arc for 30 degrees.

To "turn in place" 30 degrees, you place the center of the arc midway between the wheels, rotate, stop then drive straight.    Is that what is needed?


问:
question about car-like robot localization based on dead-reckoning
I have a question about car-like robot localization using only dead-reckoning. Given:

robot position (at current time step) in the form $\begin{bmatrix}x & y & \theta\end{bmatrix}$ (theta is the heading)

steering angle

distance traveled between two time steps

How can I estimate the position of the robot at the next time step?

答:
I'm reasonably sure the answer to your original question using the steering angle, will involve some hefty calculus. Although I'd like to be proven wrong.

I'd suggest putting encoders on the non steering pair of wheels so you can tell how far each wheel has traveled.

As the non steering wheels are always pointing the same direction you can use the information about how far each wheel has traveled in the same way that you would for a differential drive robot. This does of course assume that the to wheels can rotate independently of each other, as is traditional with cars having a differential to allow for the vehicle turning.


问:
Aliexpress bought BNO055 UART connection
I bought a BNO055 module from Aliexpress which is shown in the picture below.

I am able to read the IMU data in an Arduino nano from this BNO055 via an I2C connection. Now, I want to connect it to a Rasberry Pi Zero. From the AdaFruit website, BNO055 Absolute Orientation Sensor with Raspberry Pi & BeagleBone Black - Hardware, I found that the connection needs to be a UART connection. But I don't see the PS1 pins on my board. Do you think it is still possible to make a UART connection on this BNO055 board or do I need to get a new board?

答:
As it stands it would appear that your version of the breakout board can not support UART mode.

Looking at the front side of the board, there are two solder pads, next to the XYZ axis label:

They aren't labelled, but following the guide by David Piling, they may require changing the soldering/bridging in order to change the mode. However, how the change is made, is not clear, and doesn't appear to be documented.

However, on the Arduino forums, this thread, GY-BNO055 Issues, and in particular this post, shows how to set the UART mode:

On the breakout there are two unmarked jumper pads

 Some manufactures are shipping these modules with the jumpers open,
  Others ship with the jumpers closed. To configure the module for i2c
  communication both jumpers should be closed.

So you need to unsolder the bridge on the pads closest to the IC, to set UART mode.

Image from Don’t get the wrong BNO055!:

When:

the pads are soldered, then they are grounded, i.e. set to 0;

the pads are open, then they are equivalent to 1 (as there appear to be two pull up resistors, just below the pads, labelled 010).

So now you can set the BNO055 to whatever mode you require by following the table:


问:
What is an axial and polar vector?
In Robot Kinematics and Dynamics by Herman Bruyninckx, it states:

Axial vectors have an inner orientation, i.e., the direction of the vector indicates the positive orientation. For example, a unit linear force vector: the positive direction of the force does not depend on the orientation (right-handed vs. left-handed) of the world reference frame. As many (but not all) other textbooks, this book implicitly uses right-handed reference frames only, but no physical arguments prevent the use of left-handed frames.

Polar vector have an outer orientation, i.e., the positive orientation cannot be derived from the direction vector itself, but is imposed on it by the "environment." For example, a unit moment of force vector: if the handedness of the world frame changes, the orientation associated with the moment vector changes too. Note that this is a feature of the coordinate representation, not of the physical property that the vector stands for.

Can someone please explain these types of vector to me?  I do not understand the explanation given.

答: It may be helpful to not get caught up in the author’s description of frames with respect to these vectors.  The author is stating that an axial vector, like a force vector, acts along a line.  But a polar vector, like a torque, acts about an axis.  </p>

Title: What is an axial and polar vector?