-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Orientation Incorrect on GPS Duro #16
Comments
Sure, this is a good idea, early next week I will add param, so we can keep backward compatibility and also add this feature. |
@zeerek-polymath i added the param to the 16-orientation-issue branch, please test it and share your comments currently our GPS sensor is not available, but after the sensor test and your comments, it can be merged into master branch |
By default the raw values have us rotating about the x axis. By changing Lines 244 to 249 in f00726f
to: if(orientation_enu){
pose_msg.pose.orientation.w = w;
pose_msg.pose.orientation.x = x * -1;
pose_msg.pose.orientation.y = y;
pose_msg.pose.orientation.z = z;
} We get rotation correctly about Z. We need to then apply another rotation by PI_2 about Z to get ENU (without this rotation we our 0 rotation angle is SOUTH instead of EAST. However, direction of rotation is correct). We are double checking our frames of reference and should have more of an idea tomorrow. However, do you know why we have to multiply the x portion of the quaternion to rotate appropriately about z? |
We used our other GPS as a reference (Novatel PWRPAK7 https://github.com/swri-robotics/novatel_gps_driver) and we determined the orientation accordingly. As far as I understand the problem was with the left handed / right handed orientation. |
It seems like correcting from NED frame to ENU frame. Can someone help me understand the transformations? |
Let me illustrate the problem with small gifs. What you can observe is two gps-es mounted on the same vehicle. The orange arrow is Swiftnav Duro the green one is Novatel PWRPAK7 novatel driver. Novatel is a 20 Hz dual antenna RTK GPS, much more expensive compared to Duro (which provides only 10 Hz pos data).
You can download some rosbags directly from here: https://jkk-research.github.io/#dataset you can examine them in rviz or in foxglove studio. In this gifs RTK status was in float so not the most accurate but still quite good. |
Thanks for this @horverno. Great visualisation, helps me draw comparisons between our setups. The setup looks exactly as mine where I have a lowly vectornav 200 instead of Novatel. So the Duro produces the orientation quaternion in the NED frame and the following piece of code converts that NED frame to ENU frame , to match with the orientation of the Novatel or vectornav (And by all means please correct me if I am wrong ) :
Here is my understanding of what is happening :
Define original quaternion (in NED frame?)
Define a quaternion which represents a rotation of -pi/2 in z (in ENU frame?)
Rotate our original quaternion by -pi/2 in z (so the tf_aligned is in the ENU frame? What is the need of this rotation?)
Now this is where it gets confusing. Why are we negating w, swapping x and y and then negating x? |
On my GPS we are getting West North Up orientation (which does not match the standard right hand or left hand ) with inverted rotation instead of the ROS standard East North Up.
In code it may be related to the code here:
duro_gps_driver/src/duro.cpp
Lines 230 to 248 in 67db9dc
More specifically this code block:
which inverts w and x and causes inverted rotation and West to be the X axis instead of ROS standard East.
Could we get a param to switch this behavior to keep current behavior possible set to true?
The text was updated successfully, but these errors were encountered: