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

# Husky Quaternion Rotation w/ Odometry

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 : http://www.ogre3d.org/tikiwiki/Quater...

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


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

edit retag close merge delete

Sort by ยป oldest newest most voted

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].

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 http://www.ros.org/reps/rep-0105.html

( 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

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

This is correct (-Clearpath)

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