Important must read information

The HoverGames drone development kit (the “KIT”) is for experienced developers above the age of 18 only. CAREFULLY read all information and instructions on this page before assembly and operation of the device.

• NXP provides no software for this circuit board. You are using open source software and programming the flight controller yourself.

• Advanced mechanical and flying skills are a prerequisite for assembling and operating this device. If you are in doubt of your assembly or piloting skills, do not assemble or fly.

• It is your responsibility to inform yourself of and follow all current federal, state, provincial, district and any local laws regarding the use of the drone in the area where you plan to operate it.

• If you choose to modify your drone to function in any autonomous manner, you must ensure that you obtain any required certifications, waivers and licenses and comply fully with local, national and international laws that will apply. It is your responsibility to know what is legal operation.

• It is highly recommended that you have proper liability insurance coverage at all times.

• Your first priority must be the safety of people. Therefore, always keep the drone at a safe distance from people (including yourself!) and follow the provided safety instructions.

Environmental considerations

• Always fly at locations that are clear of buildings and other obstacles.

• DO NOT fly above or near people or crowds.

• Avoid flying at altitudes above 400 feet (120 m).

• Be certain you are legally allowed to fly in the location and at the altitude you are planning.

• Fly in moderate weather conditions with temperatures between 32 to 104 °F (0 to 40 °C).

• Check all applicable NOTAM and Flight Restrictions in your area. If you don't know what this means, study and educate yourself on the local area aviation rules first. You may need to call and ask a nearby flight control tower before flying.

Pre-flight checklist

These are some very important things to check before every flight:

• Ensure you have programmed a motor "kill switch" on the RC transmitter and that it is tested and functioning. How to do this will be explained in this GitBook as well.

• Ensure the remote controller and aircraft batteries are fully charged.

• Ensure the propellers are in good condition and securely tightened.

• Ensure there is nothing obstructing the motors.

• Be sure to calibrate the compass at every new flight location or if the app prompts you.

• Check that the camera lens is clean and free of stains, in case of FPV (First Person View) flight.

Also see the page about safety. Never attach propellers until ready to fly.

Operation

• Stay away from the rotating propellers and motors.

• Maintain line of sight of your aircraft at all times.

• DO NOT answer incoming telephone calls during flight.

• DO NOT fly under the influence of alcohol or drugs.

• In the case of a "Low Battery Warning", land the aircraft as soon as possible at a safe location.

• After landing, first disarm the drone, unplug the flight battery, then turn off the remote controller.

Insurance

There is also the possibility to insure yourself. It is your own responsibility to find out whether this is required in your location.

• Germany - Pages like DMO offer insurances especially created for drones.

• Americas - AMA and MAAC are two hobby associations that offer insurance for hobby drones (non-commercial use). There are insurers for other usage types.

• Other countries - Contact local drone/hobby flight associations, they should be aware of the best available options.

Documentation

This GitBook is by no means a complete reference guide for the HoverGames drone development platform or other NXP mobile robotics products. Also be aware that this GitBook is continuously being improved and expanded. Information may change without notice and some sections may be incomplete or contain errors. If you find an error or have a suggestion, any feedback is very welcome.

DISCLAIMER OF LIABILITY

NXP Semiconductors provides the KIT “as is” and “as available” for your use, without warranty of any kind, either express or implied, including all implied warranties of merchantability, and fitness for a particular purpose. NXP provides no software for this KIT.

In no case shall NXP Semiconductors be liable for any direct, indirect, punitive, special, or consequential damages AND PERSONAL INJURIES, INCLUDING THAT TO LIFE AND HEALTH, RESULTING FROM THE ASSEMBLY AND OPERATION OF THE KIT.

YOU ASSUME FULL AND UNLIMITED RESPONSIBILITY FOR ALL APPLICATIONS AND USES of the KIT, INCLUDING liability for damages to property and persons from the DEVICE.

QGroundControl

• Download QGroundControl from QGroundControl.com (Stable release, recommended)

• Download QGroundControl from QGroundControl.com (Daily build / development release)

QGroundControl is the ground control software (GCS) of choice within the Dronecode platform. It can be used to flash, configure and control any FMU that runs PX4 or a MAVLink compatible flight stack. It is recommended to use the latest stable release and update regularly when new releases become available.

PX4 Autopilot builds for RDDRONE-FMUK66(E)

(Note: NXP does not provide precompiled code. Binaries are available through the courtesy of PX4)

Check below which file(s) you should download.

• Download nxp_fmuk66-v3_default.px4 (stable build for Rev. C/D, use with QGC)

• Download nxp_fmuk66-e_default.px4 (stable, build for Rev. E, use with QGC)

• Download nxp_fmuk66-v3_default.bin (stable build for Rev. C/D, use with J-Link)

• Download nxp_fmuk66-e_default.bin (stable build for Rev. E, use with J-Link)

• Download nxp_fmuk66-v3_default.elf (stable build for Rev. C/D, use for debugging)

• Download nxp_fmuk66-e_default.elf (stable build for Rev. E, use for debugging)

• Download nxp_fmuk66-v3_default.px4 (latest dev. build for Rev. C/D, use with QGC)

• Download nxp_fmuk66-e_default.px4 (latest dev. build for Rev. E, use with QGC)

• Download nxp_fmuk66-v3_default.bin (latest dev. build for Rev. C/D, use with J-Link)

• Download nxp_fmuk66-e_default.bin (latest dev. build for Rev. E, use with J-Link)

• Download nxp_fmuk66-v3_default.elf (latest dev. build for Rev. C/D, use for debugging)

• Download nxp_fmuk66-e_default.elf (latest dev. build for Rev. E, use for debugging)

Which variant and file type should I choose?

First you should determine whether to use the -v3 (Rev. C/D) or -e (Rev. E) build. This depends on when you got your RDDRONE-FMUK66. Rev. C and D boards have been distributed before 2022, but are still supported. New boards distributed since the beginning of 2022 are most likely Rev. E. You can also recognize a Rev. E board by the 8x RC PWM outputs (older boards had 6x PWM), or the small 2-pin NFC antenna connector on the side (which was not present on previous revisions).

Next you should consider whether you want to use the stable or development build. For flying it is generally recommended to start with a stable build. Only use a development build if you want to use experimental features or if you ran into a bug with the stable build. Note that it is very much possible that the development build introduces additional bugs - so be careful!

Finally you look at the purpose for which you need the binary. Are you flashing the FMUK66 board with a debugger (for example because you are using the board for the very first time), then you need the .bin file. If you have already flashed the board before and a bootloader has already been installed, then you can also upload it as a custom firmware binary through QGroundControl. For this you need the .px4 file. Then there is also the .elf format which can be used with debugging software (e.g. GDB).

Flashing PX4 Autopilot

After the bootloader has been installed, the PX4 firmware can be installed or updated through QGroundControl. When using QGC, it is not necessary to download a firmware binary separately. It will download and flash the latest stable release to your FMU by default, but you can also select the latest development build or a custom binary (.px4 or .bin file).

Guides are available for updating firmware, and building the firmware from source.

RDDRONE-FMUK66(E) PX4 bootloader

(Note: NXP does not provide precompiled code. Binaries are available through the courtesy of PX4)

• Download nxp_fmuk66-v3_bootloader.bin (for Rev. C/D)

• Download nxp_fmuk66-e_bootloader.bin (for Rev. E)

A precompiled PX4 bootloader is available for convenience. This file will be updated infrequently and usually without notice. There is usually no immediate need to flash newer bootloader versions.

This GitBook has a guide for programming software using the J-Link debugger. The bootloader binary has to be programmed at memory address 0x0000 on the RDDRONE-FMUK66. There are also instructions for building the bootloader from source, in case you ever need it.

Oracle VM VirtualBox

• Download Oracle VM VirtualBox from VirtualBox.org

It is required to setup a Linux-based* development environment, preferably based on Ubuntu 20.04 (or 22.04). If you are not running a Linux OS already, you can consider to install Ubuntu natively besides your Windows setup (dual-boot), or on a separate laptop. However the easiest option might be to run it virtually from within your Windows OS. NXP does not endorse any specific tool. An often used option is Oracle VM VirtualBox, which is an open-source virtual machine hypervisor that can be used for free.

Our Developer Guide contains further information and instructions on how to setup your own Linux-based development environment from scratch in e.g. VirtualBox.

J-Link Software and Documentation Pack

• Download J-Link Software and Documentation Pack from SEGGER.com

J-Link Commander is used to flash binaries onto the RDDRONE-FMUK66 board. The latest (stable) release of the J-Link Software and Documentation Pack is available at the SEGGER website for different operating systems.

FlySky-i6S radio controller firmware updater

• Download FlySky-i6S firmware updater (click the firmware button at the bottom of the page)

The firmware on the radio controller can be updated by connecting the transmitter to your PC with a micro-USB cable. Go to the settings menu on the controller, and select "Firmware update". Run the firmware updater tool on your PC to update the firmware on your controller.

Virtual COM Port drivers for FTDI / USB-TTL-3V3 cable

• Download Virtual COM Port Drivers

In some cases you might need to install a VCP driver for the FTDI (USB-TTL-3V3) cable. It is available for Windows and Mac OS. For Windows there is a setup executable available in the "Comments" column.

Personal Protection

Protect yourself and others during drone development and flying. We strongly encourage you and anyone nearby wearing personal protective equipment.

This includes but is not limited to:

• Protective Eyewear

• Protective foot wear such as heavy boots (Steel toe)

• Arms and legs fully covered.

• Heavy jacket.

• Leather gloves, but be careful they don't inhibit safe movement or handling.

You and observers should be well away from the vehicle while testing. You may also want to include a barrier such as netting to either protect yourself, others. You can also fly the drone in a netted enclosure.

Drone laws and regulations

Regulations around the world vary greatly, and not handling according to regulations can result in significant penalties. It is your own responsibility that you follow these regulations. The links below are provided here for guidance only and should not be considered comprehensive information in any way.

Ensure you are familiar with the local regulations that are in place before you fly: regulations are different depending on what continent, country or region you want to fly. The links below might be a good starting point. Please contact us if you have any additions to this list.

Many locations require you pass a drone safety test or drone operators test, and also register and display a registration number on your drone. It is usually not difficult to comply to these regulations but will require some study.

• General resources for drone laws and regulations:

  • https://uavcoach.com/drone-laws/ (scroll down for a list of countries)

  • https://www.droneregulations.info

  • https://drone-traveller.com/drone-regulations-worldwide/

• European Union: http://dronerules.eu/en/​

• United Kingdom: https://www.caa.co.uk/consumers/unmanned-aircraft-and-drones/​

• United States of America: https://www.faa.gov/uas/​

• Canada: https://tc.canada.ca/en/aviation/drone-safety

• India:

  • https://digitalsky.dgca.gov.in/

  • http://pib.nic.in/newsite/PrintRelease.aspx?relid=183093

  • https://www.medianama.com/2018/12/223-drones-online-registration-india/

Privacy Laws

In addition to regulations regarding flying a drone, there may also be regulations relating to privacy when a camera is on board the drone. The link below has a reasonable summary of what may be the situation in your location. This link is provided for convenience only, and should not be considered comprehensive:

• https://surfshark.com/drone-privacy-laws

Safety settings

Some important safety settings are explained in this GitBook. You will come across them when following the pages in the intended order, but please check that you did not miss anything.

The sections linked to below describe how to set up the RC transmitter and FMU such that the drone should not show unexpected behavior when, for instance, the connection is lost. Before you turn on your drone with propellers installed, you should have read these pages and set the settings as described. You should understand why we advice these settings, and understand the shortcomings.

If you decide to deviate from the recommended settings, make sure you know what behavior you can expect and learn what you can do in case something goes wrong.

Flying safely

In the flying section, the principles of safely handling your drone are described. Remember to be extra careful with your first few flights. Fly responsibly and be prepared in case something goes wrong. Make sure you know what to do when something happens. You should know which options you have to land or shut down the drone in case of emergency.

HoverGames website

The main website for HoverGames is .

NXP Mobile Robotics Community

The has a space dedicated to . Here you can ask your questions about the drone kit and add-on boards. There is also a subspace for the . For questions about PX4 Autopilot and other Dronecode software you can use the platforms mentioned below.

PX4 Slack and Discuss forum

HoverGames has its own Slack channel () on the . To gain access to the PX4 Slack, you have to register through first. There are many channels on the PX4 Slack related to different Dronecode projects and different features of the PX4 software. It is recommended to have a look at the list of available channels.

To join you can press "Channels" or the small plus icon next to it, then search for the channel name. If this is not visible, you can make the menu appear by pressing the PX4 logo at the top. Any HoverGames or RDDRONE-FMUK66 specific questions can be asked here. More general PX4 related questions can be discussed in other channels.

Dronecode also has a for discussing PX4, QGroundControl, MAVLink, MAVSDK and other Dronecode projects. General questions regarding drones and PX4 can also be asked there.

Hackster.io Discussion board

General questions can also be asked on the . We try to keep an eye on the new posts and ongoing discussions, but more in-depth or technical questions are better asked on the NXP Mobile Robotics community or on PX4 Slack (or the PX4 Discuss forum).

The discussion board for the first challenge is also still available and can be found .

Contact the HoverGames team

Contribute to our GitBook

This user guide should contain most information you need to get your HoverGames drone and RDDRONE-FMUK66 flying. Most pages should be read in order. Sometimes a link to another page or external source is provided. It is often useful to have a (quick) look at the information found on the external page before you continue reading on this GitBook.

Also, remember that GitBook has a search function - use it to locate specific details quickly! You can find the search box on the right side at the top of the page.

Important information about the HoverGames

to the HoverGames and RDDRONE-FMUK66 if you haven't already done so! It explains what this program is all about, and it introduces the hardware which HoverGames builds upon. Make sure to have a look at the and the before you continue!

Check the contents of the kit!

After receiving the HoverGames kit, the first thing you should do is check its contents. which explains which items should be included in your kit, and the purpose of the different components.

Unfortunately, it is not possible to include absolutely everything you need to fly your drone in the kit. There is a short list of items you will . Most importantly, the kit does not include a battery!

Learn about some basic concepts

If you have never done anything with drones before, it might be a good idea to get familiar with some basic concepts first. The earlier mentioned gives a short explanation of the different parts of a drone. The following page also introduces some of the hardware, software and other important concepts:

You might come across many acronyms and terminology that you are not yet familiar with. Everything should become clear as you keep on reading. If not, there are many resources available on the internet, such as these two webpages:

Build your drone

Configure your radio controller

Learn about PX4 Autopilot and QGroundControl

Install PX4 Autopilot software and configure your drone

Let's fly!

When the drone is ready, make sure to check everything is connected and working as intended!

Frequently asked questions

Developing your own software

Technical reference

This section is a complete guide on how to build the HoverGames drone with the LJI X4 500 drone frame. It is recommended to read this guide thoroughly and in order. You should start with mounting the motors, and finish with connecting all wires to the FMU (flight management unit).

The guide originally consisted of text and pictures. Videos are now available as well. It is recommended to use the videos together with the written instructions, to make sure you are not missing any information.

Please contact the HoverGames team in case anything is missing, unclear or if you have any feedback.

NOTICE: New motors for 2021/2022

Motor mounts

The four motor mounts go on the end of the arms (carbon fiber tubes). Each one consists of two small carbon fiber plates, four tube clamps (the arch-shaped parts), and four long M2.5 screws with locknuts (with an elastic ring inside). Additionally, you need the motor itself and four short M3 screws from the labeled bag.

Assembling the 5010-750kV motor

The new motors for late 2021/2022 require some assembly. Please follow the images below to assemble.

First, you should organize the parts that come in the package for each motor. The package should include 4 black M3 screws, 4 silver M3 screws, a washer, a hub, and a cap.

Install the hub to the top of the motor using the 4 included black M3 screws.

Add the washer and the cap to the hub.

Use the video below to get an idea of how to attach the motor. It takes 4 screws on the bottom just like the previous model. You will find that the motor blocks the nuts for the comlete motor mount package. We suggest using the included wrench to tighten these down, rather than the nut driver shown in the video.

