Chapter 5 PX4-GPS Analysis
In the previous chapter, we analyzed the sensor MPU6000. The protocol supported by MPU6000 is SPI. In this chapter, we will analyze GPS, which uses serial communication. Here we focus on explaining the parsing process of UBLOX, and the parsing instructions of the serial port will be attached. After this chapter is over, if you are interested, you can try RTK data analysis. I mentioned RTK earlier.
First of all, we still find the startup code of GPS. The startup of GPS is directly in the RCS file.
. Here we go back to the driver layer
Find the file gps.cpp file to find the entry function
. Here it is explained that the gps driver of PX4 can support 2 sets of gps
It can be seen from here. First of all, let's look at device_name, this parameter is
The h files of the driver layer are all in
Under contents. Obviously, this is actually the name of the serial port. Now that we are here, let's talk about how "/dev/ttys3" is registered to the serial port.
Remember the SPI driver. Here, our main control is the V2 board, so the supported processor is stm32, so we will go to the stm32 driver to find it. If you know about the stm32 library, you will know that the serial port is either usart or serial. Here we will You can know that the file is stm32_serial.c, and the serial port initialization program is up_serialinit. As for why, you can trace it and find that this function is in
Called in the file, stm32 belongs to arm not avr,
Then follow it step by step and you can find the ultimate source. Go back to the initial piece of code in the stm32_serial.c file. You can see that the NSH background control serial port is registered with serial port 7
CONSOLE_UART=7 Oh, you can track it here, compare the deconfig file, those define definitions can be found in the deconfig file. And serial port 7 is also registered for DMA control , the next for will initialize the serial port one by one and
see that it is not copied at first,
then the x value is changed and then registered, just now we found that the GPS is ttys3, so let's check uart_devs[ 2], the logic here should not be difficult to understand! It is found that the serial port 3 is registered. Let's take a look at the GPS interface of the hardware
It happens to be serial port 3, so it corresponds to it now. The registration of the serial port is finished.
Here we go directly to the start function, the parameters here are
not difficult to understand. Then it is to generate the driver firstly in the new way, and then perform the init function after success. The init function
here is the init of gps, understand this by yourself, so this initialization is also in this file, find the init function and see the serial port The task
also goes to the middle function
to find the task_main function. The first is to open the serial port
. The _port here is assigned a value when it is new. Then it is to subscribe and initialize the data dump, and then enter the while to execute. First, the _fake_gps parameter will be judged. This is virtual data, and it will definitely not be used in real situations. So let's look at else. Here is a case statement to select a module. We only talk about ublox today, so we see that here is also new GPSDriverUBX. Then the detection configuration
is mainly the baud rate. The configure here is a virtual function. We use ublox, so of course we went to ubx.cpp to find it.
The functions here are not difficult, but compared with the manual, the processing mechanism here is worth learning, to find the baud rate of ublox by polling, and to configure ublox.
The next step is to reset the data, and then to receive the data . Find the receive function of ublox
, and enter the read data from the serial port
. The data read is temporarily stored in buf. You may wish to look for the read function here. This is a callback function that is overloaded into gps.cpp.
You can also see the case statement for reading data.
There is a function for interrupting the reading of serial port data. Understand for yourself.
Then enter the data analysis stage. Here we post the protocol format of ublox.
So it can be seen from here that the frame header starts with 0xb5, 0x62. The first case is to judge whether it is 0xb5 and whether it is in rtcm format .
After the frame header is completed, it needs to be verified. It starts from the third data. ublox uses the checksum and
then gets the length of 2 data.
The _rx_payload_length here is the length. Then start to parse the relevant data, here we only parse the SVINFO information
See what data is received by seeing the _rx_msg received before. First, let's take a look at ublox's SFINFO data frame,
Entering the analytical function, you can see the analysis of these data. I will not explain too much here. It is easy to read as long as you refer to the manual. This frame of data is mainly satellite altitude angle and signal-to-noise ratio.
After parsing the data, the checksum must be continued. From the data frame of ublox, it can be seen that the checksum occupies two characters.
Of course, after the verification is completed, other data must be parsed . There are NAV_PVT, NAV_POSLLH, etc. in these data frames. You can see the latitude, longitude, altitude, and ecef coordinates of these data frames. There is no need to say these parsing.
Even if all the data is received here, of course, it has to be released to the required mechanism for customization.