Unable to navigate robot [closed]

asked 2020-09-08 04:19:45 -0500

Haadi gravatar image

updated 2020-09-08 10:43:45 -0500

I am trying to autonomously navigate my robot. I have installed a laser scanner, an encoder and a bldc motor. I am using an arduino to control my robot wheels. My arduino subscribes to cmd_vel topic and rotates the wheels accordingly. I have used move base package, rosserial package and gmappping package for this purpose. When I run my launch file rviz starts and everything works normally, however when I give it 2d nav goal the wheels donot move and robot stays stationary. I have tried changing few parameter values for DWA planner's .yaml file, however still no luck. Can anyone guide me whats wrong?

P.S. I have modified the NOX ROBOT package availabe at ros wiki according to my robot and used the same launch files http://wiki.ros.org/Robots/Nox

Publishing to cmd_vel topic manually using twist_teleop_keyboard does result in movement of the wheels according to set velocity.


<?xml version="1.0"?>
                <!--  ************** Odometry ***************  -->
    <arg name="gui" default="True" />
    <param name="use_gui" value="$(arg gui)"/>
    <param name="robot_description" command="cat $(find nox_description)/urdf/nox.urdf" />

    <node name="joint_state_publisher" pkg="joint_state_publisher" type="joint_state_publisher" />

    <node name="robot_state_publisher" pkg="robot_state_publisher" type="state_publisher" />

    <node name="serial_node" pkg="rosserial_python" type="serial_node.py">
        <param name="port" value="/dev/ttyACM0"/>

    <node name="nox_controller" pkg="nox" type="nox_controller">
        <param name="publish_tf" value="true" />
            <param name="publish_rate" value="10.0" />
            <param name="linear_scale_positive" value="8" />
            <param name="linear_scale_negative" value="8" />
            <param name="angular_scale_positive" value="7" />
            <param name="angular_scale_negative" value="7" />
        <param name="angular_scale_accel" value="0.0" />
    <node pkg="tf" type="static_transform_publisher" name="odom_to_laser" args="0.0 0.0 0.3 0.0 0.0 0.0 /odom /laser 0" />
                  ************** Sensors ***************  
         <include file="$(find rplidar_ros)/launch/rplidar.launch" /> 


<?xml version="1.0"?>
            <!--  ************** Navigation ***************  -->
    <node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
        <rosparam file="$(find nox)/cfg/costmap_common_params.yaml" command="load" ns="global_costmap" />
        <rosparam file="$(find nox)/cfg/costmap_common_params.yaml" command="load" ns="local_costmap" />
        <rosparam file="$(find nox)/cfg/local_costmap_params.yaml" command="load" />
        <rosparam file="$(find nox)/cfg/global_costmap_params.yaml" command="load" />
        <rosparam file="$(find nox)/cfg/dwa_local_planner_params.yaml" command="load" />
        <param name="base_local_planner" value="dwa_local_planner/DWAPlannerROS" />
        <!-- param name="controller_frequency" value="5.0" />  -->
        <param name="controller_patience" value="15.0" />
            <param name="clearing_rotation_allowed" value="true" /> <!-- Nox is able to rotate in place -->
 <node pkg="tf" type="static_transform_publisher" name="map_to_odom" args="0.0 0.0 0.0 0 0 0.0 /map /odom 0" />
  <node pkg="tf" type="static_transform_publisher" name="odom_to_base_link" args="0.0 0.0 0.0 0 0 0.0 /odom /base_link 0" />



footprint: [ [-0.27,-0.19], [0.13,-0.19], [0.13,0.19], [-0.27,0.19] ]
transform_tolerance: 0.4
map_type: costmap ...
edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Haadi
close date 2020-09-18 04:34:41.470748


In your launchfiles you have static transform publisher odom->base_link, and static transform map->odom. You also have a odom->laser static transform. For navigation the usual setup is map->odom->base_link(from here on sensor static tf might work). In a standard setup you would use amcl for localization (odom error correction) map->odom transform.

what does "rostopic list" show? Likely a mix up with publishing and subsribing of topics. Does it work when ordering cmd_vel manualy?

Dragonslayer gravatar image Dragonslayer  ( 2020-09-08 08:45:16 -0500 )edit

Yes "rostopic list" shows multiple topics published and subscribed by move_base package, rplidar and arduino etc.

Publishing to cmd_vel manually using teleop_twist_keyboard does work and wheels rotate according to the given velocity

Haadi gravatar image Haadi  ( 2020-09-08 10:39:59 -0500 )edit

Ok, to be more clear, is move_base taking in the 2dgoal from the right topic, and is it publishing to the right cmd_vel topic? move_base could be subsribing to a non published topic or publishing cmd_vel to a different topic, "rostopic info [topic_name]" will show publisher and subscriber of the topic. Also be aware that two nodes publishing cmd_vel will not work. For example move_base and teleop running at the same time will mess things up.

Dragonslayer gravatar image Dragonslayer  ( 2020-09-08 10:49:21 -0500 )edit

Apologies for late reply.

  1. This is my rostopic info output rostopic info cmd_vel Type: geometry_msgs/Twist

Publishers: * /move_base

Subscribers: * /serial_node

  1. I am not using teleop simultaneously with move_base. I ran it separately to check if arduino is subscribing to topic or not.

  2. Do you need to see rostopic list?

  3. There is no output on rostopic echo cmd_vel before I give it 2d nav goal. Once I give it a goal following output is constantly viewed at rostopic echo cmd_vel: linear: x: -0.10000000149 y: 0.0 z: 0.0 angular: x: 0.0 y: 0.0 z: -0.286315768957

This value is constant. I think it is giving recovery rotation but nothing is moving on my robot.

Also arduino and rplidar are connected to my laptop, and not on raspberry pi at the moment

Haadi gravatar image Haadi  ( 2020-09-09 03:25:10 -0500 )edit

No problem. What I would try first is publish similar values via teleop and see if this works. As the move_base values are negative floats I would asume some casting or rounding taking place somewhere (hardwareinterface?/arduino), nulling out the data. There are also some paramters in the navigation stack that should be defined as floats (1.0 vs 1) as otherwise a type cast ocures ruining precission.

Dragonslayer gravatar image Dragonslayer  ( 2020-09-09 06:28:29 -0500 )edit

And by the way, I once got the problem that the PID controllers werent tuned right, with the standart teleop commands x=1.0 or similar the motors moved but with the real x=0.x from move_base the tuning parameters didnt get the motors moving.

Dragonslayer gravatar image Dragonslayer  ( 2020-09-09 06:41:48 -0500 )edit