Sync ublox_dgnss with upstream

[dylan-gonzalez]

For most of the previous design cycle, we used @leighleighleigh's fork of ublox_dgnss since we needed support for RTCM message transport over USB. But it seems like the upstream has since implemented this except for the base-station side. We should contribute the downstream base-station RTCM message publishing to the upstream.

it looks like upstream has had heaps of development, and there seems to be some discussion of the RTCM message transport over USB - which is the feature I had implimented

so it looks like upstream is ALMOST what you need.
it subscribes to RTCM correction messages, at the topic /ntrip_client/rtcm, using the message type rtcm_msgs/Message
In my fork, this was done using the RTCM3 message type on the /rtcm3_in topic, which is pretty much exactly the same (raw byte array).
So that means upstream code should work on rover-side. On base-station side, you need to find a way to receive the RTCM3 messages from the USB, read them into a rtcm_msgs/Message type, and publish that out. Compare my version of ublox_dgnss_node.cpp/ubox_in_callback, to their version (here).

So basically I would recommend trying to re-implement my changes over upstream. If you have time.

1. Change ublox_in_callback() so it reads the actual RTCM3 correction messages (raw binary data) from the base station GPS USB. Put this into some kinda queue.
2. While you are at it, add a timer and publisher for the rtcm_msgs/Message type, which reads from the rtcm_queue and publishes OUT into the ROS network.
3. Tell the rover to remap the /ntrip_client/rtcm topic, to the one which the base station is sending.So basically I would recommend trying to re-implement my changes over upstream. If you have time.

And make sure to use the same launch parameters as in my fork, which ensures the GPS will actually send data out the USB port in the first place!!

I also think we should not use specific launch files like base.launch.py and rover.launch.py. Instead, we should contribute a parameter server to the upstream to set relevant params, rather than having many launch files that are only different because of the parameters they set.

Note: we currently use a fork of Leigh's fork that modifies the launch file so it can work with humble; we shouldn't need to upstream this if we do what I suggested above

Steps:

1. create a new fork of ublox_dgnss
2. re-implement Leigh's changes of base-station side RTCM3 message transport over USB to publish as a ROS2 topic. His changes are evident in his fork.
3. implement a parameter server for the different params.