Is your feature request related to a problem? Please describe.
Not a problem, but a different use-case that would make some problems go away.
Currently, RTK with eg. the F9P is possible (ros noetic).
ublox_f9p is able to subscribe to rtcm_msg's on topic /rtcm, and pass them into the F9P module,
and then it gives us back a nice accurate NavSatFix,
all via the one USB cable or serial port.
The /rtcm topic typically gets published from ntrip_client.
Describe the solution you'd like
I'd like to be able to simply run two ublox_gps nodes and pass rtcm_msg's from one to the other.
One as fixed-base, the other as rover.
You might say that doesn't make sense having both connected to the same machine.
It makes sense, because in our projects we bridge topics between two ROS instances with separate ROS masters using mqtt_client, although any other way of bridging topics between ROS instances would work.
Describe alternatives you've considered
The alternatives are to use ntrip_client and an internet based ntrip caster - not so convenient is you don't have internet at the test site, or to run your own ntrip server and ntrip caster, in order to feed ntrip_client. These add more complexity and issues.
Additional context
I'm sure more flexibility in how rtcm_msg's are sourced and passed around won't hurt.
Perhaps this would open up other ideas.
Is your feature request related to a problem? Please describe. Not a problem, but a different use-case that would make some problems go away.
Currently, RTK with eg. the F9P is possible (ros noetic).
ublox_f9p
is able to subscribe tortcm_msg
's on topic/rtcm
, and pass them into the F9P module, and then it gives us back a nice accurateNavSatFix
, all via the one USB cable or serial port. The /rtcm topic typically gets published fromntrip_client
.Describe the solution you'd like I'd like to be able to simply run two
ublox_gps
nodes and passrtcm_msg
's from one to the other. One as fixed-base, the other as rover. You might say that doesn't make sense having both connected to the same machine. It makes sense, because in our projects we bridge topics between two ROS instances with separate ROS masters usingmqtt_client
, although any other way of bridging topics between ROS instances would work.Describe alternatives you've considered The alternatives are to use
ntrip_client
and an internet based ntrip caster - not so convenient is you don't have internet at the test site, or to run your own ntrip server and ntrip caster, in order to feedntrip_client
. These add more complexity and issues.Additional context I'm sure more flexibility in how
rtcm_msg
's are sourced and passed around won't hurt. Perhaps this would open up other ideas.