PX4 / PX4-GPSDrivers

Platform independent GPS drivers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Disabling UBX configuration

jkutia opened this issue · comments

commented

Hi all,
In order to share a common GNSS module (F9P) between both payload and drone, it would be nice to have an option to disable the automatic module configuration that takes place in the drivers which would otherwise disrupt the payload operation.
It is already possible to simply use the NMEA interface instead, but this introduces limitations with position precision, RTK heading use etc.
Cheers

Could they use separate ports and GPSDrivers could be less pointed about configuring ports it doesn't actually use?

commented

Thanks for the quick reply!
Yes, if GPSDrivers were to only configure the nominated output port this would avoid interfering with the payload port. Our intended setup is USB for payload and UART1 TX to FCU. UART2 is configured by the payload already for RTCM input / moving base RTCM output.
I noticed there are also several other rate, timeref, dynamic model parameters which are set by the driver. Ideally it would be great if all these could be disabled by a PX4 config option to let the payload govern the configuration; however I understand the potential for misconfiguration by the user (probably belongs under the developer param subset).

Cheers

commented

As a proof of concept, I have added in the following lines to ubx.cpp which yielded a successful GPS startup.

int GPSDriverUBX::configure(unsigned &baudrate, const GPSConfig &config) { _configured = true; _use_nav_pvt = true; setBaudrate(921600); return 0;

Ultimately, an ideal case would be to send both position and RTK heading information over a single UART link from the payload. As far as I'm aware, the EKF/PX4 currently supports a max of two GPS units, so this would leave the second GPS interface free as a spare for a redundant unit on the drone in the event of some payload failure.

I have seen a previous pull request utilizing the MAVLink GPS_INPUT message which would do the job, except there are several fields missing when compared against the uORB sensor_gps message.
Alternatively, the RELPOSNED message from the rover could be sent on the same UART interface as the moving base and the driver could take the heading info but discard the relative position info.