PX4 HoverGames starter examples

Some simple examples have been created by the HoverGames team. They are available for download on our NXP HoverGames GitHub in the Tutorials repository.

You can place these examples in the src/examples folder of the PX4 firmware and edit the file boards/nxp/fmuk66-v3/default.cmake .

These HoverGames PX4 starter examples are complemented with step by step tutorials:

PX4 starter examples

The PX4 firmware already includes a few example applications, some of which are similar to the examples created for HoverGames. They can be found under the src/examples folder and should be included by default on most builds.

PX4 Developer Guide

The PX4 Developer Guide also includes a "getting started" page for writing your first PX4 module. This is also based on some of these examples. It explains some of the basics of creating a new module, building your new code and interacting with it from the console. It also gives an introduction to using uORB, the middleware layer that allows you to communicate with other modules.

It is strongly recommended that you start with these examples and then slowly start exploring other parts of the software. The is a good place to get information and you can always ask your questions on the .

Example code for add-on hardware

Example software for add-on components used in the HoverGames is available on their own pages. You can find them by scrolling down in the menu on the left. They are listed under "Add-On Hardware".

In the last lab, we learned what uORB and publish/subscribe protocols were. Then, we wrote a bit of code that allowed us to print out some gyro measurements to the MavLink console! The program we wrote was only half of the equation, though, as we only used the "subscribe" portion of uORB. In this lab, we will publish some data to a topic that will control the RGB LED on the RDDRONE-FMUK66. The topic we are publishing to is subscribed to by an internal PX4 program that handles LED control.

HG_led

To start, let's get the license for this source code out of the way:

Includes

As in the last lab, we include our headers to the source code. The headers will be nearly the same, except we will change the uORB topic from sensor_gyro to led_control.

Main function

As done in the previous lab we create our main function and export it.

Here we export our hg_led_main function. Remember, your main function should be called <filename>_main. ThePX4_INFO() function to show text indicating that the program has started.

Setup

A structure is created that we can save LED control data to. This structure will be used to publish the data to the led_control uORB topic.

First step is to create the structure itself. Here, we created an led_control_s structure and named it led_control. Then, we call memset() to fill the structure we created with zeros. We do this because the memory we allocate could have uninitialized random data in it, and in a safety critical platform such as a drone, we don't want to inadvertently send bad data if for some reason our data allocation code fails. The last line of code creates a uORB topic advertisement variable that allows us to publish to the led_control topic.

Setting LED control data

Once the initial setup is done, we can now start filling our led_control structure with data.

Colors, modes, and priorities can be set using the parameters as described in the link above. In this example, we are going to tell the LED to blink 10 times at max priority with the color green. Here's how to do that:

These parameters are easily set simply by referring to the parameter and giving it a value.

• num_blinks : We set the number of blinks to 10. You can make this whatever number you want, but don't make it too large or your LED will blink for a very long time!

• priority : Make our LED app max priority so that something else can't override it by setting LED_CONTROL_MAX_PRIORITY . Note that there is are priority levels for a reason. Think carefully about your application as not everything should be max priority.

Publishing our LED data

In order to tell the LED controller to use the parameters we set, we have to send a uORB message with the structure we created. We will use the orb_publish() function to do so:

And there we have it! Once this command is run, the uORB message with our data will be sent, and our LEDs will start blinking green. To close out the program, let's print something to the MavLink console that shows our program is done running.

Conclusion

We have now learned how to both subscribe and publish uORB messages in PX4. Next, we will create our own program that uses our new found knowledge to manipulate the LED on the RDDRONE-FMUK66.

You've made it to the last example lab on this gitbook! In this lab, we will learn how to create our own app that harnesses both the publish and subscribe protocols in uORB.

Objective

In this lab, we won't be guiding you through creating this program, but we will give instructions on how to complete it. Don't worry though, if you get stuck there is a solution file that you can reference to learn how to complete this lab.

The objective of this lab is to harness the data published by the magnetometer (compass) on the FMU and control the RGB LED when you're facing north. You should also print a message to the Mavlink console that you're facing north along with the magnetometer data.

Tips

Demo

Here's a small demo of what the output should look like. You should have some sort of logging in the Mavlink console as well as the LED flashing red when you're facing north.

Solution

If you need the solution to figure it out, or want to view some of the other tutorial files, go to this link:

Extra Credit!

See if you can make the LED blink a different color for North, South, East, and West!

Contact

Thanks for following these tutorials. If you would like to see more, or have feedback or corrections please email us at HoverGames@nxp.com or on

Uploading firmware to the board

You're probably wondering "now how do I upload this new firmware to my board"? There are a couple of ways. We will use the easiest method, using the on board bootloader and QGroundControl. Note: This assumes your FMU already has a bootloader loaded from the section Programming FMUK66 for first use. Assuming that the bootloader is already in place, loading code is a simple process, so lets go over that next.

Preparing the FMU

Start with the FMUK66 powered off, and disconnected from USB on your computer. Run QGroundControl and navigate to the Firmware tab as shown below:

Bootloader settings for custom firmware

Once you've navigated to this screen, follow the instructions and plug the FMU into your computer using the provided microUSB cable. You should see a prompt asking you which firmware you want to upload.

You'll want to check the "Advanced settings" box and select "Custom firmware file..." from the dropdown box as shown in the image below. Click OK at the top right to go to the next step.

Selecting your .px4 file and flashing

Once you click OK, a dialog to select your file will appear. You'll need to navigate to your PX4 firmware directory and go to Firmware/build/nxp_fmuk66-v3_default/. Inside that folder you'll find an nxp_fmuk66-v3_default.px4 file. Select this file to upload the firmware to your board.

If the firmware upgrade successfully finished, you should see a message in the log that says "Upgrade complete." in yellow. If you didn't get that message, try again, check to see that the code did in fact complete compiling without errors.

Assuming you did get the "Upgrade complete." message, then you can continue in this lab guide!

Running our custom PX4 application

Now that we have built our PX4 application into the firmware, and loaded it onto the FMU hardware, it's time to run it. After flashing your FMU it is recommended to hard reset or power-cycle the board. Wait for QGroundControl to reconnect with your board over USB, and then open up the Mavlink console as shown below.

The console

The terminal shell or console gives you command line access to the software running on the FMU.

It should be noted that the console is actually available through several interfaces. A hardware "root console" is available when using the FMU debugger interface connected to a FTDI-USB-UART cable. This exposes a serial UART directly on the FMU itself. The root console is particularly helpful since it is initialized on power-up and can specifically show what is happening immediately on power-up, before something like the the USB interface is initialized and working.

Note: Since the FTDI-USB-UART cable is a hardware solution that converts the FMU debugger UART interface to USB it doesn't require any FMU software. This is different than the FMU USB port itself - which makes use of a PX4 software driver in order to function.

A console is also available through a direct USB connection or over a telemetry radio to a program such as QGroundControl. (and there are even other methods, such as SSH over an Ethernet connection). With any of these connections you can run PX4/NuttX commands in the Mavlink console. To see a list of commands you can run, type "?" into the console input field.

Finding your new LAB3 hg_led program

With any of these connections discussed above you can run PX4/NuttX commands in the console program. In QGroundControl this is known as the Mavlink Console. As with other operating systems such as Linux, commands are actually just programs that can be run on the command line or called from other programs or scripts. To see a list of PX4 commands you can run, type "?" into the console input field.

Running your program

At the top left, you can see our new program, hg_led! Go ahead and run it by typing its name in the console and pressing <enter> to see your hg_led program in action!

The main multicolor LED is the one we are controlling in the program, the other red and orange LEDs are other indicators. Fun! Next, we will go over a more advanced example and you can try coding it yourself!

Building our code to run on the FMU

Now that we have prepared two applications for use on our drone, we want to run them in order to confirm that they work.

We can test and debug code like this in a few different ways:

In this section, we will go through some of the PX4 example code and explain how it works, and then write our own PX4 app to run on the RDDRONE-FMUK66. As a prerequisite, you should download the PX4 examples outlined in the , and then come back to this section.

Getting Started

Lets review uORB, a messaging protocol that will be used in many of the examples.