add the quectel parser

[ChuHongBin]

Desription

• add the parser for Quectel module, including: Quectel LG290P, Quectel LC29HCA and Quectel LC29HDA etc.
• Supported function list:
  • NMEA format parsing: NMEA0183 messages and PQTM messages.
  • Reciever work mode: Rover mode and Base station mode.
• The framework for parsing has been built and can be expanded later based on demand.

This is my first time submitting a request and I'm looking forward to some good news.

Attached is the log of my test.
base_sta_mode.log
rover_mode.log

[NearDuckyu]

Hi, @ChuHongBin.
I'm currently trying to use the Quectel LC29HC EA model with rover mode.

In my knowledge, the module supports the NMEA message format with rover mode.
Therefore, It has to be work properly while I'm using with the NMEA protocol setup(PX4 parameter setup)

However, I'm experiencing the severe oscillation on manuever while utilizing them.
Have you experienced the similar situation? Or else, with your commit, does the drone flies without oscillation?

Any support or tips willl helpful. Thanks!!

[ChuHongBin]

Hi @NearDuckyu

We can discuss GNSS-related topics. I don't know much about drones.

You could first confirm whether the GNSS data can output a stable position in a static state and ensure GNSS is effective.

[NearDuckyu]

Thank you for your reply @ChuHongBin,
May I ask you about the Quectel GNSS engine?

Is there any chance that a time delay occurs while NMEA data is published from the module?
I'd like to try setting up the parameter (namely, EKF2_GPS_DELAY) which deals with GNSS-IMU time delay in the PX4 EKF2 module.

Since oscillation occurred when a single position target was set, I suspect that GNSS data latency may be the cause of this symptom.
(FYI: The same platform with a UBLOX F9P GNSS made a super clear flight, which means the controller is not the issue)

In fact, I've already compared the Quectel LC29H EA module and the Ublox F9P module (Holybro H-RTK F9P ultralight) simultaneously.
The accuracy and precision of these two modules are mostly the same (in terms of position and velocity), and the timestamp difference shows only 25ms (I've calculated the average of the difference between the flight controller timestamp and the UTC time from the satellite of each GNSS module).

Moreover, I've already tested the EKF2_GPS_DELAY parameter change from the default 110ms to 150ms. It seems to show a slight improvement, though I'm not sure if it actually does. (Due to the measurement rate difference between GNSS-IMU, correlation between GNSS velocity data and IMU linear acceleration data could not be calculated properly)

I'm quite stuck these days... If you have any suggestions, let me know.
If you want to examine the log of the flight, I can provide you with the ULG file (PX4 log file).

[NearDuckyu]

I realize now that my question wasn't very relevant to this PR. When I get a chance, I'd like to try out the code you've posted here.
Could you let me know what modifications need to be made to the PX4 firmware itself, aside from fetching the driver from that branch?
I think several files needs to be changed in the https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/gps.
As follows:

• enum class of gps.cpp file
• Kconfig
• paramter

If any other changes needed, let me know/

[ChuHongBin]

Hi @NearDuckyu

This PR is a parser for Quectel NMEA. It takes serial data as input and outputs parsed GNSS data. You may need to modify the end-of-frame flag.

Sorry, I couldn't help you with the fusion part. I hope you can solve this problem as soon as possible.

[NearDuckyu]

I see... Thank you anyway.

I hope you have a nice flight test and merge this PR as soon as possible.