Conform to ros conventions regarding frame id's and coordinate frames #9
Conversation
The driver is now configured using standard ROS parameters. If a ROS topic is provided via the "rtcm" parameter, Strings on this topic will be passed to the device as RTCM corrections (packet ID 55).
Yaw has been corrected to conform with REP 103. ros-drivers#3 RTCM corrections can be passed from a topic (as Strings). A UTM-based transform can be generated.
added instructions for RTCM and TF usage, notification of REP 103 compliance
I changed the parameter names again. I added a note about the new Odometry feature.
I'm trying to standardize the parameter names (to be more like Robotnik's). I added Odometry message output if utm_zone is provided.
Even at only 20 Hz, the driver always consumed 100% CPU time. I found that it was polling without any delay/throttling. I configured the Linux version of OpenComport() for blocking reads. CPU time dropped to 5%.
I added a note about blocking serial port reads for Linux.
Rather than specify topic and frame names using parameters, I named them relative to the current namespace.
RonaldEnsing
force-pushed
the
ros-conventions
branch
from
fadf135 to
f05316f
Compare
|
@an-scott: what would be needed to get this PR merged? I realise it could break setups of users that are using the current version of the driver, but adherence to REP-103 and REP-145 seems of critical importance for IMU / INS drivers to me. #5 by @kylerlaird that this is based on has been around for a bit as well, so it would be really nice if we could get this all merged. |
RonaldEnsing
force-pushed
the
ros-conventions
branch
from
229aa12 to
cc059db
Compare
…gation_driver into ros-conventions Conflicts: src/an_driver.cpp
RonaldEnsing
force-pushed
the
ros-conventions
branch
from
cc059db to
d38265d
Compare
|
As someone who uses this driver, I'm looking forward for this to be merged. |
|
btw, did you leave 'imu_msg.linear_acceleration' and 'imu_msg.angular_velocity' as REP145 on purpose? |
|
@edoreshef I think I don't understand your question. The goal is to make it conform to REP145 indeed. Is there something with |
|
@RonaldEnsing, you are right, I got confused there :) |
|
🛎️ |
|
An update, in the end I found that REP103 conversions to be more accurate in this branch https://github.com/lbl-anp/advanced_navigation_driver/commit/f594142841a1e1d8d889a6fa51a98908e956d6bb |
|
Hi @RonaldEnsing I am interested in using this driver with ROS and was directed to the fork of @kylerlaird. Upon seeing this PR I would like to get confirmation that this fork conforms to REP-103 and REP-145 |
|
@GrantDare I created this PR to make the driver conform to REP-103 and REP-145, because there was no REP-103 and REP145 compatible driver as far as I know. |
|
Note: This repository is abandoned by Advanced Navigation Support [email protected]. When asking them about this, they pointed me to: |
This PR makes the advanced navigation driver conform to ROS conventions:
This work is partially created using the fork of @kylerlaird [3]
In addition, the
DiagnosticStatusmessage is replaced by aDiagnosticArraymessage, to allow the use of a Diagnostic Analyzer.[1] http://www.ros.org/reps/rep-0103.html
[2] http://www.ros.org/reps/rep-0145.html
[3] https://github.com/kylerlaird/advanced_navigation_driver
[4] http://wiki.ros.org/diagnostics/Tutorials/Creating%20a%20Diagnostic%20Analyzer