-
Notifications
You must be signed in to change notification settings - Fork 43
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
nav_msgs/Odometry output #44
Comments
Hi, However, it's not trivial due to frame id transformations. If you have already done the implementation, we could be interested to share with you information such as which frame id you would like. Thanks, |
I haven't done it yet. I thought an update of the driver would be better than a proxy node. |
Ok thanks, I am however a little bit concerned if nav_msgs/Odometry is really what you are looking at. It's not easy to implement from an INS that delivers latitude/longitude/altitude measurements on earth. You can explain you use case so I can better understand what we can do to assist you? Thank you, |
Sure ! We have multiple sources of odometry on the machine : wheels, slam, gps. They are all converted to nav_msgs/Odometry in order to be merged (in node such as robot_localization UKF/EKF), to be compared and displayed in RVIZ. I agree that using a relative position is not the best idea to place a robot but, aside from the GPS, all sensors provide a relative data of the robot. Maybe another type such as geometry_msgs/PoseWithCovarianceStamped would fit better ? |
Hi, Thanks, |
We are using the RTK GNSS from the Ellipse D. Thanks. |
Hi, The pos ECEF is not a projected position (not planar) UTM however gives you a X/Y/Z planar position that is suitable for the Odometry message. We are planing to implement the Odometry message using UTM projection. As a result, the Odometry and Pose messages will only be sent by the INS once a first valid absolute INS position has been computed. It will not be suited for indoor only navigation for instance. Please feel free to get back to me if you have any remark or question. Regards, |
Hi, Regards. |
Hi, |
Hi, We have indeed released a new version that aim to fix some issues and improve the overall implementation. It will be done on a dedicated feature branch and it could be very helpful if you get a chance to test the Odometry implementation once it's done. We will get back to you once we have a working version. Thanks, |
I was looking at this: """/imu/odometry nav_msgs/Odometry UTM projected position relative to the first valid INS position. Requires /sbg/imu_data and /sbg/ekv_nav and either /sbg/ekf_euler or /sbg/ekf_quat. Disabled by default, set odometry.enable in configuration file.""" I was not able to find odometry.enable in the config file : config/sbg_device_udp_default.yaml Is it something that needs to be configured in the sbg ros driver some place else ? |
Hi,
Can you add a nav_msgs/Odometry optionnal output as a new feature (Ellipse D / N) ?
It would be nice instead of everyone making a concat node.
The text was updated successfully, but these errors were encountered: