Terms of service
Brokking
 
 
.net
Let's keep it simple
 

 
   Home
   TL-blog
   Projects
 

   Articles
 

   Donation
             
 
 

 
Brokking.net - Video: YMFC-32| GPS hold part 1| The STM32 - Arduino DIY autonomous drone

YMFC-32| GPS hold part 1| The STM32 - Arduino DIY autonomous drone

This page contains the full script that I used for making this video.

Yes, after many videos we can finally start working on the GPS hold function. This is the most satisfying moment when you are programming your own quadcopter. That moment when you can put the transmitter down and the quadcopter flies fully autonomous with your own code is absolutely amazing.

From that moment on you can really start to optimize the code and add other features to it.

But first, let's have a look at how it works and what is needed to implement the GPS-hold function in the YMFC-32 code.

As always let's start with the basics. A GPS system overlays a virtual grid on the earth's surface. With two coordinates you can mark a 2 dimensional position anywhere on earth. These are the so called latitude and longitude.

In space several GPS satellites are orbiting the earth. These satellites output a perfectly time synchronized signal.

A GPS module has the ability to receive these signals and based on the traveled time of the signals it can calculate the distance between the receiver and the satellites. When there are four or more satellites in view the GPS module uses these distances and the position of the satellites in the sky to calculate the latitude and longitude.

It can calculate a lot more but for now we will only focus on the latitude and longitude.

Ok, now let's have a look at the hardware. If you use the same components as I do you already have the GPS module powered as it is part of the compass. In contrast to the compass, which is using I2C, the GPS module sends its data via the serial communication protocol to the STM32.

If we have a quick look inside we can see the compass over here and the GPS module that outputs the GPS data can be found here.

!!WARNING!!

https://www.u-blox.com/en/counterfeit-products-and-u-blox-brand-misuse

Ok, very important. Please be aware that there are counterfeit products on the market that use the u-blox logo as a selling argument. I have quite some experience with real u-blox modules and I know what they are capable off. Even this older LEA-6S module gives very good results.

This is the module that I used for my own project, and as you can see it works very well.

So please be aware that despite the fact that it's labeled u-blox you could be buying a counterfeit product that will result is poor GPS hold performance.

The module that I'm currently using on two of my test quads gives me the expected result. So I will post the link to this specific module on my website. But please be aware that I have no influence whatsoever on the product behind the link. So I cannot guarantee that this is or will stay a real u-blox product.

Ok, back to the hardware. When I connect the serial output of the GPS module to a FTDI programmer, or any other serial to USB interface, I can read the serial data stream with the u-center software from u-blox that you can download for free.

If you don't know the function of the individual wires of the GPS module you can have a look inside and check the markings on the printed circuit board.

Select the correct com port and a baud rate of 9600 bauds per second and click connect. At startup this GPS module outputs it's data at 9600 bauds per second.

When I power the GPS-module it will start to detect satellite signals. This may take quite some time, especially when you are indoors. The backup battery is completely drained when you receive a new GPS module and it needs to create a new dataset for tracking the various satellite signals.

If the GPS module cannot find any satellites you might need to take it outside.

The progress of the GPS module can be followed in the main screen of the u-center software.

After a while you can see that satellites are taking their place in this virtual sky and the various data fields are filled with numbers.

All-in-all an enormous amount of usable data.

For the YMFC-32 the most important values are these two lines: latitude and longitude. These two parameters are the 2 dimensional location indicators that we will use for the GPS-hold function.

And yes, there are a lot of parameters that we can use. But as already explained I want to keep the code as simple as possible and only focus on the essential data.

Now let's have a look at the raw data output of the GPS module. The easiest way to do this is by selecting the text console. Now you can see the raw data output that is received via the serial data line.

All the data that you see over here is the data that is calculated and filtered from these data blocks. Every second the GPS module outputs one block of data. And as you can see it's humanly readable.

I can also print this data to the serial monitor of the Arduino IDE as you can see here.

Now, let's have a look at a single data block.

Ok, you don't have to be a rocket scientist to detect some sort of pattern.

For example, every line starts with a dollar sign followed by a code that indicates the specific data in that line. This is the so called NMEA protocol that is in use for quit some years now.

Now I could talk about all the different fields and what they mean. But I rather link you to this u-blox document. It explains all the various fields, what they mean and how to use them. I will link it in the description so you can have a look for yourself.

For now we will only focus on two lines, the Global positioning system fix data or GGA. And the GNSS DOP and Active Satellites or GSA.

The GGA line holds the latitude and longitude information and the number of satellites that are used to calculate the information.

The GSA line holds the fix type. As you can see we can have a 2 dimensional fix and a 3 dimensional fix. Where a 3 dimensional fix is preferred. This is a good indicator of the quality of the latitude and longitude values.

Ok, now that we know what information we need it is time to connect the GPS module to the STM32. As you can see on this schematic the transmit and receive wires are connected to pin A2 and A3 of the STM32.

As already explained, if you don't know the function of the individual wires you can have a look inside and check the markings on the printed circuit board. Never solder the wires blindly as it can ruin the STM32 or the GPS module.

And this was the moment where I decided to switch to one PPM signal instead of 6 individual PWM signals. As you can see we also have to connect the output of the telemetry transceiver and the analog input from the batteries. Using PPM really simplifies the whole hardware setup.

Most FlySky transmitters and receivers already support this PPM signal. Like this IA6B for example.

However, If you use the FlySky T6 with the R6B receiver like I do you need to convert the 6 PWM signals into a single PPM signal. This can easily be done with an Arduino pro mini and a small program.

I made this simple PWM to PPM converter for my own quadcopter. Detailed information and the code for the Arduino pro mini can be found on my website.

Another thing that I did is modifying the transmitter so it has more individual positions on one channel. This will make it possible to select the individual functions like altitude hold, gps hold and heading lock. I made a video about it that I will link in the description.

Ok, back to the GPS. Now that we know how to connect the GPS and what parameters are needed we can start with the first part of the program.

And that is the setup part. At startup the GPS module outputs one block of data every second at 9600 baud per second. So the refresh rate of the latitude and longitude are 1Hz or once per second.

This is way to slow for the YMFC-32 to hold its position. Luckily the GPS module is able to output data at a higher refresh rate up to 10 times per second. However, for the YMFC-32 we will use a data output of 5Hz or 5 times per second.

Another thing that I will change is the baud rate of the serial data transfer. Instead of the normal 9600 bauds per second the YMFC-32 will use 57.6 kilo bauds per second.

To offload the microcontroller I will also reduce the number of lines that are send by the GPS module. Depending on the number of satellites in view a number of GSV messages are send by the GPS module. These are not needed for the YMFC-32 flight controller and can be disabled.

To do all of this we need to send some information to the GPS module. If the module accepts the u-blox protocol the following lines will do the trick.

This line will disable the GSV messages that are not needed.

This line will increase the output refresh rate to 5Hz.

Finally the baud rate can be changed to 57.6kbs with this line. To get the communication going we also need to change the baud rate of the STM32.

To see if it will work for your module you need to test it with the setup program first. When I perform a GPS test it will first output the data with the startup settings.

After that it will make the changes as described before and output the data again. The output should now be 5 times per second and without the GSV lines. So make sure to do this test to check if your GPS module reacts correctly to the u-blox protocol.

And that brings us to the end of this first videos about the GPS hold function of the YMFC-32. In the next video I will explain the code that makes the GPS hold function possible.

Thank you for watching and see you next time.