szenergy / duro_gps_driver Goto Github PK

According to the docs of libsbp, the orientation data published in the "pose" and "odom" messages from the Duro driver node are not provided by Duro or Piksi: https://swift-nav.github.io/libsbp/c/build/docs/html/group__orientation.html
Only the baseline direction is provided, but this is not to be confused with the Duro 's orientation.

No license information available in this project, can you add an open source license (such as MIT or Apache)?

MSG_ORIENT_QUAT may not part of the future firmware.
From MSG_ORIENT_EULER the ROS standard quaternion can be calculated as a workaround.

Related to #16 #19

Not an urgent issue. After stopping the ros2 node, following error shows up:

[ERROR] [duro_node-1]: process has died [pid 42717, exit code -11, cmd '/home/dev/ros2_ws/install/duro_gps_driver/lib/duro_gps_driver/duro_node --ros-args --params-file /tmp/launch_params_x_50soe5 --params-file /tmp/launch_params_jr4meyrh --params-file /tmp/launch_params_eulraqmu --params-file /tmp/launch_params_xyxbhqmq --params-file /tmp/launch_params_w_v8zclu --params-file /tmp/launch_params_8n_tp44w --params-file /tmp/launch_params_4mpronji --params-file /tmp/launch_params_l565il6v --params-file /tmp/launch_params_n6xk85ff'].

Test and if necessary modify the driver

Couple of things to check before a non-beta release:

• Is the provided documentation enough
• Are there any performance issues
• Whether the example rosbag ok, and the current way of sharing ok
• Any typos or other problems
  @rudolfkrecht @rokusottervanger
  Thanks 👍

In the /gps/duro/imu message the orientation is zero right now, although it is provided by the sensor in the message /gps/duro/rollpitchyaw. It needs to be converted to geometry_msgs/Quaternion and fill out in a proper way.

http://docs.ros.org/en/melodic/api/sensor_msgs/html/msg/Imu.html

How can I get the orientation data? Right now the only non-zero values I get from the pose is the position (x, y, z). I'm using a swift multi in simulation mode with msg IDs 544 and 545 enabled for tcp server 0.

But in the swift sbp spec document it says swift multi and duro do not produce these messages (544 and 545)...

https://www.swiftnav.com/latest/sbp-specification

The status flags for the position message are described in the PDF that can be found here: http://swift-nav.github.io/libsbp/
The status byte should be bitmasked before it can be interpreted as an integer value. Are you interested in a PR?

Using the lastest libsbp, duro_gps_driver fails to compile. Using libsbp@e149901e63ddcdb0d818adcd8f8e4dbd0e2738d6 works as expected. Just thought I would give a heads up.

Hi

Suppose I have RTK correction bytes ready (somehow streaming),
How to write bytes on the socket of the rover piksi?

-Thanks

A ROS/ROS2 tf2 broadcaster for transforms. Send out the relative pose of coordinate frames to the rest of the system.
The parameters should be the following:

• tf_publish - Boolean
• tf_pub_child_frame_id - String
• tf_pub_frame_id - String

The transform (translation + rotation) should be the same values as current_pose pose (position + orientation)

Add possibility to change topic names from a launch file

Swiftnaw provides GPS time in msec + nsec_residual basis, but the standard ROS time is sec + nsec. Conversion is needed.

https://swift-nav.github.io/libsbp/c/build/docs/html/structsbp__gps__time__t.html

time_msg->time_ref.sec = time_gps.tow; // TODO - It is not sec: GPS time of week rounded to the nearest millisecond [ms]
time_msg->time_ref.nsec = time_gps.ns_residual; // TODO - It is not nsec: Nanosecond residual of millisecond-rounded TOW

Is it possible to release this package to the OSRF package server?

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:

More specifically this code block:

pose_msg.pose.orientation.w = tf_aligned.w() * -1;
pose_msg.pose.orientation.x = tf_aligned.y();      // left-handerd / right handed orientation
pose_msg.pose.orientation.y = tf_aligned.x() * -1; // left-handerd / right handed orientation
pose_msg.pose.orientation.z = tf_aligned.z();      // left-handerd / right handed orientation

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?

Although Duro Inertial and Piksi Multi Inertial provides orientation, Duro and Piksi Multi does not. The initial idea is to use history position data to artificially generate orientation. The limitation is obvious, the orientation accuracy is lower and it only works when moving and the precision is high (FIXED_RTK or FLOAT_RTK).

ROS design conventions requires m/s^2 and rad/sec for the sensor_msgs/Imu message type, but currently the raw data is published.
This can be fixed, see the datasheet.
This issue is also related to #3

There is now a conversion from lat long to UTM coordinates in this driver. IMHO I think you should let the driver be a driver, and perform UTM conversion separately and independently if necessary. Just use the regular ROS message types like sensor_msgs/NavSatFix and you'll be able to swap devices without the need to implement a new driver that performs UTM conversion like this one. It makes for a more flexible and lean system.

For example, for my use case, I don't need UTM conversion, but using this driver forces me to take on the extra weight of the UTM conversion for no reason.

I see that libsbp returns x_accuracy, y_accuracy, z_accuracy, w_accuracy as part of the orientation message. Could we get that as a covariance transmitted added to the pose/imu messages as well?

This node does not follow the conventions and rules about:

• Package naming: https://www.ros.org/reps/rep-0144.html
• Naming conventions for drivers: https://ros.org/reps/rep-0135.html
• Parameter namespacing: http://wiki.ros.org/Parameter%20Server
• IMU topics and using the sensor_msgs/IMU message: https://www.ros.org/reps/rep-0145.html

Also, it's good practice to separate a library for interfacing with the hardware from the ROS wrapper, implemented as a C++ class.

Would you be interested in a refactor to make your driver follow these conventions? It might break existing setups, but as there is no release yet, that doesn't seem like too much of a problem.