The first step is to mount the motors onto the carbon plates. You need a carbon plate and four M3 screws for this. Make sure the three motor wires come out on one of the short sides of the carbon fiber plate. Repeat this step until you have all four motors mounted. Make sure you tighten the screws appropriately, because it will be hard to access the screws later.

For the next step, we need: four tube clamps, the other carbon plate, four long M2.5 screws and the locknuts.

• The screws go through the holes in the corners of the carbon fiber plate.

• Then on each side, slide *two* tube clamps (forming a circle) over top of the screws The carbon fiber arms will fit between these clamps.

• Finally, the remaining carbon fiber plate goes on the part of the screw left sticking out. A locknut goes on the end. Tighten the nuts slightly by hand, so they don't fall off. You don't have to fully tighten them with a wrench yet, because we have to put the carbon fiber tubes through first, and then we will tighten it around the tube.

Alternative approach

There are two ways to assemble the motor mounts. While having the screws come down from the top, with the locknuts on the bottom makes logical sense as you would probably only lose the nut if it comes loose during flight. However, it can also be convenient to put the screws up from the bottom. In this case, you put the screws through the "bottom plate" first, with the tube clamps going on top. The advantage is you can then put this structure on the table and put the plate with motor on top of it.

Serviceability is also a bit easier since the Motor plate is easy to put on and off without disturbing the screws and clamp portion. This is nice if you are building multiple drones kits, or when you have to take them apart often. Similarly "up" going screws are especially useful for the clamps in the middle main body part of the drone. These are built in a similar way as these motor mounts. The disadvantage is that you are likely to lose both the screw and the nut in case it comes loose. Ultimately, it comes down to preference.

Inserting the carbon fiber tubes

You can now insert the carbon fiber tubes between the tube clamps. The motor mounts should be on the end of the tube. The tube should extend slightly beyond the motor mount, but a few millimeters should be enough. The motor wires should be on the opposite side of the carbon fiber tubes. These wires will later plug into extension cables that will come from inside the carbon tubes. Once the tube is inserted, you can tighten the screws using a hex key and a wrench.

If you look carefully, you can see that two motors have a notch on top of the shaft. The other two motors have a flat top. This is an indication of the direction in which the motor is supposed to rotate, and the threading on the shaft corresponds to this.

We will come back to this later. Just keep in mind that there are motors that are supposed to rotate clockwise, and motors that should rotate counter clockwise.

Motor extension wires

You can choose to insert the extension wires into the tubes already. These wires will plug into the ESCs (electronic speed controllers) that we will put inside the center of the drone frame in a later part.

What is this program?

Unmanned aerial vehicles (UAVs) promise new perspectives on the world around us and the ability to go places that were once impossible. NXP is a trusted leader in automotive, radar, aerospace, RF, security, motor control and battery management and places the world’s most complete portfolio of UAV technologies in the hands of developers. Our automotive grade solutions are well suited to the design methodology and environments in which commercial unmanned aircraft systems, and increasingly also personal UAVs, operate. We provide semiconductor solutions for every aspect of drones and rovers.

The HoverGames drone kit

The HoverGames drone kit is a single, modular, and flexible NXP development platform with the RDDRONE-FMUK66 flight management unit at its base. It can be used to build any autonomous vehicle, from drones to rovers to flying cars. As part of the kit, participants receive a complete reference drone including the flight management unit (FMU).

HoverGames drone flight management unit (FMU)

RDDRONE-FMUK66 is an experimental flight management unit that is compliant with Dronecode and PX4 Autopilot software. PX4 is used extensively for research and commercial drone platforms. Its permissive BSD license preserves the ability to include proprietary IP.

The RDDRONE-FMUK66 runs NuttX RTOS on a NXP Kinetis K66 microcontroller, with an ARM Cortex-M4 core at 180 MHz and 2 MB flash memory. It uses NXP sensors, automotive CAN bus transceivers, as well as the new two wire automotive 100BASE-T1 ethernet transceiver TJA110x.

What is our mission?

Spread the latest technology to developers

Drones and rovers have the capability to enhance our cities and rural areas in the same way that autonomous cars and mobile technologies do. We want to bring the latest innovations in these areas to the small autonomous vehicles of the future. They need the same high reliability, security and functional safety that make it possible to occupy the same spaces, roads and sky, as we humans do.

With the HoverGames challenges we can introduce this technology to you, and share our findings as we learn together how the technology could be used in new ways. We want to invite everyone who is interested to use the newest technology on the market and take advantage of the many possibilities the tech provides.

Co-creation code sourcing

Many drone challenges today are human operated races, and while they are lots of fun, they are about operating a drone, not controlling or programming a robot. HoverGames will encourage participants to write code that enhances or activates new features in their vehicles, in addition to fun racing challenges. Ongoing coding challenges of all levels will be presented, and the resulting code is shared and published as open-source. The PX4 community Slack, Discuss forum, GitHub and the GitBook platforms give participants the ability to communicate and support each other as well as get support from NXP Industrial and Automotive and from external partners.

Tackle real life problems

The result of solving a set of ongoing coding enablement challenges, be it for enabling new hardware components or new software features, is to use the sum of all these new capabilities to take on complex action challenges where participants design and adapt their vehicles to tackle a real societal problem. Each one is different and can range from cleaning up the beach, mapping a dangerous gas emission, or locating and tracking migration patterns of an endangered animal species.

How do we make this mission a reality?

To achieve these goals, we will have a series of developer and hacker challenges.

HoverGames are a series of hands-on challenges for engineers and tech enthusiasts to co-pioneer with NXP and design for new forms of mobility. Each game consists of a set of challenges. Participants need to buy a kit - a physical complete drone kit you hold in hands - form teams and enroll virtually. As part of each game, participants will write code that activates their vehicles.

To warm up - participants will be asked to take part in comparably simple coding challenges to get familiar with their drone and the Dronecode environment including PX4 software flight stack . This code serves as a basis for further challenges as they build upon each other.

After getting comfortable with the entry level challenges, participants can enroll in any of the currently active Virtual Software challenges. Some will be open to anyone, some will need pre-qualification in order to get access to specific hardware boards that might be needed.

Once or twice a year larger Societal Challenges will be announced. For these, the participants use the existing and newly solved body of knowledge to design vehicles that can solve a societal problem – For example a simulation of cleaning up nuclear waste, or tracking migration patterns of an endangered animal species.

We need you!

UAVs have a wide range of applications in many fields like environmental hazards monitoring, traffic management and pollution monitoring, all of which contributes greatly to the development of any city and rural area. HoverGames will be of great benefit to developers around the world to jointly develop autonomous robot vehicle solutions.

More information can be found on HoverGames.com. It is also possible to directly contact the HoverGames team, contact information is available on our contact page.

While the HoverGames kit includes most of the parts needed to build your HoverGames drone, some parts could not be included. You will have to buy them yourself. On this page, you can find a list of parts that you need to buy to complete your HoverGames drone.

Holybro Transceiver Telemetry Radio V3

• Product webpage

The standard drone kit does NOT include a telemetry radio transceiver set, because there are different versions for different regions. However, NXP does sell the recommended Holybro radios!

Please make sure you order the right ones for your region. Depending on your location, you need either a 915 MHz or 433 MHz set. Please check which frequencies / ISM bands are allowed in your region.

A set of telemetry radios allows you to change settings and parameters of the FMU without USB. It also allows you to check the status of the drone while it is in the air. One radio connects directly to the FMU. The other radio can be plugged into your computer using the included USB cable.

LiPo batteries

Drones require batteries which can handle the high currents drawn by the motors. Lithium batteries are able to supply these high currents. Typically these are lithium polymer batteries in a flat "pouch" type configuration. Other cell types and chemistry such as Lithium ion cylindrical or LiFe prismatic cells may be used in some commercial applications. These lithium polymer (LiPo) batteries (and most lithium batteries) can be quite dangerous because of the amount of power they hold, and as such there may be restrictions for shipping this kind of batteries. Overcharging, overdischarging and overheating can lead to catastrophic failure and an uncontrollable lithium metal fire. While you should not be unduly worried, you should always treat the battery pack with respect, store and charge them safely, and properly dispose of any damaged ones. For this reason, there was no battery included in the kit. You will have to buy an appropriate LiPo battery yourself.

Airline Travel with LiPo batteries

Battery specification

The provided frame, motors and ESCs are designed for a a LiPo battery with the following battery specifications:

• 3S or 4S, which means a battery with 3 or 4 cells in series. This is often also indicated by the nominal voltage, which is 11.1 V for 3S batteries and 14.8 V for 4S batteries.

• XT60 power connector (the big connector, usually yellow).

• Capacity of 3000 mAh to 5500 mAh will give you a reasonable flight time.

  • Smaller batteries will reduce flight time.

  • Larger capacity batteries will become too big and heavy.

  • A capacity of around 4200 mAh is usually the most cost effective.

• 20C continuous discharge rating or higher is recommended. 20C means that the battery can supply a continuous current 20 times its capacity. For a 4000 mAh battery, that means it can continuously supply a current of 80 A. For a 3000 mAh battery you probably want to have at least a 25C rating.

LiPo battery charger

A good LiPo battery charger is required to safely charge your LiPo batteries. This cannot be done with an ordinary power supply or battery charger! The kits already include a simple charger to get you started. However, these chargers are slow because they only charge through the balance connector.

Therefore, it is recommended that you buy a higher quality charger at some point. A good one charges the battery through its main connector and uses the balance connector only for cell balancing. A good battery charger should also be able to charge batteries with different cell configurations.

AA batteries

The RC transmitter is powered by four AA batteries, which are not included in the kit. They should be easily available for you to buy.

Extra screwdrivers

The HoverGames kit includes some hex/Allen keys and a wrench which are needed to build the frame. However, you might also need an additional Phillips/Pozidriv screwdriver and a small 1.5 mm hex/Allen key. Note that there are 2.0 and 2.5 mm hex keys included in the HoverGames drone kit.

The HoverGames drone kit includes most components required to build your own quadcopter. The kit provides a frame, motors, electronic speed controllers, the RDDRONE-FMUK66 flight controller and some additional peripherals. The contents of the package should be checked to make sure nothing is missing.

Overview of the included items

• 1x NXP RDDRONE-FMUK66 with enclosure and microSD card

• 1x ReadytoSky LJI X4 500 quadcopter frame kit with carbon fiber landing gear

• 4x ReadytoSky RS2212 920 kV CW & CCW brushless motor

• 4x ReadytoSky 2-6S 40 A OPTO ESC

• 12x Extension cable with bullet connectors

• 4x LJI 9450 propellers CW & CCW

• 1x FMU power module

• 1x Holybro Pixhawk 4 GPS with integrated safety switch and buzzer

• 1x FlySky FS-i6S radio control transmitter and FS-iA6B receiver

• 1x 3D printed RC receiver antenna mount

• 1x Debug breakout board with cable and 3D printed enclosure

• 1x Segger J-Link EDU Mini debugger

• 1x Generic USB-TTL-3V3 cable

• 1x HoverGames battery strap

• 1x HotRC A400 3S-4S LiPo battery charger, with EU & US power plugs (BATTERY NOT INCLUDED!)

• Hex/Allen keys and wrench

• Extra cables with JST-GH connector

• Double-sided foam tape / sticky pads

• Zip ties

NXP RDDRONE-FMUK66 with enclosure and microSD card

• Product webpage

The NXP RDDRONE-FMUK66 flight management unit is the brain of the HoverGames drone. It features NXP sensors and automotive grade components and it is fully supported by PX4 Autopilot software. This GitBook provides instructions and external sources which should help you set up the software.

The FMU comes with a 3D printed enclosure, which can be mounted on top of the drone with double-sided tape. A microSD card is also included, to which logs will be written during flight. Make sure to insert this SD card before you fly!

ReadytoSky LJI X4 500 quadcopter frame kit with carbon fiber landing gear

• Product webpage

The LJI X4 500 quadcopter frame is the body of the HoverGames drone. It replaces the S500 frame that was included with older kits. It is completely made out of carbon fiber parts and has a vibration damped mount for the FMU. This GitBook provides instructions on how to assemble this frame.

• Frame size: 500 mm (diagonal), 200 mm (height)

• Weight: 475 g (without electronics and motors)

ReadytoSky RS2212 920 kV CW & CCW brushless motors

• Product webpage

The kit includes four brushless motors suitable for a quadcopter the size of the HoverGames drone. Two motors will rotate in clockwise (CW) direction, and two in counter clockwise (CCW) direction. This allows the drone to fly stable without unwantedly rotating around its vertical axis.

The clockwise (CW) rotating motors have a little notch on top of their shaft. It might come with a black nut. The counterclockwise (CCW) rotating motors have a smooth top and they usually come with silver nuts.

ReadytoSky 2-6S 40 A OPTO ESCs

• Product webpage

There are four ESCs (electronic speed controllers) or motor controllers included in the HoverGames kit. The ESCs control the current to the motors on demand of the FMU. The motors are connected to the ESCs with three bullet connectors. It is safe to connect these three connectors in any order.

The provided ESCs are able to handle currents up to 40 A continuously, which should be more than enough when used with the included motors. They support battery configurations between 2 and 6 cells in series (3 or 4 cells are recommended).

LJI 9450 self-locking propellers CW & CCW

• Product webpage

Included in the kit are also two clockwise (CW) turning propellers and two counterclockwise (CCW) propellers. The intended direction of the propeller becomes clear from the shape of the propeller. Looking at it from the side, it curves down towards the back of the propeller blade, with the front being the side which "slices through the air first".

The direction of these self tightening propellers is also easily recognized by the color of the "integrated" nut. Propellers with a black nut are meant to go clockwise, and propellers with the silver nut go counterclockwise.

FMU power module

• Product webpage

The power module provides power to the FMU and also includes voltage and current sensors which allow the flight controller to keep track of the battery level.

The small white JST-GH connector provides power to the FMU. The larger black XT60 connectors go to the batteries and to the power distribution board (PDB). The PDB included with the frame kit should already have an XT60 connector installed. (Note that XT60 connectors may also be yellow.)

Holybro Pixhawk 4 GPS

• Product webpage

GPS allows the drone to receive information about its position. This enables position hold mode and autonomous flying modes in which no user input is required. The Pixhawk 4 GPS has an integrated safety switch, buzzer and status LED. It plugs directly into the FMU. It also includes a compass, which is able to measure the rotation of the drone. The GPS comes with its own mount as well.

FlySky FS-i6S radio control transmitter and FS-iA6B receiver

• Product webpage

For controlling the drone, a radio controller is included. The transmitter has several switches to which different actions and functions can be programmed. Settings are changed with a touchscreen, which can also be set up to show telemetry data. The receiver module connects directly to the FMU. A 3D printed component for mounting the antennas of the receiver is included in the drone kit.

More information on setting up the RC transmitter and receiver can be found elsewhere on in this GitBook.

Segger J-Link EDU Mini / USB-TTL-3V3 cable / Debug breakout board with cable

Debug tools are also included in the HoverGames kit. It consists of a small breakout board with a 3D printed plastic case, a Segger J-Link EDU Mini debugger and a USB-TTL-3V3 cable, as well as a 7 pin JST-GH cable that connects the breakout board to the FMU. With this setup you can program a blank board, single step through the code, set breakpoints and debug the processor. The USB-TTL-3V3 cable gives you access to the system console.

Stay up-to-date

Below you will find a list of recent updates and important news about the HoverGames and this GitBook, but there are also some other platforms that you should keep a close eye on:

Recent updates

July 16, 2020

• A page about has been added.

July 15, 2020

• Five HoverGames/PX4 example labs have been added. You learn step-by-step how to create a basic PX4 module/application. The following labs are currently available:

July 14, 2020

July 6, 2020

June 18, 2020

May 28, 2020

May 26, 2020

• GitBooks added for NXP's new HoverGames add-on boards:

April 22, 2020

• The NavQ companion computer was added to list of add-on components.

The FMU comes with a 3D printed enclosure, which still has to be assembled. It consists of a top part, a bottom part and a tiny reset button.

First, make sure the reset button is installed inside the enclosure. It should fit in a hole in the side, next to the hole for the micro USB connector.

Now, the FMU can be installed into the bottom part of the enclosure with four short screws (7 mm). You may only have one type of screw with your case, which is fine as well. Just use four of the included screws and be gentle when tightening them into the plastic. Do not overtighten.

After the FMU is installed and screwed down to the bottom part, you can put the top part of the case in place and turn the whole enclosure upside down. You need two short screws (7 mm) and two longer screws (about 10 mm) to keep the two halves together. The short screws should go in the holes close to the servo-rail of the FMU. The longer ones go in the holes near the SD card slot. Again, if you have only one type of screw with your case, that is fine as well. Just be gentle when tightening the screws.

Mounting the ESCs

Before we continue, you should put the yellow XT60 connector through the hole closest to what will be the back of the drone. See the picture below.

The ESCs should come with pre-soldered bullet connectors on the red and black leads. Also, there should be four sets of three extension cables included, which go between the ESCs and the motors. Plug these extension cables into the ESCs first, if you didn't already plug them into the motors. In that case, you can connect them to the ESCs later when we install the arms onto the body of the frame.

Then, plug the red and black wires into the PDB and use some zipties to strap the ESCs to the bottom plate. You could also use the double sided foam tape / sticky pads. You can see four screws for mounting the arms in each corner, make sure you do not cover them with the ESCs.

You should install the ESCs in a similar way to what is shown in the picture below. This should still give you enough space to plug in the connectors.

FMU power module

The yellow XT60 connector coming from the PDB is now coming out at the bottom of the frame. You can plug the FMU power module (with black or yellow XT60 connectors) into this connector. Use a zip tie to strap the power module to the bottom of the frame. You should be able to use some of the slits at the front for this. When we are finished, the battery will be plugged into the other end of the power module.

Make sure to put the 6 pin JST-GH connector coming from the power module through the hole in the middle. We will plug this into the FMU (which will go on top) later. This cable will provide power to the FMU as well as voltage and current sensor data.

RC receiver module

We will also mount the RC receiver module on the bottom. The receiver for the radio controller has two antennas that work best when under an angle. A 3D printed antenna mount is included in the kit. The antennas should fit right into it and can be attached to the rails.

A small cable with a 6 pin JST-GH connector one side and a 3 pin servo connector on the other side should be plugged into the receiver module. The pins are labeled i-BUS SERVO on the receiver. The signal wire (white) should be on the outside. See the picture below.

The antenna mount can be easily attached to the rails at the bottom of the drone. You can always move it over the small carbon tubes if the antennas are blocking a screw or nut.

You can fix the receiver module itself with a zip tie or some double sided foam tape/pads. Just like the cable coming from the power module, put the cable with JST-GH connector through the hole in the middle. This cable will plug into the FMU as well.

Battery plate

We have installed everything on the bottom of the drone, except for the battery plate. It consists of a carbon plate with two clamps that are put together with four small screws. It is easiest to put the clamps onto the rails first, then screw the carbon plate onto them. A velcro strap is included to keep the battery in place.

Vibration damped FMU mount

First the FMU mount should be put together. It's a small carbon fiber part and it should come with four black vibration damping rubbers. You should put these rubbers through big holes in the corners of the carbon, as shown below.

There are four similar holes at the corners of the big gap in the middle of the top plate. You should also put the rubbers through these holes, as shown below. Note that they do not exactly align, there will be some tension on the rubbers. This will help dampen the vibrations.

Installing the GPS

The GPS and its mount consist of several parts. The GPS should come with a short and a long rod. We recommend to use the shorter one, because it won't vibrate as much as the longer rod. However, many successful tests were done with the long one as well, so ultimately it comes down to personal preference. The longer one is useful when you get too much interference from the other electronics on the drone.

A small part that will hold the rod should be screwed onto the cross-shaped base, using a hex screw.

The rod can be inserted into this piece and will be kept in place with a tiny hex screw.

You should put the big "cone" over the rod, you can screw this onto the base.

On top, you should have a big flat piece, which is also kept in place with a tiny hex screw.

With the included double sided tape, you can install the GPS itself on top. Make sure the arrow on the GPS aligns with one of the "arms" of the cross-shaped base. It doesn't have to be perfect, you will be able to slightly rotate the GPS after loosening the small screw in the top part of the mount.

We also suggest to remove the piece of heatshrink (or cloth tape) at the end of the GPS cable, just before the connector. Be *very* careful to not cut the wires! The reason for this is that this heatshrink itself is quite stiff and in some cases this could cause mechanical vibrations in the GPS mount to be transmitted by the cable to the FMU.

Once it's assembled, the GPS mount can be installed onto the top plate. It's easier to do this now, because you can easily access the bottom side of this plate.

Earlier, on the bottom plate, we defined the front as the side pointed to by the weirdly shaped gap in the plate. The gap with the little notch or triangle. We will also use this to define front for the top plate. We will install the GPS on the right side of the plate, and the arrow on the GPS should point towards the front of the drone. Also see the picture below.

There should be screws and nuts included with the GPS. You can use the slits on the side of the plate to put the screws through. On some top plates there will be exact holes to mount to. We have used only three screws, which should be enough. If you put a washer in between, you might also be able to use the fourth screw.

Arming switch integral to GPS module

Telemetry radio

The telemetry radio can be installed on the left side of the plate (the opposite side of the GPS). Use a ziptie or some double sided foam tape. Make sure both the JST-GH and Micro USB connectors remain easily accessible. You will use the JST-GH to connect the radio to the FMU, and you might need the micro USB to connect it to your computer to update the radio firmware.

Be careful that you don't cover the screw holes for the arms with the telemetry radio or its antenna. There are four in each corner of the plate.

Mounting the FMU

You can mount the FMU with some sticky pads. Later, we will plug in all the wires and use some zip ties to secure them.

Landing gear

Each leg consists of two parts. The first is the horizontal part with the T-connector and foam protection. The second is the carbon fiber tube with the connector that can be mounted to the frame.

Begin by loosening the two hex screws on the side of the T-connector. You should now be able to put in the carbon fiber tube. Once it is inserted, you can tighten the two screws again. Do this for both legs.

Next, we will need the bottom plate of the frame. It is one of the two plates with the cut out areas as shown above. The bottom plate is the one with the circle shaped holes in the middle and on the sides, we will put the other one on top. Around the two circle shaped holes on the sides, there are four small holes for screws. The black M3 socket head cap screws go down these holes, and should screw directly into the leg mounts. Nuts are not needed for this part.

Installing the PDB

Next, we will install the power distribution board (PDB) onto the bottom plate. You should have a pre-soldered board included with your kit. It already has small connectors for your ESCs. It also has a yellow XT60 connector for the FMU power module (and battery).

There should be nylon spacers and nuts included with the unsoldered PDB. We will reuse these with the soldered PDB and install four of these spacers on top of the bottom plate. We will then use the remaining four spacers to keep the PDB in place.

There are eight holes for screws distributed in a circle around the center of the bottom plate. We will use the "diagonal" holes, so not the holes that are closest to the legs or the front/back of the plate. Put a spacer through from the top, and use a nut to keep it in place. It should be fine to tighten them by hand, it is not necessary to use the wrench.

You can now put the PDB on top, and use the other four spacers to keep the PDB in place. The orientation of the PDB does not matter a lot, but the XT60 connector should go through the larger hole at the back of the frame. We define the front of the drone as the side to which the weirdly shaped hole "points". Also see the picture below.

Rails

The next step is installing the rails. Other plates and components can easily be attached to them. These rails are a defacto standard of 60 mm spacing with 10 mm carbon fiber tubes, and you can find several 3D printable mounts which fit.

We have to install these rails now, because after the other components are installed the screws will be very difficult to get in place. We need the two 10 mm carbon tubes, the two plastic bags with tube mounts and rubber rings, and the small M2.5 screws. There is also a smaller carbon fiber plate included, typically used for camera mounting, that we will put on these rails.

First things first, put the rubber rings through the tube mounts, as shown in the picture below.

You can now gently slide these tube mounts onto the carbon rods. We found that this is easier than first installing the tube mounts on the bottom of the frame, and then forcing the carbon tube through them.

Slide the tube mounts on the carbon tube, such that on one side the screw holes in the tube mounts align with the holes in the big bottom plate of the drone. On the other side, the holes should match with the small plate. Also see the picture below.

We can now easily mount this onto the bottom plate, using either the small M2.5 socket head cap screws. The screws go down from the top, and should screw directly into the tube mounts. The extra tube mounts for the small plate should be at the front of the drone.

Finally, you can also mount the small plate. You either need the same M2.5 screws or the small countersunk screws that are included in newer kit. This plate could be used to mount a camera gimbal. Note that there is no camera or gimbal included in the drone kit.

Connector pinout

We are almost ready. We only need to connect the wires to the right connectors on the FMU. A diagram showing all port locations is available below. is also available in the technical reference section.

There are four connectors that you should plug in. The 6 pin POWER IN connector at the top right. Below that is the 10 pin GPS connector. On the left side is the 6 pin TELEM connector for the telemetry radio. And below the GPS there is also the 5 pin RC IN connector for the RC receiver.

Servorail

The servorail pinout is shown in the diagram below. If you have a BEC (not included in the standard HoverGames kits), it should be connected to the leftmost pins. The ESCs should be connected to the first four sets of pins on the right side.

The order in which the ESCs should be connected to the servo rail is given by the diagram below. The red arrow indicates the front of the drone. Because the ESCs are mounted in a very tight space, it might be hard to find which wire is coming from which ESC, and which ESC is connected to which motor.

If you followed the assembly instructions on the previous pages, the position of the ESCs should correspond to the table below. If you are not sure if you followed the previous instructions correctly, you might want to have a good look at where the wires are going, and write down which motor they control.

When inserting the connectors to the servorail, the black (ground) wires should be on top, and the white (signal) wires on the bottom. The BEC doesn't have a white wire, but it has a red wire, which goes in the middle. It will provide 5V power to all pins in the middle row. However, the ESCs included in the HoverGames drone kit already receive power directly from the PDB and therefore don't have a wire that connects to the middle pins of the servo rail.

At this point, the drone should look similar to the picture below.

Final result

Finally, you can use some zip ties to make sure the propellers won't cut through any loose wires. You could already install the propellers, but you might have to remove them again later. The propellers with black nuts go on the clockwise rotating motors (with a notch on the shaft), the propellers with silver nuts go on the counter clockwise rotating motors.

Installing the top plate

We will first install the top plate and the tube clamps, in between which the carbon tubes will be kept in place. These are the same tube clamps as used for the motor mounts.

It's easiest to put the plate on top of the ESCs, it should be fairly level. Then, start on one side. Put two tube clamps in between the plates, put the screws through and put the nuts on by hand. You don't have to tighten them with a wrench yet. Make sure the three extension cables coming from the ESC are put through the middle.

Repeat this seven more times, until in each corner you have two sets of tube clamps. Make sure the ESC extension cables are routed through the holes in between the clamps.

Installing the arms

When we first put together the arms, it was explained that there are clockwise rotating motors and counter clockwise rotating motors. At this point, you have to be careful. You have two arms with a clockwise (CW) rotating motor (with a notch on top of the shaft), and two arms with a counter clockwise (CCW) rotating motor (flat top).

The motors should be mounted according to the following diagram. The CW rotating motors with a notch should go on the front left and back right of the drone. The CCW rotating motors without this notch should be on the front right and back left.

If we look at the figure above, the green motors (3 and 4) should have a notch on top of their shaft. The shaft of the blue motors (1 and 2) should have a flat top.

Once you are absolutely sure that you have the right arm, you can put the extension cables inside of the tube, and put the tube it in between the clamps. On the inside, make sure the carbon tube aligns with the clamps. It's also okay if it slightly extends beyond the clamps, then just make sure this is the case for all four arms.

Make sure the motor is pointing upward and is not askew. You can then tighten the screws that go through the tube clamps, using a hex key and a wrench. Repeat this process for all four arms. Make sure at all times that you use an arm with a motor that is made to rotate in the right direction!

Plugging in the motors

The extension cables should come out slightly at the end of the arm. You can plug in the motor wires, the order does not really matter. However, if the motor happens to be turning the wrong direction (note that this is independent of whether the motor is SUPPOSED to rotate that way), you only have to swap two of the wires, and it should then rotate in the other direction.

It's best to leave the cables like this for now. After you have been able to run the motors for the first time, you can verify whether all motors are rotating in the right direction, and change the cables if necessary. After that, you can push them inside the carbon fiber tube. You might have to pull gently from inside the frame. It can be a bit hard to access, but you can also use some pliers, as long as you are careful.

Introduction

Preparing the arms and motors

Landing gear, PDB and rails

ESCs, FMU power module and RC receiver

Top plate, GPS, telemetry and FMU

Mounting the top plate and arms

FMU enclosure

Connecting all FMU wires

When a compatible bootloader is present on the target device, QGroundControl can update the firmware on it. You can use this feature to update the PX4 firmware on the RDDRONE-FMUK66, but also to update firmware on telemetry radio modules.

The QGroundControl user guide provides a clear description of the firmware uploading process. Please have a look at their documentation:

Uploading PX4 firmware using QGroundControl

It is recommended to use PX4 on the RDDRONE-FMUK66. It's an opensource flight stack containing all the software necessary to get your drone into the air. PX4 is constantly being updated with stability improvements and new features. It is recommended to always run the latest (stable) firmware on your FMU, as constant updates will make your drone fly more stable, add exciting new features and open up more possibilities for using different sensor types. In the Firmware screen you can upload a new version of PX4.

QGroundControl will ask you to plug in your FMU using a USB cable. It might also ask you to first unplug it again, because it needs to enter the bootloader before it can upload firmware. A popup will appear that asks you which flight stack you want to use. We will use the PX4 flight stack. You can choose between the standard (stable) version and test/development versions, or a custom firmware binary. It is recommended to use the stable version, for now.

It is also possible to build the firmware yourself (or download binary files from the PX4 Continuous Integration server), and upload it through the custom firmware option. Instructions for building your own firmware binaries from source are available in the developer guide:

Updating the telemetry radio firmware

It is recommended to also update the firmware on your telemetry radios. Simply go to the Firmware tab in QGroundControl and plug in your radio using a USB cable. Make sure you only have the radio plugged in to your laptop, no FMU. QGC should automatically detect the radio and start the firmware upgrade process. If you get any errors during this process, starting over usually works.

You have to do this for both radios! If you don't, you might not be able to establish a connection. Make sure the radio on the drone is not connected to the FMU (take out the JST-GH connector) and connect it with a USB cable to your computer, just like the other radio.

Disclaimer

Software setup and debugger adapter board

The bootloader can only be written to the board using a debugger. Once a bootloader is present, then PX4 itself may be written using QGroundControl or the debugger. The HoverGames drone kit includes a J-Link EDU Mini debugger. To use it, you need to install the J-Link Software Pack. Links are provided on the downloads page.

The debugger can be plugged into the FMU using a small adapter board. This small PCB comes with a 3D printed case that can easily be put together. The J-Link debugger can be connected using an SWD cable. The connectors have to be oriented such that the wires directly go to the side of the board, as shown in the picture below.

While you do not need it right now, the adapter board also has a 6-pin connector for a USB-TTL-3V3 cable, which you can use to access the system console of the FMU. The 3D printed case has a small notch on one side of the connector. The USB-TTL-3V3 cable needs to be plugged in such that the black (ground) wire is on the same side as this notch in the case.

Video tutorial

We have created a video walking through the instructions below if you prefer watching a video rather than reading documentation. If you get confused at any time during the video, use the documentation below as a reference!

Programming the bootloader

RDDRONE-FMUK66 expects a bootloader to be programmed onto the board. We will flash the PX4 bootloader, which can be used from the command line or QGroundcontrol to load new PX4 firmware when powering the board. A precompiled binary of the bootloader is available on the downloads page.

Connect the debugger to the FMU using the 7-pin JST-GH connector from the debug adapter board and plug the USB coming from the debugger into your computer. You should provide power to the FMU using a USB cable. Then start the J-Link Commander program, and follow these steps:

• Enter the connect command.

• Enter ? to bring up a window in which you can select the target device.

• In the Device field, enter MK66FN, select MK66FN2M0xxx18 and press OK.

• Type s to select SWD as the target interface.

• Press enter to select the default interface speed (4000 kHz).

• Enter loadbin "/absolute/path/to/bootloader.bin" 0x0 command to write the bootloader to the board at memory address 0x0. Change the path to the location of the bootloader binary file.

Programming the firmware

The firmware can be programmed to the board with almost the same procedure as the bootloader. You first need to download a firmware binary (.bin file) of the PX4 firmware. We keep up-to-date links to the recommended releases on our downloads page, because it is important that you start with the most stable and up-to-date version of the firmware.

To write the firmware, you have to make sure the debugger is still plugged into your computer, and the FMU is still powered. If you did not keep J-Link Commander open after writing the bootloader, you can restart it and follow these steps again:

• Enter the connect command.

• Enter ? to bring up a window in which you can select the target device.

• In the Device field, enter MK66FN, select MK66FN2M0xxx18 and press OK.

• Type s to select SWD as the target interface.

• Press enter to select the default interface speed (4000 kHz).

Finally, you can write the firmware to the board using the following command:

• Enter loadbin "/absolute/path/to/firmware.bin" 0x6000 command to write the firmware to the board at memory address 0x6000, which is the address at which the bootloader will look to start a program. Change the path to the location of the firmware binary file.

Attribution

This content generously contributed by @NotBlackMagic

RCReceiver RSSI

The stock firmware of the included RC receiver, the FS-iA6B, does not provide any RSSI signal feedback even though the hardware is capable of it. It is possible to enable this feature by flashing a new firmware, developed by the community: https://github.com/povlhp/FlySkyRxFirmware

This GitHub has all the instructions necessary on how to access the programing interface of the RC receiver and how to flash the new firmware.

With the new firmware flashed, we now have the receiver RSSI signal output on SBUS Channel 14, which then can be read by the FMUK66 by setting the RC_RSSI_PWM_CHANNEL parameter in the PX4 firmware (can be done through QGroundControl) as shown in the figure bellow:

Enabled RC RSSI reading on SBUS Channel 14

The RSSI value is then also displayed in QGroundControl like can be seen in the figure bellow:

The HoverGames drone kit includes the LJI X4 500 drone frame. We previously used an S500 drone frame, for which a S500 airframe preset was available. Currently, we still use this with the LJI X4 500 frame.

In the airframe screen, under the Quadrotor X configurations, select the S500 airframe preset. The QGroundControl user guide provides more information on how you can select this airframe.

A very important step is the setup of the safety features and fail-safe options. Make sure to have a look at the QGroundControl documentation for this tab.

For safety, we again recommend you to set up a kill switch on your controller, as has already been mentioned in the flight modes section.

It is also highly recommended to set up fail-safe features in case the connection to the RC transmitter is lost. If you followed the suggested radio controller setup, you already have a fail-safe implemented that the receiver module will trigger. It was explained as a last resort that should turn of the drone to prevent a fly-away situation. However, PX4 should also be able to detect RC connection loss (and not listen to the kill command coming from the receiver module). You can configure different fail-safe actions, that don't necessarily damage the drone.

There is not a single best setting for fail-safe options: it depends on the situation in which the drone is deployed. For example, when flying autonomously close to people, it might some times be better to just stop the motors in uncontrollable situations: when you are flying close to people, the drone might fly into them when control is lost.

But in other situations it might be better to have the drone try to fly to a safe location before landing: when the drone is flying very high, almost above people, where a gust of wind could blow it towards and on top of someone. You should always evaluate what is best in your specific situation.

We recommend to use the land mode action for both the low battery level fail-safe and the RC communication loss fail-safe. The drone will try to land in its current location when the fail-safe is triggered.

More information on how to set up fail-safe features can be found in the PX4 user guide:

Pre-flight and takeoff procedures

In order to start flying your drone, there are a couple of steps you need to follow. It is important to follow all these steps before every flight.

1. Make sure you have fully set up your drone. While it is not necessary to check every little setting every time before takeoff, it is a good idea to regularly check your settings, especially after making a lot of changes.

2. Check out the Flying Regulations in your area whether you are allowed to fly in your area.

3. Check that you are flying safely by going through the Safety Guidelines.

4. Arm the drone, which is a two-step process involving both the drone and the RC transmitter:

   1. Arm on the drone-side by pressing and holding the safety switch on the GPS module, until it starts blinking faster.

   2. Arm on the RC transmitter-side by holding the left stick to the bottom right, until the safety switch and RGB LED on the FMU glow solid. At this point the drone is armed!

When the drone is armed, its motors will start rotating immediately! When you test this for the first time, do this without propellers!

Now that the drone is armed, it can be controlled using the RC transmitter. For more tips on things to think about while flying, you can refer to the During flight section. When it is armed, the drone can be disarmed by moving the left stick on the RC transmitter to the bottom left, until the lights on the drone start flashing again (safety switch and RGB LED). More information on what to do when you are done flying can be found in the After you fly section.

Pre-flight checklist

It's a good idea to make your own pre-flight checklist and "tick off the boxes" before you arm the drone and go fly. At least include the steps that are mentioned above, with as much details as you need to remember what you need to do exactly.

You can also enable a generic preflight checklist in QGroundControl! Go to the application settings by clicking on the logo on the top left, and the enable "Use preflight checklist". When this is enabled, the home screen will show a checklist with some important steps you should perform before a flight.

Safety

Drones are not toys, and should be handled with care to make sure no-one gets hurt. While the local regulations mentioned above improve the general safety somewhat, taking good care of your drone is also required for a safe flight. It is important to do this before every flight, since damaged or loose components can cause the drone to malfunction during flight, leading to loss of control and crashes!

Some general checks that apply to any custom-made drone:

• Check whether the propellers are mounted properly. This means that they are spinning in the right direction, and that they are mounted tightly.

  • DOUBLE CHECK that the propeller nuts are tight and they have not loosened since last use.

• Make sure that the propellers can rotate freely without touching any of the frame or wiring.

• Check that there are no loose wires that could get in-between the propellers during flight.

• Make sure that the battery is tightly strapped to the frame: it should not be able to move at all. If the battery can shift during flight, it causes the drone to get out of balance, or the battery could even detach from the drone!

• Check the battery percentage and voltage. Flight-time can drastically decrease when taking off with a lower battery percentage. When the voltage per cell is more than 4V (total voltage for 3S = 3x4 = 12V, total voltage for 4S = 16V) there should be no problem, but when the cell voltage is below 4V you should watch your battery level extra carefully during take-off.

• Make sure that you have correctly set up and configured all the settings on the FMU and the RC transmitter.

• Ensure you have calibrated and tested all your sensors before flying.

Drones and robots can be dangerous if safety precautions are not followed:

• Be very careful and follow all safety instructions and help prepare additional safety instructions and labels.

• Propellers can and will cut severely if not treated with respect. NEVER mount them until after you have calibrated and flight checked the whole system, and are ready to fly.

On the software side, PX4 also provides a lot of safety features, which can improve the safety of your flights. More on these safety features can be found here

The sensors screen lists most of the sensors that are available to the FMU (internal or external). It allows you to start the calibration process for the listed sensors. The QGroundControl user guide has all information you need about calibrating the sensors. This step is very important for stable flights, it is required to do the calibration at least once and it should be redone whenever the drone starts flying less stable!

You can check whether the sensors are properly calibrated using the Analyze widget, which can be found under Widgets at the top of the screen. This is a tool in QGroundControl that allows you to plot sensor values of sensors inside of the RDDRONE-FMUK66 in real-time.

You can check the calibration of the sensors inside of the FMU by putting the drone on a flat, horizontal surface, and looking at the ATTITUDE.roll and ATTITUDE.pitch variables. If they are larger than 0.02 (both positive and negative), you should consider recalibrating the Accelerometer, Gyroscope and Level Horizon.

Safety

After flying, make sure to disarm the drone while you are not operating it. This can be done by moving the left stick to the bottom left until the LEDs on the drone start flashing. At this point the propellers of the drone stop rotating. This prevents unwanted accidental takeoffs. It is also safer to disarm the drone at all times when it is on the ground; when the drone is armed, it could also react to movement when you pick it up, causing your fingers to be cut by the propellers. Regardless, always check that the drone is disarmed before handling it.

When you are done flying the drone, make sure that you disarm the drone on the drone-side as well before handling it: this can be done by pressing and holding the safety switch (on the GPS module), until it starts flashing slower. After this, it is also safer to have the batteries disconnected to prevent draining your batteries while moving the drone. Usually propellers are also taken off the drone after flying.

Flight log analysis

On-board log files are generated and stored on the SD card. These can be analysed using the tools and procedures shown here:

All relevant information is available in the QGroundControl documentation. Below we provide some more information about the different settings found on the Power page.

Battery Percentage

For correct display of battery percentage, you should always specify the correct number of cells in the battery (indicated by 3S, 4S, etc. on the battery). You should also calculate the value for the voltage divider to calibrate the voltage readings coming from the power module. This can be done by measuring the voltage of the connected battery using a volt- or multi-meter, and inserting the measured voltage into the Calculate Voltage Divider prompt. Together, these settings will provide you with an accurate battery percentage while the drone is idle on the ground, so you can determine whether it is still safe to take off. PX4 also has a fail-safe that prevents arming when the battery percentage is too low.

For a better indication of the battery percentage when the drone is flying, you should also calculate the Amps per volt value: this will allow the software to calculate the battery voltage based on current draw, correctly taking high-load voltage drop into account. The calculation can be performed by measuring the current through the drone when it is idle, and inserting the value into the Calculate Amps per Volt prompt. After calculating the correct Amps per Volt value, the battery percentage will also be correct during flight. This will allow you to determine how much flight-time you have remaining during flight. It also allows you to make use of more advanced PX4 fail-safes based on battery percentage, such as automatically returning home and landing when the battery percentage gets too low.

If you still have issues with incorrect battery percentages, it is possible to manually specify the voltage drop under Advanced power settings. This voltage drop can be determined based on flight logs by looking at the difference in voltage when the drone takes off.

ESC Calibration

To ensure that all motors correctly respond to commands coming from the FMU, you should perform an ESC "calibration". It makes sure that the ESCs are aware of the minimum and maximum PWM values that the FMU will provide. This can be done by pressing the ESC calibration button and following the on-screen prompts. The calibration process requires a USB connection, since it involves steps where you have to disconnect and reconnect the battery.

There are multiple modes in which you can control a drone. For each of these modes, there are different things to keep in mind. Some things apply to any flight mode, while others apply only to the more advanced flight modes. More information about the different available flight modes can be found here:

Any flight mode

• Always watch your environment during flight. Next to people and animals getting in your flight area, the weather is also very important. A sudden gust of wind can quickly blow your drone out of the sky, or out of sight! If you notice that you are unable to keep the drone stable, land it immediately to avoid damage to the drone or its surroundings.

• While you can technically fly a drone by yourself, it is always safer to have someone else with you. They can keep track of your surroundings, and watch the telemetry information of the drone, while you can be more focused on flying the drone.

• During flight it is important to keep track of the battery percentage and voltage of your drone; when the voltage gets too low, the drone will become less mobile, and eventually it will crash! Note that the lower the cell voltage, the quicker the battery will deplete. Especially at a cell voltage below 3.7 V (3S = 11.1 V, 4 S = 14.8 V), the battery percentage will drop pretty quickly.

• When you lose control of the drone, always make sure that it is safe to stop the motors mid-flight; do not engage the kill switch immediately! However, when the drone is about to hurt someone, you should enable the kill switch as soon as possible.

Assisted flight modes

Assisted flight modes are flight modes in which the drone uses more sensors in order to keep position when it does not receive any command. An example of an assisted flight mode is altitude control, in which the drone regulates its height in the air using a barometer or its height above the ground using a distance sensor. Position control is another assisted flight mode, in which the drone also keeps its horizontal position using GPS or a flow sensor.

Autonomous flight

During autonomous flight, the drone essentially controls itself. The drone can fly missions using GPS which you can configure using QGroundControl, or you can put the drone in offboard flight mode. When in offboard flight mode, a companion computer will provide commands to the drone.

Even though the drone controls itself, this does not mean that you do not have to watch your drone: during autonomous flight you should still keep clear sight on the drone, and be ready to take over when the drone loses control of itself.

This means switching back to an assisted flight mode or to full manual mode, or flipping the kill switch. Make sure you know which modes are available and how they work, and think about what you would do in case something goes wrong.

Offboard flight

When something goes wrong in offboard flight mode, you should first turn of the offboard flight mode. You should set up an offboard switch on your RC transmitter, so you can use the controller to decide whether you are in control, or the companion computer.

It is also possible to set up failsafe actions for when offboard mode fails, both with and without RC connection. Before flying in offboard mode, it is highly recommended to set up these offboard failsafes, to avoid non-expected behaviour during flight.

When you need to monitor or control the companion computer connected to the FMU during flight, you should also have someone else fly the drone.

More information about autonomous flight using offboard control can be found here:

This section provides important information about safely flying a drone. It is split up in things you should do before you fly, things to keep in mind while you're flying, and things to check afterwards.

It is recommended that you check all three sections before your first flight.

Payload, Motors and Airframe

The HoverGames drone KIT-HGDRONEK66 doesn’t have an officially specified carry weight as it is not a product, but rather a reference or evaluation tool.

In practice – with the motors and propellers we provide – is is good for about 500g payload. People have maxed it out to almost 1Kg payload.

BUT – The motors and props can be changed to larger ones, as can the batteries and even the motor controllers. Bigger motors, bigger Carbon Fiber props and optimizing the battery size vs payload all contribute to the tradeoff between lift capacity and overall flight time.

You COULD even attach a second set of four motors facing downward.

ALSO – the size of the motors / props is limited only by the frame. All the same electronics can be moved to a larger multicopter frame. You might also just be able to use longer arms on the same frame in order to get larger propellers in place. Keep in mind these modifications will change the characteristics of the ariframe, and you will want to spend time with advanced tuning to make sure the airframe performs as expected. (PID timing, resonances etc)

There are online calculators to work out payload and estimated flight time. This is a popular one:

Battery Tuning

The traditional battery current and voltage, and hence state of charge, is managed by a simple analog to digital conversion. There are scaling factors that mean you may not be getting the full energy out of your battery. In addition different batteries have different internal resistances, and react differently to temperature changes. For example, you won't get the same energy out of a battery that is operated in the cold. Some systems exist even to warm up a battery to an optimal temperature.

There are a number of things that can be done to ensure your battery readings are accurate. Follow the PX4 guide for this.

XXX <Todo> created a nice youtube video that shows how to check that scaling parameters in PX4 accurately match what is happening at the battery.

Design assembly improvements

Unboxing

Improving range of Flysky RC

Switching the device off and on

Many problems are solved by simply switching the device off and on. This goes for both the RDDRONE-FMUK66 and your computer. If you can't connect with your drone, first try to switch it on and off, and also try restarting the software you are using, or reboot your PC.

Unable to make connection from Windows computer to FMU

Windows Driver issue (old)

Originally there were some issues with the Windows driver that comes with QGroundControl. It did not recognize and support the RDDRONE-FMUK66. If this occurs again in future then once again Flashing firmware via QGC may be impossible.

Flashing firmware using the debugger should always work, even under Windows. Otherwise, it might be a good idea to setup a virtual machine with a Linux OS. The Linux version of QGroundControl does recognize the FMU, and this also works in a virtual machine if you set up the USB passthrough correctly. Note that the FMU has a bootloader which is seen as a separate device during boot, you will also have to add this device.

Windows Bluetooth COM port conflict

One of the HoverGames reported the following issue: "I had FMU communications issues recently. QGroundControl was no longer detecting FMU/Telemetry. In my case, it turned out the Bluetooth controller included in my laptop (Dell Latitude E7450) was creating UARTs COM ports conflicting with FMU/Telemetry, preventing QGC to detect the new ports. To work around this connection issue, just temporarily disable the Bluetooth in Windows 10 (for example, in the bottom right notification area menu, set the Bluetooth OFF), unplug FMU or Telemetry cables, then restart QGroundControl."

The FMU is not booting

Make sure there is actually a bootloader on the board, and that the firmware is working correctly. When first powered on the Bootloader will flash the yellow LED while in bootloader mode. If you are having difficulty you can follow the flashing instructions, and re-flash both the bootloader and firmware using the debugger.

The FMU is not receiving power through its USB port

Check if you can power the FMU at all. If the FMU works fine when the battery is connected, but not when only USB is connected, it could be that fuse F3 is blown. Please see the page about the fuses on the RDDRONE-FMUK66 board.

ESC calibration does not work or motors don't work properly

If the motors are not spinning at the right speed, or are not reacting properly to changes in the throttle input coming from the controller, there are quite a few things to check.

Check the electrical connections, see if the bullet connectors coming from the motors are completely plugged into the ESCs, and check if the ESCs are soldered in the right way and if they receive power.

Also make sure to check your RC configuration on both the transmitter (controller) and the FMU. Also check with the information in the radio tab in QGroundControl if the signal is properly received.

Testing the PWM output, ESC, motors manually

The airframe must be set, and to get accurate results the motor calibration should be completed. After ensuring the propellers are removed for safety, from the console you can issue the following commands to directly test and exercise the PWM outputs:

• The fmu test command will sweep all the PWMS up and down repeatedly

>fmu test

• The pwm command will let you individually control the pwm output channels as configured by your specific airframe and mixer settings.

>pwm test -c 1234 -p 1300

>pwm -test -c 24 -p 1630

You can use the -c parameter to select which channels you want to use. With the -p parameter you can select the pwm value.

Unable to establish a MAVLink v2 connection in some cases

It was reported that MAVLink v2 is not always used when it should. By default, PX4 uses MAVLink v1, unless v2 is supported and requested to be used by the connected device.

A possible solution is to set the MAV_PROTO_VER parameter to 2, to force all MAVLink connections to use MAVLink v2. Note that this makes it impossible to use devices that only support MAVLink v1!

Vibration management and improvement

Unable to solve your problem?

NXP sells the complete drone kits and separate FMU modules and telemetry radios. The list of components available directly from NXP is available here:

Many other parts are commonly found at hobby shops or on online retailers. Some suggested sourced are listed in the following pages. In addition many parts or upgrades can be fabricated or 3d printed.

It's recommended to buy jumper wires with pre-crimped contacts and connector housings. You can easily insert the jumper wires into the connector housing.

Jumper wires with pre-crimped JST-GH contacts

• 2 inch, black: Digikey

• 4 inch, black: Digikey

• 6 inch, black: Digikey

• 8 inch, black: Digikey

• 10 inch, black: Digikey

• 12 inch, black: Digikey

JST-GH connector housings

• 2 pins: Digikey

• 3 pins: Digikey

• 4 pins: Digikey

• 5 pins: Digikey

• 6 pins: Digikey

• 7 pins: Digikey

• 10 pins: Digikey

Practice makes perfect

As is often the case, practice makes perfect. When you are flying a drone for the first time, it's not going to be easy and you will make mistakes. As you grow more confident and get more familiar with the controls and the different flight modes, you will be able to fly quicker and more aggressive.

PID tuning

While the default values should be a good starting point, the controllers that are part of PX4 are not perfectly tuned for every drone. Some improvements are always possible, but are probably not needed unless you are using the drone in more extreme situations, or when you are doing more advanced flying.

The default PID values for the S500 airframe preset are listed below:

MC_ROLL_P 6.5
MC_ROLLRATE_P 0.18
MC_ROLLRATE_I 0.15
MC_ROLLRATE_D 0.003
MC_PITCH_P 6.5
MC_PITCHRATE_P 0.18
MC_PITCHRATE_I 0.15
MC_PITCHRATE_D 0.003

The PX4 user documentation has a multicopter tuning guide that will be useful if you decide to do your own PID tuning.

Use GPS as primary altitude source

You may want to try using GPS as the primary altitude source instead of the barometer (pressure sensor). The result is still fused between the two. Depending on your GPS accuracy it might improve the altitude control of your drone. To set GPS as the primary altitude source, set parameter EKF2_HGT_MODE to GPS.

There are many local and online sources for replacement parts for items that might get broken over time. These sources are only suggestions, and should not be considered an endorsement of any specific company.

ReadytoSky LJI X4 500 quadcopter drone frame kit

Motors

Propellers and propeller nuts

Propeller balancing equipment

The propellers coming with the HoverGames kit (the same as provided in the links above) can sometimes have balancing issues: one blade can be heavier than the other, which could cause unwanted vibrations. This inbalance can be removed by adding or removing weight from one of the propeller blades (sticking tape underneath the blade or by sanding it down).

To check the balance of a propeller, you can use special propeller balancing tools, which can show you whether one of the propeller blades is heavier than the other. Some people have used very basic setups, such as an iron nail. Others have used dedicated propeller balancer shafts such as the one linked below.

Now it's your turn

In the "user guide" part of this GitBook we showed you step-by-step how to build and configure your drone. However, now it's your turn. You have to pick your own tools and make your own plans for what comes next. This "developer guide" will not be a step-by-step tutorial for writing your own software for your drone, but it should still give you some idea of where to start. We aim to provide you with all the resources that you need to start learning about the PX4 software architecture and how to extend it.

Remember that you can always ask questions on the PX4 Discuss forums and the PX4 Slack and the PX4 GitHub. Also don't forget about the PX4 User Guide and the PX4 Developer Guide, they should be the first place to look for further information.

Extending PX4 or adding a companion computer

Developing new features for your HoverGames drone can be done in different ways. It is possible to add new modules directly into the PX4 Autopilot software. You can also send commands to PX4 Autopilot from a companion computer. These options will be discussed below. You can also keep it simple and run your software on a separate microcontroller (or processor) that does not communicate with the FMU, but keep in mind that this limits the usefulness of your project.

Ultimately, you are free to do whatever you want, as long as you stay within the requirements of the challenge. You can combine different approaches for developing your application, or come up with your own approach to realize new functionality on the drone. Be creative.

Adding modules into the existing PX4 Autopilot architecture can be quite challenging, but does not require extra hardware. The Kinetis K66 on the RDDRONE-FMUK66 is a fairly powerful microcontroller, but you cannot compare it to the processor in your personal computer. Resources (RAM, processing power) are limited and your own modules have to share this with the rest of the PX4 Autopilot software. When building more advanced applications, you might have to learn more about the PX4 software architecture and embedded software in general.

The PX4 Developer Guide has some resources that will help you get familiar with the PX4 architecture, as well as writing your first module/application within PX4.

Another (often used) option is to send commands to PX4 from a companion computer that is also on the drone. The main advantage of a companion computer is that you do not have to worry as much about the already existing PX4 software architecture. You can build your application however you want without worrying that you are affecting the performance of the flight controller. There are some software packages available that allow you to communicate with PX4 from a companion device.

The NavQ companion computer was developed by NXP with the HoverGames in mind. We recommend it for new developers that want to get started with a first companion computer. Another possible option is to use a NXP Rapid IoT Prototyping Kit with a special adapter board, but note that it has "only" a Kinetis K64 microcontroller and not the powerful i.MX 8M Mini microprocessor that is available on the NavQ.

The PX4 Developer Guide provides some information about the use of companion computers.

Development tools

This developer guide provides instructions for setting up and using the recommended development tools. You will need them to write, build, debug and program software for PX4, RDDRONE-FMUK66 and the HoverGames drone. You can either download a preconfigured environment with most tools already installed, or you can setup your own environment from scratch (which might be educational as well).

Building and programming software

We have pages that explain how to build the bootloader and firmware from source using the console instead of an IDE. A guide to programming the binaries onto the FMU using the J-Link debugger is also available.

Learn Git

If you have not worked with Git before, you should really learn the basics before you continue. Git is a very popular version control system and you will probably have to use it a lot when developing your own software for the HoverGames drone. The PX4 Autopilot source code is hosted on GitHub, a Git-based software hosting platform. You have to use Git to retrieve the original source code, but also when you want to publish your code and contribute to the PX4 project.

The Git source code management page provides all the resources you need to get started with Git and GitHub. It is an essential tool and you really should spend some time on it.

Learn C/C++

Most PX4 code is written in the C and C++ programming languages. If you are not familiar with these languages, it will be useful to follow a few tutorials and read about the basic concepts. There are many great books, courses and tutorials available for learning these programming languages.

These are some useful websites to get you started:

• https://isocpp.org/

• https://www.learncpp.com/

• https://www.codecademy.com/learn/learn-c-plus-plus

• https://www.learn-c.org/

• https://www.learn-cpp.org/

These two Stack Overflow posts provide lists of the best C/C++ books:

• https://stackoverflow.com/questions/562303/the-definitive-c-book-guide-and-list

• https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list

Most of the popular tools that you can use to develop software for the HoverGames drone kit are best supported under a Linux operating system. Therefore it is strongly recommended to either use a native Linux setup, or a virtual machine (VM) running Linux on top of a Windows (or Mac) operating system. Using a VM instead of a native setup comes at the cost of processing power and flexibility, but should not be a big issue if you have a modern computer.

Ubuntu and VirtualBox

It is strongly recommended to use a recent Ubuntu LTS (long-term support) version as the basis of your development environment. It is a beginner-friendly Linux distribution that is widely used for software development. Most of our required tools are guaranteed to work on recent Ubuntu versions. As of August 2022, the PX4 Autopilot build system supports Ubuntu 18.04, Ubuntu 20.04 as well as Ubuntu 22.04. We strongly recommend to use Ubuntu 20.04 because it is also supported by most NXP tools, though all instructions have also been tested with Ubuntu 22.04. Use of another Linux distribution or Ubuntu version may give some unexpected issues.

You can download the "desktop image" (.iso file) for free from the Ubuntu website:

VirtualBox is a beginner-friendly and cost-effective package for creating and running virtual machines, because it is also an open source project and available free of charge. As of August 2022, the latest version is VirtualBox 6.1.36. Please install VirtualBox and all of its components on your computer before you continue.

Creating the virtual machine

Open VirtualBox and create a new virtual machine using the blue "New" button at the top of the screen, or using the "New..." option under the "Machine" tab. Fill in a descriptive and easily recognizable name for your virtual machine, such as "NXP HoverGames" or "NXP Mobile Robotics". The default machine folder location should be okay, but may be changed if you want. The type should be changed to Linux and the right version is Ubuntu (64-bit).

Set the memory size to at least 4096 MiB, assuming you have at least 8 GiB of RAM available on your computer. It is recommended to allocate even more memory to your virtual machine if your computer has more RAM installed. For example, if your computer has 16 GiB RAM, you can usually allocate 8 GiB (8192 MiB) to the VM without issues. More allocated memory generally means a more responsive virtual machine and quicker software builds. Less than 4096 MiB might work, but your VM will probably be very slow.

The next window will ask you to add a virtual hard disk. Choose the option to create a new one. The default VDI file format is fine, and it is a good idea to make it dynamically allocated. You can keep the default name. Please increase the size of the virtual hard disk to at least 60.00 GB. This will be the maximum amount of space that the virtual hard disk may (eventually) use.

Virtual machine settings

Select your newly created virtual machine and click the orange "Settings" button at the top of the screen, or the "Settings..." option under the "Machine" tab.

Under "General", go to the "Advanced" tab. Enable the shared clipboard and set it to bidirectional. It allows you to easily copy and paste text between your host and guest operating systems. You may also enable the drag'n'drop feature, but this has not been the most stable feature of VirtualBox. It is easier to work with a shared folder, which we will create later.

Under "System", you can go to the "Processor" tab. Assuming your CPU has at least 4 cores, you should add at least a second core to your virtual machine. If your CPU has more cores you can even consider to add a third and a fourth. This will generally make your virtual machine more responsive and speeds up software builds tremendously.

Under "Display", you can increase the video memory. You usually want to set this to the maximum value available, but any value within the green range should work well. The green range is the recommended range based on your computer hardware and the selected guest OS.

Under "Storage", select the empty disk drive in the middle of the window, then click on the small disk icon on the right side of the window and look for the "Choose a disk file..." option. Then find the Ubuntu .iso file you downloaded before. The right file might also be listed in the menu already!

If you have the VirtualBox Extension Pack installed, you can select the USB 2.0 or USB 3.0 controller under "USB". Otherwise you will be stuck with the USB 1.1 controller, which should be fine as well. The USB 2.0 controller is the default option when the extension pack is installed, but you may opt to select the USB 3.0 controller if you want to use superspeed USB devices.

While you're at this screen, consider to add some filters for the USB devices that you will be using. This allows the virtual machine to access these devices whenever they are plugged into your computer while the VM is running. Note that these devices will then not be available on your host operating system. You can also add filters at a later time or pass through USB devices manually.

To easily add a device filter, make sure the device is plugged in and click on the icon with the "+" sign. It is recommended that you add filters for the FMUK66, the J-Link debugger and the USB-UART cable.

For just a few seconds after you plug in the FMU, the "NXP SEMICONDUCTORS PX4 BL FMUK66 E" device will be available in the list. This is the bootloader. After a few seconds, this device will disappear and "NXP SEMICONDUCTORS PX4 FMUK66 E" will appear. Note that this is only the case if the FMU already has a bootloader and firmware installed!

Make sure to add filters for both the FMUK66 bootloader and the "standard" FMUK66 device. If you don't see the bootloader device in the list, make sure the FMU is not powered by anything else than the USB cable. Plug the USB cable in again and quickly click the icon while the bootloader is still active (orange LED on the FMU will blink). You have to do this quickly!

Also, make sure to plug in the debugger and USB-TTL-3V3 cable and add filters for "SEGGER J-Link" and "FTDI TTL232R-3V3" (or a name that looks similar). Be aware that the telemetry radios may also present themselves as a FTDI USB UART device if you have one connected to your computer! Their product number should be slightly different, but it's better to disconnect them to avoid confusion.

The list should look similar to this:

Under "Shared Folders", we can also setup a folder that will be accessible on both your host and guest operating systems. Please create an empty folder on your host operating system. The folder name should be short and clear. This name will be used to identify the folder in the guest operating system (Ubuntu). You can also enable auto-mount. This will make sure that the shared folder is automatically mounted after the virtual machine has booted, but first we have to install the OS including guest additions.

You can now press the green "Start" button to run your virtual machine. You may be asked first to select the right boot disk, make sure you select the Ubuntu image. The VM should then start and boot from the provided .iso disk image, starting the installation process for Ubuntu. We will continue on the next page and guide you through this process.

To start building PX4 Autopilot from source, you should first install the PX4 toolchain. This provides you with all the tools required to develop, build and debug PX4 Autopilot, but the same tools may also be used for other software projects, such as Apache NuttX.

These tools can be installed for various operating systems, but are best supported for Ubuntu. Some tools or features may not work if installed on different operating systems. Therefore we recommended to install Ubuntu either natively or inside a virtual machine. The step-by-step instructions below will be specific to Ubuntu 20.04 (or 22.04) and may not work if you are using a different OS.

Install Git

The minimal installation that we selected does not include Git by default. Git is a very popular distributed version-control system and you will probably use it a lot when developing software for the HoverGames. It will also allow us to easily download ("clone") the PX4 code because it is available on GitHub, which is a Git-based source code hosting platform.

So let's install Git using the following command:

Download the PX4 source code

