Husky robot not moving as it should

Hi The Construct team,

I am currently learning ROS Navigation in 5 Days course and currently in the Localization chapter, working with the Husky Robot.
I am trying to get my program working for Exercise 3.12 and having issues with the movement of Husky Robot.

When I publish any value to /cmd_vel, the robot moves just for a second and stops.
I thought my program had issues - so tried to use rostopic pub /cmd_vel ... command with linear.x = 2.5. But, again, the robot moved just a little bit forward and stopped - not the expected result.
I tried the same command with turtlebot - the robot keeps moving until stopped - expected result.

In conclusion, I can never get the square movement done correctly with Husky robot for the exercise 3.12.

Any help / advice would be appreciated!


Hi The Construct team,

I am working on Exercise 4.4 of Path Planning 1 chapter. The (husky) robot is still not moving to the goal position. I think the robot is not responding to the action goal command.

I first run this command on webshell 1:
roslaunch husky_navigation move_base_demo.launch

On webshell 2, I run this command:
rosrun send_goals

Here is my code for

#! /usr/bin/env python

import rospy
import actionlib
from move_base_msgs.msg import MoveBaseAction, MoveBaseGoal

class SendGoalsClient:

    def __init__(self):
        self.action_name = "/move_base"
        self.action_client = actionlib.SimpleActionClient(ns=self.action_name,
        print("Action Client Initialized")
        print("Waiting for Action Server...")
        print("Action Server Started and Running")

        # goal = (pos_x, pos_y, quat_z, quat_w)
        self.goals = [(0.0, -0.05, -0.90, 0.44),
                      (-3.0, -4.0, 0.015, 0.99),
                      (2.0, -4.0, 0.85, 0.55)]
        return None

    def update_goal(self, pos_x, pos_y, quat_z, quat_w):
        self.goal = MoveBaseGoal()
        self.goal.target_pose.pose.position.x = pos_x
        self.goal.target_pose.pose.position.y = pos_y
        self.goal.target_pose.pose.orientation.z = quat_z
        self.goal.target_pose.pose.orientation.w = quat_w
        return None

    def send_goal(self):
            self.goal, feedback_cb=self.feedback_callback)
        print("Goal Sent")
        return None

    def feedback_callback(self, feedback): = feedback
        return None

    def get_result(self):
        result = self.action_client.get_result()
        return None

    def main(self):
        # single loop for now - must be infinte loop.
        for goal in self.goals:
            pos_x, pos_y, quat_z, quat_w = goal
            self.update_goal(pos_x, pos_y, quat_z, quat_w)
            self.action_client.wait_for_result()  # wait for robot to reach goal
        return None

if __name__ == "__main__":
    action_client = SendGoalsClient()

# End of Code

I need some assistance getting this to work. Also let me know if anything is wrong in my code.


Hello @girishkumar.kannan ,

  • As for the 1st post, that is normal Husky behavior. In fact, this is the normal behavior of most robots. If you don’t send velocity commands, the robot stops by default. This is a standard security measure. So, if you want to move the robot continuously, you have to keep publishing velocity commands at a rate. In the case of the Turtlebot, the behavior is different because it uses what is known as a “latched” topic. When a topic is latched, the last message published is saved and automatically sent to any future subscribers that connect to it (in this case the robot). This is why the robot keeps moving even if you publish a single message to the topic.

  • As for the 2nd post, I would say that probably there’s something wrong with the orientation of the goal pose. Are you getting any messages from the move_base output? To make sure that your code is correct, you could try using a goal pose that you know 100% is correct. For instance, you can send a goal pose from RViz (using the 2D Goal Pose tool), capture this goal pose values, and then use the same ones in your program.

1 Like

Hello @girishkumar.kannan,

the robot doesn’t move because it using a velocity command multiplexer with a dead-man’s switch to increases the safety of the robot operation. This causes the robot to stop automatically if it does not continuously receive a new command message. By default rostopic pub will only send one message to each subscriber. In this case the dead-man switch will stop the robot as said before. In order for the robot to keep operating we must tell rostopic pub command to keep sending new messages at a constant frequency. We do so by adding the -r option and specifying a frequency. Try this command here and see if it works:

user:~$ rostopic pub -r 50 /cmd_vel geometry_msgs/Twist "linear:
  x: -1.0
  y: 0.0
  z: 0.0
  x: 0.0
  y: 0.0
  z: 0.0"

You will also note that the robot will immediately stop if you kill the publisher using Ctrl+C. Normally we would have to stop the robot sending a new velocity command with all zeros.

By the way this is not part of the course, so don’t worry to much about it. For the unit you have to use the keyboard teleoperation node to control the robot, and as you will have noticed you have to keep the keys pressed to move the robot. If you release a key the robot will stop. This is due to the same reasons.

I added a note to the unit indicating that it is necessary to press and hold a key on the keyboard to move the robot.

Hope this helped,



1 Like

Hi @albertoezquerro and @rzegers ,
Thank you very much for your reply.



Ok, yes, that happened. I did not know this was the normal behavior. Now I have understood why Turtlebot behaves differently than Husky.

I got those (three) values from rostopic echo /move_base/goal after using 2D Goal Pose with RViz - to move the robot to three different goal poses.

I also had rostopic echo /move_base/feedback and rostopic echo /move_base/result on two other webshells. Once I sent a Goal pose, I started getting feedback but the robot never moved (not even a little bit).



Thanks for the detail on “dead-man’s switch”. I did not know about that concept.

Yes, I did notice that the very first time. Also noted that when I release a key the robot stops - as explained by you in your reply.

rostopic pub -r <number> /cmd_vel ... command worked well. I believe now I know how to restructure my code to make the robot move.


I will mark this post as solved once I get Exercises 3.12 and 4.4 working correctly.


Hi @albertoezquerro ,

I got Exercise 3.12 working correctly.
I cannot get the robot to move in Exercise 4.4.

Here is the first goal pose request:

user:~$ rostopic echo /move_base/goal
WARNING: no messages received and simulated time is active.
Is /clock being published?
  seq: 1
    secs: 1749
    nsecs: 399000000
  frame_id: ''
    secs: 1749
    nsecs: 399000000
  id: "/send_goals_action_client-1-1749.399"
      seq: 0
        secs: 0
        nsecs:         0
      frame_id: ''
        x: 0.0
        y: -0.05
        z: 0.0
        x: 0.0
        y: 0.0
        z: -0.9
        w: 0.44

I am not sure what mistake I am doing here. The goal pose gets registered but the robot is not moving.
(My move_base is running in webshell1.)

Is this problem happening because some fields do are not matching? For example, seq, in the output message above, seq is 1 for header but it is 0 in goal.target_pose.header. Also secs and nsecs do not match.
Could this be the problem?


Hi @albertoezquerro ,

I finally got Exercise 4.4 working.

The problem was that I forgot to fill in frame_id in my Goal message. I thought it was pre-filled but it was empty by default. I set it to “map” and the robot started to move.

Marking this issue as solved.