Been working on a new ublox dgnss driver for > Gen 9 Ublox devices such as the ZED-F9P. I was thinking of publishing it. Have never published a ros package before.
I built this one as the previous ublox ubx driver was built using the previous standards which are being deprecated. It also did not have the high precision output messages I was looking for. They advised that the package was no longer being actively maintained.
The package I’ve created works against Galactic (and had previously run it against Foxy).
So I’ve got a few questions:
1/ is this package of interest to others?
2/ what are the steps to create a new package?
3/ are others interested in helping to maintain this if I do publish it?
4/ how may I get some input on whether this is at a sufficient quality to be published for others to use?
5/ can anyone help review the package structure and/or give recommendations on its set up?
It was the KumarRobotics package that I was looking at before deciding to write this. I’m using ubx-cfg-valset & cfg-val-valget commands available in gen 9 devices. As well, added the high precision messages that I was after. UBX is of course a binary interface. I decided also not to go down the USB Serial interface route but instead to use libusb-1.0. All messages received back in callbacks from the GPS device are stored in a queue with a timestamp. Another timer handles that queue and publishing. Would love some feedback on the async nature. I really did not know how to handle futures in a c++ ros2 node
This is a general no-nonsense “here’s what to do” guide. Its by far not exhaustive of all the ways to release software, but it is the most straight forward way without getting bogged down too much into what exactly is going on in the background.
I recently worked with ublox-F9R module and didn’t find a great ROS(1) package for it. I wanted to receive GPS data, fix-type (other NMEA stuff) and also send back RTCM corrections. I ended up writing the driver myself. An attempt to answer your specific questions -
I think this would be of immense use to other people IF maintained and documented properly.
As @smac and others may have offered, I think you’ll definitely get help towards this.
I’ll do my best to contribute with fixes as and when I can. Again, in my view participation by community at large would probably depend on how much traction there already is. Chicken and eggs.
For what it is worth, I did the port of GitHub - KumarRobotics/ublox: A driver for ublox gps to ROS 2. Saying that there is little “movement” in that driver is a bit disingenuous; other than a PR from myself, there are no currently open PRs against the foxy-devel branch in that repository.
That said, I haven’t had time to do any additional development on it. I also don’t have any hardware other than the Ublox C94-M8T.
Overall, I would generally prefer to have one well supported driver rather than several half-implemented ones. From that perspective, it would make much more sense to me to add the changes for the new drivers into the KumarRobotics one.
Just to pile on here - the way that the KumarRobotics/ublox driver was written it should be relatively straight forward to add new generations of ublox devices to it. I remember adding the M8T and M8U devices back in the day, and then watching others add the “new” ZED F9 series to it as well.
I’d recommend trying to first add whatever you think is missing to that package as I think it would be easier for everyone to have one really well maintained package.
When I looked at the code, I couldn’t easily work out how to add new message types. I also noticed that the code wasn’t using ubx-cfg-valget or ubx-cfg-valset but was using the deprecated cfg messages. It appears UBLOX with UBX has taken a different approach with generation 9 devices. Generation 10, I assume will use the new.
So I decided to write a new driver, for my purposes, that also didn’t use a serial interface, but used libusb-1.0 with an async interface.
It’s time consuming adding all the configuration variables and messages. I’ve not done the RTCM ones as yet. The driver that I’ve written works well. Can also unplug it, go to u-center, change settings, and then replug it in. It picks up the USB hot plug attach event and resends the local configuration to ram in the gps device.
Whilst I agree basically with your sentiment, I think these newer devices have a different interfacing style. The generation 9 devices have deprecated the configuration interface for the generation 8 devices, the ones coming will most likely not work with generation 8 and below configuration commands. Hence why I’ve focused purely on generation 9, configuration interfacing, using ubx-cfg-valget and ubx-cfg-valset, with an emphasis on ubx messages and high precision.
I’ve not focused on the base station modes and RTCM correction message publishing & receiving as yet. My current setup is using the NTRIP client on android and publishing via Bluetooth to a receiver connected on uart2. I followed the instructions from SparkFun as I bought their device.
It would be a simpler setup if an NTRIP caster was in the driver with ROS2 messages. In Australia we now have access to a regional set of CORS https://www.auscors.ga.gov.au/status/ hence I didn’t need to establish my own base reference station. Ideally any driver should find the closest CORS and use that.
My setup involved getting corrections from a paid castor service provider (since rtk2go doesn’t provide coverage and availability guarantees).
I had a tough time with RTCM at first, it was my first time working with RTK-GPS so added terms like GGA/NMEA/RTCM2-3 on top of ublox driver dev. was a bit confusing at first. Engineering itself turned out to be quite smooth once I grasped these concepts.
What I can tell you is that it was an off-road application with speeds < 30 km/hr. This unfortunately renders ublox-f9r calibration and usage limited so I didn’t end up using their sensor fusion after all. As for KF/EKF - we’ll probably be using robot_localization as starting point and take it further from there. What are you looking to build if I may ask?
Just to clarify here they (at the link you provided) said it wasnt being actively developed.
It is being actively maintained though and the maintainer even explicitly asks you to make a PR to add this functionality if you want it.
Seems like the perfect place to contribute for anyone who wants to work with some ublox devices.
The message type generation for that ublox package is difficult to understand at first but it makes a lot of sense once you do. I’d recommend taking another stab at it since the structure that’s setup there is great for adding new messages and firmware versions.
The package works great for Generation 8 and below devices. However Ublox has moved to a different configuration mechanism for later devices. That’s what I’ve focused on and the high precision aspects