Before we install any tools we will download the PX4 Autopilot source code. The PX4 developers have included a script with their source code that makes it much easier to install all required tools. Let's first create a folder to hold all sourcecode that we are going to work with. The following command creates the "src" folder in the user's home folder (if it doesn't exist already):

The next step is to actually download the source code. We will use Git to create a local copy of the online repository that is hosted on GitHub. The following command first changes the working directory to the "src" folder that we just created, then it will "clone" the whole PX4 Autopilot repository, including submodules, in a new "PX4-Autopilot" folder.

Note that it will take a while to clone the whole repository. The PX4 source code should now be available in the ~/src/PX4-Autopilot folder. The tilde represents the current user's home folder within the file system. You can also browse to this location with the file manager.

Install the toolchain

As already mentioned, the PX4 developers provide a bash script to easily install all the tools that you need to build the PX4 firmware. We already cloned the PX4 source code, so we can just change our working directory and run the script:

You should reboot the (virtual) machine after the installation is done.

Make your first PX4 build

Make sure to reboot your computer after the toolchain installation is finished. Then change your working directory to the PX4 Autopilot repository again and start a build for the FMUK66E using the following command:

If you still have the older FMUK66 Rev. C or Rev. D then you should use a slightly different target:

Installer options

When you boot your (virtual) machine for the first time you will be greeted by a screen that asks you to try Ubuntu first or directly install it. You can select a different language, if you want, though it is recommended to stick to English if you want to follow along with these instructions. Then press the Install Ubuntu button to start the install procedure.

Keyboard layout

If desired, you can change the keyboard layout. Note that the standard US layout is also often used in other countries. You can test if the setting is correct by typing some (special) characters in the field at the bottom of the screen.

Updates and other software

We recommend to do a minimal installation. This will only install a minimal amount of additional software. Especially for users of a virtual machine this will help to keep the amount of occupied disk space low. It is also useful to already install updates and third-party drivers, as you would need to do this anyway after Ubuntu has been installed.

Installation type

If you are installing Ubuntu within a virtual machine you can safely choose to erase the disk and install Ubuntu, as this will only "erase" your virtual hard disk image and not your actual hard drive. For a native setup you should consider whether you want to erase your disk or shrink the existing partition(s) and put Ubuntu on a second partition. After pressing "Install Now", you might get a pop-up that asks you to confirm that you want to write the changes to the disk, just press continue. After that, you might have to wait for a few minutes.

Where are you?

The next screen will ask for your location/timezone. It should already provide a default location, which will probably work fine. If it does not match your city our country at all you can select one yourself.

Who are you?

Finally, you will be asked to set up a user account. You can pick a name with which you want to be addressed by the system, for this example we will use "NXP". For compatibility reasons we suggest to use a strictly lowercase computer name, for example "nxpdev". If you are using a virtual machine you can just choose a simple username and password to make it easy to use, such as "nxp". You can also select the option to log in automatically for convenience. However, if you are installing Ubuntu on native hardware you should use a proper username and password combination, to keep your system secured.

It will take a while to finish the installation. You might be asked to restart the (virtual) machine after the installation is finished, just restart it immediately using the button. During shutdown, Ubuntu might also ask to remove the installation medium. You can ignore this when installing inside a virtual machine and immediately press enter on your keyboard.

First boot

When the system reboots, you will be greeted by a screen that asks you to connect to your online accounts. You can just skip this for now, as well as the next few tabs, until you are asked to help improve Ubuntu. You can choose to not send system info, if you don't want to. Then just continue until you are done and see the desktop.

You might also get a popup from the software updater. It is recommended to install these updates now. You will most likely be prompted to enter your password. After the updates are installed you get asked to restart again, which you should do before we continue.

Install (even more) update

After the reboot we will (again) check for and install updates. Open a terminal window by going to the launcher menu (the icon with the 9 dots at the bottom of the dock) and search for the terminal application. Once you have it opened, don't forget to right click the terminal icon on the dock and add it to your favorites - you will be using the terminal much more often! You can also right click and remove the "Help" and "Ubuntu Software" icons from the dock, because you will probably not use them much. You can always find them again in the launcher menu.

We should first update the package lists of the apt package manager with the following command:

The term "sudo" stands for "superuser do" and runs the command that follows with superuser privileges (administrator). You will probably be asked to enter your password. The terminal does not show your password while you type it, so it might seem as if nothing is happening, but just enter your password and press enter.

After the package lists have been updated, you will probably find that there are some updated packages available. We can install these updates with another command:

It will show you a list of packages that are going to be installed (not necessarily the same as shown in the screenshot below) and asks if you want to continue. You can press enter to select the capitalized default option ("Y" for "yes"). Now it might take a while to finish.

VirtualBox users: install Guest Additions

We will now install the "VirtualBox Guest Additions", which are some packages that will provide better integration between your guest OS and host OS. Open a terminal and enter the following command:

You will probably be asked again whether you want to install the listed packages. You can just press enter to continue. It might take a while to install.

Go to the "Devices" menu and click on "Insert Guest Additions CD image". It will ask you whether you want to run the software, and may ask you to enter your password. It will then open a terminal window and start the installation.

Wait until the installation has finished and close the terminal window. You can then eject the guest additions disk image by right clicking on the icon on the desktop and selecting the eject option. Now that the guest additions are installed you should be able to maximize the virtual machine window, and the resolution of the Ubuntu desktop should scale with the window size. The shared clipboard should work as well. You might have to reboot the virtual machine again if it is not working.

VirtualBox users: setup shared folder

This will give you access to the shared folders. You might get asked for your password. You possibly have to reboot before it becomes active. If after a reboot the shared folder is still not visible from the file manager, you should check the virtual machine settings if the shared folder has auto-mount enabled.

Several 3D printable models for the HoverGames drone . Search terms such as "RDDRONE-FMUK66", "NXPhlite" or "HoverGames" should pull up most files. They are also listed below. Please also use these terms for tags if you publish anything yourself.

Also, you may also find interesting accessories by searching for "S500" or "LJI X4"

RDDRONE-FMUK66 Rev. C FMU case

Debugger adapter board case

RC receiver antenna bracket

Improved landing gear T-connector

Improved landing gear parts

Note that the improved landing gear T-connector above is based on the T-connector included with this design. From this one, you should only use the part that connects the landing gear to the body of the drone.

Original style landing gear T-connector

Rapid IoT bracket

RC transmitter stick and switch protector

Battery balance lead protector clips

Protective outer dome/shield

You may have to drill or cut access holes for the GPS or telemetry antenna

Pre-built bootloader binary

It is not (always) required to build the bootloader youself. We provide a pre-built bootloader binary on the Downloads page:

Building the PX4 bootloader from source

To build the bootloader, you will need the , which you should have setup in your development virtual machine. When the toolchain has been installed, you can run the following commands in the command line tool available on your operating system or installed through the development toolchain.

• First, clone the PX4 bootloader repository: git clone https://github.com/PX4/Bootloader

• Then, change your working directory to the just cloned repository: cd Bootloader/

• Synchronize submodules: git submodule sync --recursive

• Update the submodules:git submodule update --recursive --init

• Build the RDDRONE-FMUK66 PX4 bootloader: make fmuk66v3_bl

The bootloader is now available under Bootloader/build/fmuk66v3_bl/fmuk66v3_bl.bin

Updating your local clone of the PX4 Bootloader repository

In case you already have the bootloader repository cloned, you can pull in the most recent changes and rebuild the bootloader binary. Open a console and go to your local clone of the PX4 Bootloader repository

If you want to checkout another branch, or switch back to master branch, you can do that first.

• Fetch available branches in the remote (online) repository: git fetch

• Checkout another branch: git checkout branchname

Now make sure your local repository is up-to-date with the latest upstream changes:

• Pull in new changes: git pull

• Synchronize submodules: git submodule sync --recursive

• Update the submodules:git submodule update --recursive --init

You can now rebuild the RDDRONE-FMUK66 PX4 bootloader: make fmuk66v3_bl

Writing the bootloader

It is required to setup a Linux-based* development environment, preferably based on Ubuntu 20.04 (or 22.04). If you are not running a Linux OS already, you can consider to install Ubuntu natively besides your Windows setup (dual-boot), or on a separate laptop. Another convenient option would be to use virtualization to run Linux on your Windows computer. There are plenty of tools available, such as Oracle VM VirtualBox, VMware Workstation and even the built-in Windows Subsystems for Linux (WSL).

The next pages will provide step-by-step instructions on how to install Ubuntu 20.04 (though all instructions should also apply to Ubuntu 22.04 as well) with a proper toolchain to develop, build and debug Apache NuttX and PX4 Autopilot for RDDRONE-FMUK66 (Kinetis K66 MCU) as well as other NXP Mobile Robotics platforms.

The first part of the instructions will also explain setting up the VirtualBox software for creating and running a virtual machine. NXP does not specifically endorse VirtualBox, but it is a free open source tool and it is a convenient way to start using Ubuntu as a beginner. More advanced developers may install Ubuntu natively or use different virtualization tools (e.g. VMware, WSL2).

The next step will explain how to install the Ubuntu Linux operating system. We will also download and install the PX4 toolchain, which should provide all the tools already to build your own PX4 firmware binaries from source. The same tools can also be used to build Apache NuttX, which is the Real-Time Operating System (RTOS) that is used by PX4, but can also be used stand-alone.

Finally, we will install NXP MCUXpresso, an integrated development environment (IDE) which allows you to edit, build and debug software for many NXP microcontrollers and processors. The instructions will explain how you can setup a project to build and debug PX4 Autopilot.

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:

/****************************************************************************
 *
 *   Copyright (c) 2012-2016 PX4 Development Team. All rights reserved.
 *   Copyright 2019 NXP.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 * 3. Neither the name of the copyright holder nor the names of its 
 *    contributors may be used to endorse or promote products derived 
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
 * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
 * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
 * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
 * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
 * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 *
 ****************************************************************************/

/**
 * @file hg_led.c
 * Minimal application for led control
 *
 * @author Leutrim Mustafa
 */

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.

#include <px4_platform_common/px4_config.h>
#include <px4_platform_common/posix.h>
#include <unistd.h>
#include <stdio.h>
#include <poll.h>
#include <string.h>

#include <uORB/uORB.h>               // asynchronous messaging API used for inter-thread/inter-process communication
#include <uORB/topics/led_control.h> // uORB for led_control

Main function

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

__EXPORT int hg_led_main(int argc, char *argv[]); // Export main for starting in another thread

int hg_led_main(int argc, char *argv[])
{
    PX4_INFO("Hello Hovergames LED");

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.

    // Create structure to store data in
    struct led_control_s led_control;

    // Clear the structure by filling it with 0s in memory
    memset(&led_control, 0, sizeof(led_control));

    // Create a uORB topic advertisement
    orb_advert_t led_control_pub = orb_advertise(ORB_ID(led_control), &led_control);

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:

    led_control.num_blinks = 10; // Blink 10 times
    led_control.priority = LED_CONTROL_MAX_PRIORITY; // Set our app to max priority
    led_control.mode = LED_CONTROL_MODE_BLINK_NORMAL; // Set the LED mode to blink
    led_control.led_mask = 0xff; // Select all LEDs
    led_control.color = LED_CONTROL_COLOR_GREEN; // Set color to green

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.

  • in practice, max priority is reserved for things like error LED sequences.

• mode : We set the mode to LED_CONTROL_MODE_BLINK_NORMAL for a normal blink sequence.

• led_mask : We set this to 0xff which tells the led controller to blink all LEDs. (FYI - This parameter is used in *some* custom LED drivers to allow a variety of LEDs to be controlled with uORB message. For example - LEDs located on each of the motor pods that change color in flight to indicate direction of forward travel. Technically it is not fully implemented in the standard PX4 LED driver.

• color : Set to LED_CONTROL_COLOR_GREEN ! If you'd like to set it to a different color, feel free!

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:

    orb_publish(ORB_ID(led_control), led_control_pub, &led_control);

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.

    PX4_INFO("Hovergames LED exit");
    
    return 0; // return of main function
    
}

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.

Thanks to Dobrea Dan Marius who prepared this guide for C++ and Python interface & management application for FMUK66

https://www.hackster.io/mdobrea/c-and-python-interface-management-application-for-fmuk66-6dd935

Git basics

Git is one of the most popular tools to manage source code and keep track of changes. It is also a great tool to prevent conflicts when working together in a team. If you are not yet familiar with Git, we strongly advice you to learn the basics. Git is used for managing many open source software projects, but it is also used extensively in corporate environments. It is an invaluable tool for anybody working with source code.

There are already plenty of resources available on the internet to learn Git, therefore we will not repeat the basics here. The official Git website provides a complete e-book for free, as well as some introductory videos. You can also use the (interactive) tutorials by GitHub and Atlassian Bitbucket. Last but not least, this blogpost by Nico Riedmann also provides an excellent overview of the most important Git concepts.

The sections below will try to address some practical issues and more advanced concepts that you might run into when developing software for HoverGames. Keep in mind that you can always have a look at the Git reference in case you "feel lost".

Command line or graphical interfaces

Git is a command line tool, however there are graphical interfaces available. If you have worked with graphical user interfaces for years, it might be attractive to install a graphical interface for Git as well. However, a graphical interface will just be a layer on top of the Git commandline and you will probably not understand what is really going on behind the scenes. Also, once you learn to use the command line properly you will see that it can be much quicker to use and it has some very powerful tools that are often not available in any GUI.

The commands can be hard to memorize at first, but remember that you can always look at the Git reference. At the top of the reference page there are also links to cheat sheets that list the most important commands. A web search will also quickly provide you with the right commands and hopefully also some explanation as to why you need to use that specific command.

Initial configuration

After installing Git there is some additional configuration needed. If you are using a GUI tool this configuration might be taken care of automatically or you will get a popup. However, most people will be using the command line and need to do this configuration by themselves.

The first and most important thing you need to do is set your name and e-mail. All your commits will be linked to this name and e-mail. Initially your commits will only be local (on your own computer), but if you start pushing commits to remote repositories, your name and e-mail will also be published with these commits.

You can configure your name and e-mail with the following two commands (replace with your own name/e-mail):

git config --global user.name "John Smith"
git config --global user.email "johnsmith@example.com"

It is possible to avoid "leaking" your e-mail address if you want to keep it private. GitHub is one of the largest Git-based code sharing platforms and many of the remote repositories that you will work with are hosted on GitHub. GitHub offers the option to use a special "noreply" e-mail if you create a free account.

It is also convenient to tell Git what "core" editor you want to use. This can be a very simple text editor like Gedit or Nano on Ubuntu, or Notepad on Windows. A full IDE is usually not needed, as Git will only use this editor for simple tasks like entering commit messages. You can still use any other editor (with more features) to write and debug your code.

You can configure Gedit as your core editor with the following command:

git config --global core.editor "gedit --wait --new-window"

On Linux you can just provide the command that would start the editor. On Windows you usually need to provide the full path to the executable. There is a list available with commands for different editors.

More information is available on the "first time Git-setup" page in the Git documentation.

Different Git workflows

Git can be used in different ways and many teams have their own workflow. Atlassian Bitbucket offers a great overview of some different Git workflows. It will give you some insight in how Git can be used to work together on a larger software project.

The PX4 Developer Guide explains the most used workflow for contributing to PX4 Autopilot. It is based on the GitHub flow. The PX4 documentation explains their basic branching model and code formatting, as well as Git examples that show you how to clone a forked PX4 repository, how to pull newest commits from the upstream master and more. This is a great starting point for most people.

Sharing is caring - but what to share with the community?

PX4 and Dronecode are very important for the HoverGames. Most participants will work extensively with the PX4 Autopilot software and extend it with their own software. It would be great if changes and additions that could be useful to other people are shared with the PX4 community. Think about:

• Bug fixes!

• Drivers for new components!

• New features

• Exciting ideas

Even if you think that your work is not ready to be merged into the main PX4 repository, consider creating a (draft) pull request or issue on the PX4 GitHub to at least make the developers aware of it. You can also ask the core development team on Slack what they think about your fix/addition/idea and what would be the next steps to get it merged.

Most teams will probably also create some software that is very specific to their use case. It might not really be possible or useful to share all these software additions, but you can always start the discussion on PX4 GitHub, Slack or Discuss to learn what would be good additions to the main PX4 project.

Working with multiple Git repositories

The PX4 Autopilot source code is hosted on GitHub, and it is recommend that you make your own PX4 fork on GitHub as well. You can do this under your own GitHub account, or you can fork the repository under an organization. You can create an organization on GitHub for free as long as your repositories remain open source. Using a repository under an organization allows multiple people to manage the same repository, but you can also work together on a personal repository.

However, there might be cases where you want to keep (some of) your code private. It is recommended to still have a public fork which you can use to publish bugfixes and changes that you want to merge back into the main PX4 repository. You can setup a second, private, online repository on websites like GitHub or Bitbucket to hold the code that you want to keep hidden from the general view.

The graph below shows an example of the different repositories and the flow of data once everything is set up. In general, the local repositories of the individual team members (users) are the starting point of all changes. They add their own code, but also pull in changes from the shared repository (a private Bitbucket repository in this case) or from the upstream PX4 Firmware repository. They publish changes (new code, or pulled changes from the upstream repository) to a private Bitbucket repository.

When something is ready to be made publicly available, it can be pushed to the public GitHub repository as well. From this public GitHub repository you can then create a pull request to the main PX4 repository to ask them to merge your changes.

For a team that is not using a private repository, their public GitHub repository will be the place to share code within the team. This simplifies the graph (and the workflow) significantly. You only have to keep track of the code changes in one place, and you can directly create pull requests from your main repository to the "upstream" PX4 repository.

Note that if you are working alone, you will still have your local repository, your online repository on GitHub and the upstream PX4 repository. That also means that you can easily start working together at any time. The whole setup with different repositories does not really change, except that each user has their own local repository.

Setting up your repositories

Forking the PX4 Firmware repository on GitHub

The first step is to create a fork of the PX4 Firmware repository on GitHub. Create a GitHub account if you do not have one, and go to the official PX4 Firmware repository. Press the "Fork" button on top of the page and fork the repository under your own account or under an organization. You can click your profile picture and go to settings and then create a new organization if you want.

Cloning the repository on your computer

You now have a your own public fork of the PX4 Firmware, but to actually make changes you want a local clone of the repository. To clone your own repository from GitHub, enter the command below in the command line. The URL specifies the location to the online repository that you want to clone. Usually it is of the form shown below, but with your own username.

git clone --recursive git@github.com:johnsmith/Firmware.git

You can also get the right URL for your repository by pressing the green "Code" button on the main page of your forked repository (NOT the original PX4 repository). Make sure to press the small "Use SSH" link in the corner, because it will probably default to "Clone with HTTPS".

After you enter the command it will take a while to download all files and setup the local repository.

Generating an SSH key

When you want to push changes to a GitHub repository, you will be asked for a password and it will be checked if you have permission to make changes to the online repository. If you have a private repository, authentication is also required when you clone the repository or pull changes.

An SSH will make authentication very easy (and secure)! We strongly recommend you to generate an SSH key and add it to your GitHub account. It requires a few extra steps but will make your life much easier. GitHub has an excellent step-by-step guide on how to generate and add an SSH key. Make sure that you select "Linux" at the top of the page if you are using Git within the Ubuntu virtual machine.

Setup an extra private repository

It is not required, but some people might want to use a private repository to create an online backup of their code or share it between different team members without giving the whole world access. For example, you could setup a private repository on Bitbucket.

It might be possible to "import" an online repository directly. You can use this option to make a direct copy of your public GitHub repository. You can also create an empty repository and push the code into it from your local repository, which we will do here, because this option is always available.

When the local repository was created ("cloned"), the original GitHub repository was automatically set as the standard remote repository named "origin". We will change this now to your private repository, because this is usually your default repository that you want to push to. You need to replace the URL with the URL your new (private) repository.

git remote set-url origin git@bitbucket.org:johnsmith/gestures.git

You can now push the code that you downloaded from your public repository into your private repository by using

git push --all origin

You will be asked for authentication. If you have issues with this, please refer to the documentation of the service (BitBucket, GitHub) you are using. If you generated an SSH key you can easily add it to your account on the service that you are using.

You should add the public repository again as a remote repository as well. This will allow you to easily push changes to the public repository, for example when you want to open a pull request at the upstream PX4 repository. We'll call it "public". Make sure you use the URL of your own repository:

git remote add public git@github.com:johnsmith/Firmware.git

Add upstream remote repository

For convenience, we will also add the upstream PX4 repository. This will allow you to easily pull in changes from the upstream repository, which you can push to the repositories of your team (public and/or private) if required.

git remote add upstream https://github.com/PX4/Firmware.git

Branches

In a Git repository, usually different branches are used to develop different features in parallel or to separate stable versions of the code from code that is still being developed. PX4 uses the "master" branch as their main version of the code. Features are developed in different branches and merged into master when they are ready. (Approximately) every 6 months a new major stable release will be created from the code in the master branch.

When you forked the official PX4 repository, you made a copy of all code revisions and branches up to that point in time. It is recommended that you make new branches (branching off from your copy of master) for your own features. You can keep pulling in commits from the official PX4 repository to keep your own repositories up-to-date with the upstream master branch. Note that you first have to apply changes to your local repository and then push these changes to your shared repositories.

What we recommend is to set up at least two branches. Master should correspond to the upstream master branch, you can pull changes from the official PX4 repository into this branch. Your own work should be kept in a development branch, consider this your own main branch. From this development branch, you can branch off again to develop different features, and merge them back into the development branch when they are finished. At the same time, you can also pull in changes from master if desired. This is summarized in the graph below.

The following command will create a new branch "hovergames_feature" and checks it out as your current working branch.

git checkout -b hovergames_feature

Prepare a commit

git add file
git commit -m "Commit message"

Setup default remote branch and push

git push --set-upstream origin hovergames_feature

From now on, for this branch, you can directly push to your main remote repository (origin) with the command:

git push

If you have both a public and a private repository, you can also push to the public repository by specifying its remote name and branch name. The following commands pushes the changes to the remote that we defined as "public".

git push public hovergames_feature

Pull requests

A pull request is a request to merge the changes made in a certain branch into another repository or branch. This is not a Git feature, so it is not available in your local repository, but it is a tool in online services such as GitHub and BitBucket. It allows discussion and additional explanation of the changes before they are actually merged. More information is available in the GitHub documentation and the Bitbucket documentation.

The official PX4 Firmware repository uses pull requests to manage all contributions to their source code. Anybody that wants to make any changes to PX4 has to create a pull request so the core development team can review and discuss the changes. If you ever have any changes or additions that you want to contribute to the main PX4 project, you should put them on separate branches (split different features and bugfixes to make it easier to review) on your own public fork of PX4. Then you can directly create a pull request from this branch on your own repository to the PX4 master branch.

Resources

• Git Documentation

• GitHub.com Help Documentation

• GitHub - Resources to learn Git

• Atlassian Bitbucket Documentation

• Atlassian Bitbucket - Getting Git Right

Presently we re-use the standard power adapter from PX4 products. We are working to supply one with the correct JST-GH end already applied.

Power modules include a regulator to adapt from 2S (7.4V), 3S (11.1V), or 4S (14.8V) battery input and provide +/- 5.3V power to the FMU. Some power adapters may allow higher input voltages. In addition to power regulation it includes signals for voltage and current monitoring.

Power distribution

This adapter also passes power through to the rest of the drone or rover platform. In addition there will typically be an additional power distribution board (PDB) to which the drive motors can be connected. A small PDB is included in the HoverGames kit, it should fit in the middle of your drone frame.

Notes

You may have been provided a cable to adapt from the Hirose DF13 6 pin connector on the power adapter to the JST-GH 6 pin connector.

• We have noted that some of these are difficult to fit into the Hirose end.

• There may be a couple of tiny "nubs" on that connector that should be removed. Also you may want to file the connector slightly.

• It may require quite a bit of force to get the connector to push in. Be steady, and use some pliers to apply steady force after ensuring it is aligned correctly

Advanced: A JST-GH header can be soldered to the power adapter, allowing the used of a standard JST-GH to JST-GH straight through cable. Carefully look at the location of pin 1 as the vertical and horizontal versions of the JST-GH header swap the location of pin 1.

Changing the power module cable

The initial power modules did not have the correct JST-GH end installed. You may need to swap the cable as shown below.

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 to include these examples in the build process.

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

• PX4 Example Lab 1: uORB Subscribe

• PX4 Example Lab 2: uORB Publish

• PX4 Example Lab 3: Building Code

• PX4 Example Lab 4: Running Code

• PX4 Example Lab 5: Build your own PX4 app

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 PX4 Developer Guide is a good place to get information and you can always ask your questions on the PX4 Discuss or Slack.

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".

To program a blank board, or recover a board that has been "bricked", or simply to have low level access to the MCU, you will want to use a J-Link or other SWD (Serial Wire Debug) capable programmer. Normally there is a standardized 10 pin header that is used for ARM debuggers. On the RDDRONE-FMUK66 the DCD-LZ interface is used to carry these signals, plus a primary serial console. To connect the J-Link debugger to the FMU you will use the DCD-LZ adapter as mentioned below.

This section will show the basics of how to install the software for using the J-Link programmer, and which commands to use to program a binary (*.bin) file.

Connecting the debugger to the FMU

The HoverGames drone kit includes an adapter board for the RDDRONE-FMUK66 DCD-LZ interface which allows a standard J-Link debugger and a USB to 3.3V TTL serial interface to connect using the 7 pin JST-GH connector on the RDDRONE-FMUK66 board.

This picture below shows the J-Link EDU Mini and an FTDI-USB-UART-3V3 plugged into the DCD-LZ-ADAPT board and then connecting to the DCD-LZ port an RDDRONE-FMUK66. This is the setup as included in the HoverGames drone kits. Note that the FMU has to be powered using a micro USB cable.

The 7-pin JST GH cable connects the debug adapter board to the FMU. The USB-TTL-3V3 cable plugs in as shown below. The black (GND) wire should be on the same side as the small notch/mark on the orange case! The SWD cable goes between the adapter board and the J-Link EDU Mini debugger.

Alternative debugger configurations

Shown below is the Landzo OpenSDA Debugger with an adapter board connected to the 7-pin JST-GH RDDRONE-FMUK66 DCD-LZ interface.

J-Link Software setup

You will need the J-Link Commander program, which is part of the J-Link Software pack. Installers for different operating systems are available at Segger's website. Links are available on our download page.

On Windows, you will find J-Link Commander under the program menu after installation. It can be found in a directory similar to this:

You can also browse to the installation folder and run the program from there. Usually, the J-Link Software pack is installed to a location similar to C:\Program Files (x86)\SEGGER\JLink_Vxxxx. Note that the name of the J-Link Commander executable is actually JLink.exe.

On a Linux OS, you can only run the executable through a commandline. You can directly run J-Link Commander from its installation directory by entering /opt/SEGGER/JLink/JLinkExe in the commandline.

Establishing a connection with J-Link Commander

When prompted, type connect to establish a connection with the debugger.

Set the target device

The next step is to specify the target device, which is referring to the microcontroller that is on the RDDRONE-FMUK66. For the RDDRONE-FMUK66, the correct selection is MK66FN2M0XXX18. You can enter this by hand, or enter ? to bring up a selection dialog in which you can select the right device. The selected device will be remembered in next sessions, meaning you can just press enter to select the saved default.

Select the target interface and speed

Enter s to select SWD as the target interface.

You can accept the default target speed of 4000 kHz by just pressing enter.

The JLink will then connect to the target. You should see something similar to this:

J-Link help

At this point you can type ? to get help and a list of commands that JLink accepts. Note the command loadbin, we will use it later.

Flash binary files to the FMU board

When a connection is established, you can flash binary files to the FMU board using the same commandline as we used before. We will use the loadbin command to write binary files to the FMU.

The general format of the command is as follows: loadbin <path to binary file> <target memory address>

The path to the binary file is an absolute path, and the target memory address is a hexadecimal address. The default address is 0x0, when no address is given. The PX4-compatible bootloader should be written to memory address 0x0, while the firmware should be at memory address 0x6000. The bootloader is then automatically started when the board receives power, and the bootloader then loads the firmware located at memory address 0x6000.

Depending on whether you are flashing the bootloader or firmware, you will have to enter a command similar to this:

• Bootloader: loadbin /complete/path/to/bootloader.bin 0x0

• Firmware: loadbin /complete/path/to/firmware.bin 0x6000

Depending on the size of the binary, it might take a while to flash. A pop-up will appear which shows the different steps. It will first check the contents of the binary and match it against the contents of the memory on the board. If they are equal, the binary doesn't have to be flashed. Otherwise, the old contents of the memory are first erased. Then the contents of the binary are programmed into the memory, and finally it is verified that it was done correctly.

That is everything. You may need to press reset on the board, or power cycle for the new code to start running on the RDDRONE-FMUK66. Note that with just a bootloader, the board will not do much. You will need both a bootloader and PX4 firmware for the board to function as intended.

Convert from .elf to .bin

Previously, no .bin files were available. To upload the software to the board with the J-Link debugger, you had to convert the .elf to .bin manually. On Linux, this can easily be done using the following command:

arm-none-eabi-objcopy -O binary nuttx_nxphlite-v3_default.elf nuttx_nxphlite-v3_default.bin

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:

• using SITL (software in the loop) in a simulation environment like Gazebo or AirSim. The code is running on a simulated flight controller. Fast to iterate and test unusual conditions in a safe way. Only the simulated hardware crashes, not a real drone! Sometimes not representative of real-world environment however.

• using HITL (hardware in the loop) where the code is actually running on target hardware, but all the sensor and IO is attached to the simulation environment. It is more complicated to configure than SITL, but can expose things like processor or system hardware limitations or bottlenecks.

• on the actual hardware, which is closest to reality, but slower and more dangerous to fully test.

When testing code for complex systems like drones, SITL is good practice because you can make sure it works properly and look for failure conditions in advance of loading it on a real physcial drone. This helps prevent accidents! However since we're just reading sensor measurements and publishing LED commands, we can't really harm our drone, so we're going to go the "real hardware" route. This will also give you experience in loading code to the FMU.

Adding our code to the local PX4 project

In order to build our code in PX4, we place the code in the correct location with the necessary supporting files. Lets take the hg_led example from Lab 2. Save the source code you wrote to a file named hg_led.c as seen here:

CMakeLists.txt

Now place this file into a folder also named hg_led. Your folder name should usually match your main file's name. Next create a text file called CMakeLists.txt that will tell cmake how to build our application. Inside our CMakeLists.txt file, add the following code:

px4_add_module(
    MODULE examples__hg_led
    MAIN hg_led
    STACK_MAIN 2000
    SRCS
        hg_led.c
    DEPENDS
    )

Lets explain what's going on here:

• px4_add_module(): This tells cmake that we are adding a new module (or application) to the firmware.

• MODULE: examples__hg_led tells cmake that this application is located in the Firmware/src/examples folder. If you add an application to another source folder, you essentially write <folder_name>__<app_name>.

• MAIN: This tells cmake what the main function name is. This is your application name. In this case, it's hg_led.

• SRCS: Add the names of your source files under this parameter.

• DEPENDS: If your application depends on another application, add them here. Since our application is an independent program there are no other file dependencies listed here.

Now that we have our CMakeLists.txt file configured, we also have to tell PX4 to build it for our board. First, we need to move or copy our hg_led folder containing the source files and the CMakeLists.txt that we created into the Firmware/src/examples/ directory. It should look like this:

Navigate to Firmware/boards/nxp/fmuk66-v3/default.cmake and add hg_led to the list under EXAMPLES. All of these examples listed here will be built into your PX4 image and will be able to be called from the command line on the FMU when running! Your EXAMPLES parameter should now look something like this:

    EXAMPLES
        fixedwing_control # Tutorial code from https://px4.io/dev/example_fixedwing_control
        hello
        hg_led # Our example application!
        hwtest # Hardware test
        #matlab_csv_serial
        px4_mavlink_debug # Tutorial code from http://dev.px4.io/en/debug/debug_values.html
        px4_simple_app # Tutorial code from http://dev.px4.io/en/apps/hello_sky.html
        rover_steering_control # Rover example app
        uuv_example_app
        work_item

Building PX4 and flashing the board

Now that we've added our new application to PX4, let's build our new firmware by running this command in our terminal: make nxp_fmuk66-v3

After entering the make command, the software will start building. Assuming no errors or failures, you should see an output similar to this once it's done. (If there is a failure, read the output carefully, often it is something simple that needs correction like a missing ";" at the end of a line of C code.):

Now, you can navigate to /Firmware/build/nxp_fmuk66-v3_default/ to find your *.px4 file which you can flash to your RDDRONE-FMUK66 using QGroundControl! (or a .bin file via the Segger JLINK SWD debugger tools.)

Most of the times when using the RDDRONE-FMUK66 (NXPhlite) flight controller, you will only be using the latest stable firmware, which can be directly installed using QGroundControl

https://docs.px4.io/main/en/config/firmware.html

However, some times you want to be able to test the latest development version, or your own modifications. To do this, you can build the latest version yourself, and load it on the FMU. On this page you will find the steps on how to approach this.

Building the firmware

When you have your toolchain set up, you can start building firmware. As part of the installation, the firmware has already been cloned to your computer under the folder ~/src/Firmware. To build the firmware for RDDRONE-FMUK66 (NXPhlite), open a terminal in this folder (On Windows, follow steps 1. and 2. at https://docs.px4.io/main/en/dev_setup/dev_env_windows_cygwin.html#getting-started

and use the following command:

make nxp_fmuk66-v3_default

This will create a firmware file called nxp_fmuk66-v3_default.px4, which can be found at ~/src/Firmware/build/nxp_fmuk66-v3_default. This is the firmware file based on the current master, which can already by uploaded to the RDDRONE-FMUK66 using QGroundControl. It will also create a nxp_fmuk66-v3.bin file in the same location which you can program with the debugger.

You can also have the building process directly upload the firmware to the FMU. To do this, run the following command:

make nxp_fmuk66-v3_default upload

This will also build the current version of the firmware, but when it is finished building it will also upload the firmware to a connected RDDRONE-FMUK66. If you do not have an FMU connected or the uploader does not recognize a connected FMU, it will display a message that it is waiting for a "BootLoader". If you have not connected the FMU yet, the uploading will commence whenever you plug it in. If the FMU is already connected, you can try resetting the FMU using the reset button on the side.

Building different branches

If you want to test an experimental branch to test an experimental feature or fix, you can simply checkout the different branch, because the firmware folder is a clone of the Git repository.

git fetch
git checkout branch_name

The project contains a lot of submodules, of which different versions are being used between different branches and commits of the firmware project. Therefore it is recommended to update them every time you switch between branches. You can use the following sequence of commands to update all the submodules after a checkout:

git submodule sync --recursive
git submodule update --recursive --init
make distclean

Update your local clone of the PX4 Firmware repository

You can pull in the latest changes from the remote repository using the following command:

git pull

This is useful if you already have a local clone of the repository and you want to get the latest version of the code. Using this, you don't have to clone the repository again.

Installing MCUXpresso

We will install MCUXpresso inside the Linux environment (native or virtual). This allows MCUXpresso to build PX4 Autopilot, flash it to the FMUK66E and debug the code while it is running on the board. You can also install MCUXpresso on your host operating system, but we recommend to keep all tools in the same (Linux) environment.

The MCUXpresso IDE is available free of charge and can be downloaded from the NXP website, but you will need to create a (free) NXP account:

Click on the download button and login to your NXP account. The next page will show the current available releases. There is also a tab for previous releases. You should download the current release (11.6 as of August 2022), click on "MCUXpresso IDE" to continue. You will have to agree with some terms and conditions before you can download the software.

Download the .deb.bin file for Linux. You can directly download it using the Firefox browser which is included with Ubuntu, or if you are using a virtual machine you can download it on your host operating system and move it into the shared folder, which should be accessible in the file browser.

Assuming you have the file stored in the ~/Downloads folder, you should first enter the command below to allow the package to be executed and installed. You should replace the last part of the filename with the right version number for your download! You can use the auto-complete feature for this by pressing the tab key. Just start typing the command below and press tab when you get to the version number in the file name.

chmod +x ~/Downloads/mcuxpressoide-11.6.0_8187.x86_64.deb.bin

Now you can install MCUXpresso by executing the installer package, for which you again have to modify the filename to match the right version:

sudo ~/Downloads/mcuxpressoide-11.6.0_8187.x86_64.deb.bin

You might get asked to accept an agreement (use the arrow keys to select "Yes" and press enter). Then wait for the installation to finish.

Installing the Kinetis K66 SDK

Now we should start MCUXpresso. You can find it in Ubuntu's launcher menu (the icon in the bottom left corner of the screen). Look for the blue icon with the "X", or just type "MCUXpresso". MCUXpresso will immediately ask at what location the workspace should be saved. You can chose your own directory, or leave the default as is. You can also create additional workspaces for different projects if you want.

You will then be greeted by a welcome screen. You can close the "Welcome" tab or press the "IDE" button on the top right to continue. Once you are in the main view of the IDE, find the location were you stored the Kinetis K66 SDK .zip file, and drag the archive into the area of the IDE window that says "Installed SDKs". It's usually located at the bottom. It will ask you to confirm that you want to import the SDK. Just press "OK". It might take a few seconds to install.

Create a new project for PX4

Now that MCUXpresso and the Kinetis K66 SDK are installed, we can continue and create a PX4 project. You can create a new project in MCUXpresso by going to "File", "New", and then "Project". A list with different project types will appear, from which you should select "Makefile Project with Existing Code" under "C/C++".

You can use any project name, but for clarity we will call it "HoverGames PX4". You should select /home/hovergames/src/px4-firmware as the existing code location. This is the folder where we cloned the PX4 firmware code. Make sure that both the C and C++ languages are selected. For "Toolchain for Indexer Settings", select "NXP MCU Tools". Click "Finish" to create the project.

Project properties

Before we continue we should change some project properties. Select the project we just created on the left side of the screen, go to "Project" in the menu at the top and then select "Properties".

Go to "MCU Settings" under "C/C++ Build". An error might pop up, complaining about invalid values. If this happens you can close the error, switch to another tab and switch back again. You should now see the same screen as shown in the image below. On this "MCU Settings" screen, select the MK66FN2M0xxx18 under the K6x family of MCUs.

Now go to the main "C/C++ Build" tab. Uncheck "Use default build command" and change the build command to just make. The PX4 build scripts will take care of the specifics, we should not supply any additional arguments here.

Then switch to the "Behavior" tab. Uncheck "Enable parallel build", because the PX4 build tools also already takes care of this. Set the "Build (incremental build)" target to nxp_fmuk66-v3_default and change the "Clean" target to distclean. Click "Apply" to apply all changed settings.

You can click "Apply" to apply the changes, but don't close the window yet. The current configuration is named "Debug". Let's give that a more descriptive name. Click on the "Manage Configurations..." button and then choose "Rename..." to change the name. We will call it "PX4 FMUK66 Default". You can later add additional configurations if you want to play around with the build variables or if you want to build PX4 for another board, such as the NXP UCANS32K146.

You can press "Apply and Close" to apply the changes and close the window.

We now have a build configuration that allows us to create PX4 firmware builds for the FMUK66 board. You can use the hammer icon to start a build for the selected project. If you add multiple configurations you can switch between the different profiles with the small arrow next to the hammer icon.

Give it a try, the console at the bottom of the IDE window will show the progress of the build. Note that this might take a while if you are building PX4 for the first time! When you make changes to the code after the first build it should only rebuild the changed files.

Run configuration

We can now build the PX4 firmware with MCUXpresso. We are now going to also add a run configuration to flash the binary directly to the FMUK66 board with just a USB cable, without debugger!

At the top of the screen, you have a green "Run" icon. Click on the small arrow next to it, and select "Run Configurations...". In the window that opens, select "C/C++ Application" and click the "New" button above it. Name the newly created configuration "PX4 FMUK66 Upload (USB)" to remind you that this will flash the firmware using only USB. Change the field under "C/C++ Application" to /usr/bin/make.

Also go into the "Arguments" tab and add nxp_fmuk66-v3_default upload into "Program arguments".

Finally, go into the "Common" tab. Tick the checkbox in front of "Run" under "Display in favorites menu". Press apply and close the window. You can now upload firmware binaries to the FMUK66 with just the USB cable by clicking on the green "run" icon in the toolbar.

Debug Configurations

The next step is to also add a debug configuration. This requires the J-Link EDU Mini debugger that is included with the drone kit. Make sure the debugger is plugged in to your computer and passed through to the VM (verify that you added the J-Link debugger in the USB tab of the VM settings).

Now in the bottom left of your screen, in the quickstart panel, press the blue bug icon with the label "Debug". Make sure that you have the right project ("HoverGames PX4") selected in the project browser on the top left!

A new window opens and should show the attached J-Link debugger. Select it and press "OK".

In the next screen, you should make the "Name" column a bit wider and select "nxp_fmuk66-v3_default.elf". If this file is not being shown, you should cancel and first build the software (you can click on the hammer icon as mentioned previously, or build "manually" in the terminal).

When you have the .elf file selected, press "OK". It might start building the code and start a debug session. Wait for it to finish (there is an indicator at the bottom). Then press the "Terminate All Debug sessions" button in the top bar (the red square next to the resume and pause buttons) to stop all debugging sessions.

We should make sure that the generated configuration is correct and make some small changes. Click on the small arrow between the green debug icon and the green run button. Go to "Debug Configurations...".

Under "GDB SEGGER Interface Debugging", select the generated JLink configuration. It is probably called something like "HoverGames PX4 JLink PX4 FMUK66 Default". Make sure "nxp_fmuk66-v3_default.elf" is selected in the field under "C/C++ Application".

In the "Startup" tab, disable the "Set breakpoint at" option. You can set your own breakpoints anywhere you want, we just don't need this default one.

Finally, switch to the "Common" tab, and tick the checkbox in front of "Debug" under "Display in favorites menu". Press "Apply" and close the window. You can now start a debug session with the debug icon!

Upload PX4 firmware to FMUK66 using USB

If you want to do a clean build, press the clean button on the right side first. Then, click the hammer button to build to build the PX4 firmware for the FMUK66. You can check that the build configuration is set to "PX4 FMUK66 Default" by clicking on the dropdown menu next to the hammer icon. After you start the build process, the progress will be shown in the console at the bottom of the screen.

You can upload the firmware with the green "run" icon (not to be confused with the "resume" icon that you can use during debugging). You can again check that you have the right run configuration selected by clicking on the dropdown menu next to the run icon. Keep in mind that the FMUK66 needs to be connected via USB for this to work!

Start a debugging session

You can start debugging by clicking the green debug icon, or open the dropdown menu next to it and select the "HoverGames PX4 JLink PX4 FMUK66 Default" configuration. You might get a popup about switching to the debug perspective, which will rearrange some panels within the MCUXpresso window. The debug perspective provides a better overview of the different debug tools. After debugging you can change back to the default view through the "Window" menu at the top.

You can terminate the debug session by clicking on the button with the red square.

Learn more about MCUXpresso

Further documentation and videos about MCUXpresso are available on the NXP website. You will probably have to login to access some files and videos. You can create an account for free.

The "Advanced Debugging with MCUXpresso IDE" series provides a great introduction to the debugging tools in MCUXpresso. Most of the tools shown in these videos can be directly applied to debugging an FMUK66 board running PX4 Autopilot.

Advanced Debugging with MCUXpresso IDE

• Part 1: Building Debugging and Direct Flashing

• Part 2: Accessing Data and Peripherals

• Part 3: Code & Data Breakpoints

• Additional videos are available in this series, but are outside the scope of the HoverGames.

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!

Here are some commonly used upgrades or add-on components for drones. They are not required for use with the HoverGames drone but you may enjoy adding them. The linked items are only suggestions, and should not be considered an endorsement of any specific company.

Propellers

Original DJI propellers will be much better balanced than the propellers included with the kit, but quality comes at a price. The propellers below are very similar to the propellers that come with the HoverGames drone kit. You can also look for good quality propellers in any hobby flyer shop.

LiPo batteries

LiPo battery chargers

FPV camera and visor

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 previous section, and then come back to this section.

Getting Started

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

uORB

uORB is a publish/subscribe messaging protocol that is deeply embedded in the PX4 system. Now, you may ask, what is a publish/subscribe messaging protocol? Lets find out!

Publish/Subscribe messaging protocols

In the image above, you can see that PX4 is a publisher of a multitude of different "topics". These topics are similar to a "struct" in C. They have a name (such as led_control) and can contain different variables that correspond to that topic.

For example the topic "sensor_gyro" contains the following information:

LINK to file: https://github.com/PX4/Firmware/blob/master/msg/sensor_gyro.msg
-----------------------------------------------------------------------------

uint64 timestamp # time since system start (microseconds)
uint64 timestamp_sample

uint32 device_id # unique device ID for the sensor that does not change between power cycles

float32 x # angular velocity in the NED X board axis in rad/s
float32 y # angular velocity in the NED Y board axis in rad/s
float32 z # angular velocity in the NED Z board axis in rad/s

float32 temperature # temperature in degrees celsius

uint32 error_count
uint8 ORB_QUEUE_LENGTH = 8

The sensor_gyro topic contains quite a few variables. Each topic is able to be sent as a message from a publisher to a subscriber. A timestamp is included each message, and that is defined in the .msg file.

The primary data of interest is for this topic is x, y, z, and temperature variables. The gyro on the RDDRONE-FMUK66 outputs angular velocities in the x, y, and z directions, and also reports the temperature.

Again in the image above, it shows that hg_gyro subscribes to the sensor_gyro topic to harness the data published to it.

HG_Gyro Subscriber Example

Above we've shown the sensor_gyro uORB message, lets go through the HoverGames HG_gyro example code and find out how we can print gyro measurements to the MavLink console.

License

First, we have to include the header license comment since the software is permissively licensed:

/****************************************************************************
 *
 *   Copyright (c) 2012-2016 PX4 Development Team. All rights reserved.
 *   Copyright 2019 NXP.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 * 3. Neither the name of the copyright holder nor the names of its 
 *    contributors may be used to endorse or promote products derived 
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
 * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
 * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
 * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
 * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
 * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 *
 ****************************************************************************/

/**
 * @file hg_gyro.c
 * Minimal application reading gyro values from uORB service
 *
 * @author Leutrim Mustafa
 */

Alright, with that out of the way, let's start!

Headers

We will review each section of code and then combine everything into one file at the end. The first section of code is where we include all of the necessary header (*.h) files we will need for this example.

// px4_config and posix are needed for just about every PX4 user application.
#include <px4_platform_common/px4_config.h>
#include <px4_platform_common/posix.h>

// These are basic headers that will be needed for polling messages,
// manipulting strings, standart input/output, and POSIX compliance.
#include <unistd.h>
#include <stdio.h>
#include <poll.h>
#include <string.h>

// These headers are for the uORB messaging system. We include the base uORB
// header and a header for the topic we will be using (sensor_gyro!)
#include <uORB/uORB.h>
#include <uORB/topics/sensor_gyro.h>

Main Function Declaration

Now that we have all of our headers included in our application, we can begin the real stuff. We define our main function and export it so that other applications can call upon it in PX4.

// Export main function so that we can call on it in PX4
__EXPORT int hg_gyro_main(int argc, char *argv[]);

// Define our main function
int hg_gyro_main(int argc, char *argv[]) {

    PX4_INFO("Hello Hovergames gyro!"); // Prints "Hello Hovergames Gyro!" to the console

When creating our own PX4 user apps, it's necessary to name your main function <filename>_main so that PX4 can tell what the new function is named and how to call it.

The int argc, char *argv[]arguments in the main function allow the addition of command line parameters to your app when you call it from the PX4 MavLink console or in a script. While they aren't necessary for this example, it doesn't hurt to include them for future iterations of our app!

Subscribing to the sensor_gyro topic

Next, we will go through the code to print out our gyro measurements. We need to set up the uORB messaging protocol to subscribe to the sensor_gyro topic:

    // Subscirbe to "sensor_gyro", then set a polling interval of 200ms
    int gyro_sub = orb_subscribe(ORB_ID(sensor_gyro));
    orb_set_interval(gyro_sub, 200);
    
    // Configure a POSIX POLLIN system to sleep the current thread until
    // data appears on the topic
    px4_pollfd_struct_t fds_gyro;
    fds_gyro.fd = gyro_sub;
    fds_gyro.events = POLLIN;

After subscribing to the "sensor_gyro" topic and limit the update rate (interval) to 200ms, we set up a polling structure which allows the application to enter sleep mode until another set of data gets published to the topic. This makes our application efficient and prevents it from eating CPU cycles when waiting for new data!

Setup for the for loop

Using a simple integer counter variable in a loop allows the program to end after a specified number of times. We will print out a text chart so that we can visualize the data a little bit easier.