ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Husky Quaternion Rotation w/ Odometry

asked 2014-02-24 07:08:51 -0600

stebl gravatar image

updated 2016-10-24 08:35:56 -0600

ngrennan gravatar image

Could someone help me understand what is going on here?

I was following this quaternion tutorial and trying to apply it to a clearpath Husky A-200 :

I understand quaternions to be

[x y z w]T = [sin(a/2)nx, sin(a/2)ny, sin(a/2)*nx, cos(a/2)]T

, where a is the angle of rotation and [nx ny nz] describe the vector to rotate about. So, if I input

(a=180, [nx ny nz] = [0,0,1])

quaternion = [0, 0, 1, 0]

and the Husky should rotate 180 degrees. However, it consistently rotates 90 degrees. This is all relative to the 'odom' frame. After its first rotation I would expect an input of

(a=0, [nx ny nz] = [0,0,1])

quaternion = [0, 0, 0, 1]

to return the Husky to its starting orientation in the odom frame; however, this causes it to complete it's 180.

Can someone please explain what is happening? What quaternion do I need to do a 180 degree rotation?

We are using following commands to run the gazebo and navigation packages:

roslaunch husky_gazebo husky_empty_world.launch
roslaunch husky_navigation odom_navigation_demo.launch

Commands are published to the /move_base_simple/goal topic relative to the odom frame.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2014-02-24 07:26:45 -0600

demmeln gravatar image

updated 2014-02-24 09:07:08 -0600

Shouldn't your goal pose be relative to the fixed frame (which might be map)?

Edit: A of course the odom frame is fixed, sorry. Haven't used the nav stack in a while.

A few things to try out is sending the robot to do translation as well as rotation and manually inspecting the cmd_vel topic to see what the planner/controller is trying to do. You can also visualize the planned path as well as the goal pose in rviz [1].


edit flag offensive delete link more


/move_base_simple/goal only takes input in the 'odom' frame - it sends an error otherwise (The goal pose passed to this planner must be in the odom frame. It is instead in the map frame). In any case I understand the odom frame to be a fixed frame according to

stebl gravatar image stebl  ( 2014-02-24 07:44:30 -0600 )edit

RViz produces the expected outputs. I think this is wheel slip causing the odometry to be incorrect. Tested this on a real Husky and it produced the same 90-degree turn with 180-degree input. Kudos to an accurate gazebo simulation, and thanks for your help

stebl gravatar image stebl  ( 2014-02-25 04:14:35 -0600 )edit

This is correct (-Clearpath)

Ryan gravatar image Ryan  ( 2014-03-07 13:20:26 -0600 )edit

Question Tools

1 follower


Asked: 2014-02-24 07:08:51 -0600

Seen: 1,253 times

Last updated: Feb 24 '14