Proxy driver for GPS modules supported by the PX4 firmware

[hsteinhaus]

This PR adds a very simple proxy driver for GNSS modules already supported PX4/Firmware. The driver could be enabled via GPS_TYPE parameter. The driver is useful e.g. for UAVCAN GNSS receivers, but not limited to them.

Note: this driver uses the same architectural approach as AP_Compass_PX4 and AP_Baro_PX4 do. In contrast to them, it uses a direct orb_subscribe() instead of a device file interfaces (there is no such thing in the current PX4 Firmware for GNSS devices).

[tridge]

Thanks Holger!
The code says "it is not possible to autodetect it". Can we just try to subscribe to the orb handle and then try asking for status information of the GPS? We could put that in a _detect() function like the other GPS drivers have.
We'll also need a way for users to auto-start the PX4 GPS driver. Maybe it is time that we support a init.d/rc.user script that users can put in /fs/microsd/APM? If it exists it would be run at startup just before ardupilot starts.

[hsteinhaus]

Hi tridge,

the problem with autodetection is that the parallel probing and initialization from APM would interfere with the PX4 driver, that is already running and talking with the GPS - there is no locking AFAIK. We would have to suspend/delay the probing for APM-driven GPS modules until we are sure that there is no PX4 GPS connected. Unfortunately we don't get any negative acknowledge if no PX4 GPS is connecte either.

The other aspect is that we don't have to care about different hardware here - this is transparently handled by the PX4 driver (which in fact does an autodetection again).

Regarding startup: for the case that the GPS is interfaced by UAVCAN, there is no special startup code needed at all, except the one that starts the UAVCAN stack itself (executable "uavcan"). This is BTW handled by my PR #1323 . For other GPS modules, we would indeed have to add a line to rc.APM. The rc.user would be a very nice way to do that IMHO.

[tridge]

hi Holger, I've pushed this to master with some fixes. The main fixes were to fix the build for non-PX4 boards, plus to add PX4EXPERIMENTAL to the drop down list in the GCS so users know how to select this option.
I'm actually not sure this should stay in the code long term though. It means a uBlox connected over CAN is going to behave differently from the same GPS connected over a UART. That seems wrong to me. We have a bunch of auto-config code in ArduPilot for uBlox that we don't want to lose just because we are on CAN. What I'd like to see in future is a vitual UART over UAVCAN so we have the choice of using a GPS (or other device) over CANBUS with our AP_HAL UART interface.
btw, where do I get one of these UAVCAN GPS modules? (and for that matter a mag and baro)
Craig is going to send me some UAVCAN ESCs, but I'd like the other bits too
Thanks again for your patience with the whole UAVCAN effort, I know we've been very slow accepting it, but we'll get there in the end.
Cheers, Tridge

[tridge]

I've now ordered one of the GPS+mag+baro UAVCAN combos from nicadrone. That should get me started!

[hsteinhaus]

Hi tridge,

I think you should not compare the Zubax module to a "naked" uBlox6 or so. It uses a completely different approach - I think the best is to just see it as a smart position provider, not as a GPS module at all.

It contains its own STM32F105, running it's own OS and it's own uBlox driver. This driver handles all initialization, configuration and data transfer. There is absolutely no need for an application running on Pixhawk even to know that the module is UBlox-based. Offering a virtual port over UAVCAN is probably possible, but I think doing so would give up 90% advantages of this module. You would increase load on Pixhawk and, even worse, on UAVCAN as well, plus introducing addtional delays.

BTW: please watch for my latest patches in PX4/master for making the compass work with APM. The drivers contained in diydrones/PX4Firmware does not support read() on the device file yet and hence do not work for APM. The same applies for the baro, but as APM does not support more than one baro yet, this is probably not that interesting.

[tridge]

The fact that it uses a completely different approach and that it doesn't involve a driver that we have control of is what makes it unattractive to me. The "increase load" argument makes no sense - the load in parsing GPS msgs is absolutely trivial, even on the APM2.
Basically I do not trust someone else to properly program a uBlox. We have had a lot of very subtle things we have needed to do with the uBlox driver to get the most out of it. A "don't look behind the curtain its all OK" approach makes me want to run a hundred miles from this thing.
Does whoever wrote the driver on that stm32 know what they are doing? How do we fix bugs? How do we ensure it does exactly what we want it to do? How do I query or disable SBAS? How do I change the elevation mask? How do I query the signal to noise ratio? etc etc etc. I have spent weeks looking very closely at individual packets in the uBlox protocol and thinking very carefully about how we use it. I don't want to throw all that away.
To me the only advantage is the bus technology. If we are forced to give up driver control in order to use CANBUS then I would seriously think about not using CANBUS at all.

[hsteinhaus]

Hi tridge,

it's no closed-source black box, the software just runs on a different (additional) MCU. And as far as I know the author, he will probably be happy to accept contributions to fix potential problems or to add missing features: https://github.com/Zubax/zubax_gnss

After working with the module and UAVCAN in general for some weeks now, I have the impression that we don't have to give up anything. But it is well possible that we have to spend more effort to design clean interfaces and to agree them.