SPI userspace driver

In the October Demo image, we have enabled SPI in the kernel to allow HoverGames participants to communicate with SPI devices. The October Demo image will be released soon.

Preparing the image

The HoverGames images come as a .bz2 compressed archive. To decompress this image, you'll need to use a program like 7zip on Windows, use the bunzip2 command on Linux, or double click the archive on Mac.

Flashing the image to eMMC or SD card using UUU

Downloading UUU

NXP has a tool for flashing i.MX hardware called UUU (Universal Update Utility). You can download UUU from here:

If you're on Windows, you'll want to download the uuu.exe file, and if you're on Linux, you'll want to download the uuu file.

Downloading the Linux image

You must agree to all of the applicable licenses and agreements at the following link before downloading the Linux software. It is hosted here:

Downloading the bootloader

Step 1

Flip the DIP switches on your NavQ to put it into USB flashing mode (boot from USB in the image below). Here is an image that shows how to do so:

Step 2

Connect your NavQ using the included USB-C cable to your computer. You should recieve a message on your computer that it has been connected. To make sure the NavQ is connected, you can run the UUU program with the -lsusb flag and you should see an output similar to this:

Step 3

You can flash both the SD card and the eMMC using this tool. The keyword for flashing the SD card is sd_all, while the keyword for flashing the eMMC is emmc_all. The command to flash your board is outlined below:

After a few moments, your board should be flashed. Unplug your NavQ from power, reset the DIP switches to the desired boot device, and you're good to go!

Flashing the image to SD card using dd or Win32DiskImager

To flash the image, you'll need to use dd on Linux/Mac or Win32DiskImager on Windows.

Linux

Mac

Windows

Download Win32DiskImager:

Open the program and select your SD card. Choose the .wic OR .img file, then click "Write".

Power input specification

The NavQ can take a voltage of 5V to 20V.

The board may also be powered via USB- which also has a 20V max input rating.

Power input protection

There is some, but limited power input protection on board. Given this is typically for USB-C application, it may not be sufficient in harsh operating environments. You may want to provide some additional reverse polarity protection, over-current, or DC-DC conversion/isolation from the battery if you expect to be experimenting outside the HoverGames normal operating range or treating it harshly.

Battery supply protection

Please monitor your LiPo battery carefully for undervoltage conditions. If left connected, the NavQ and HoverGames drone will completely drain your LiPo battery and could cause permanent damage to your battery. There are no undervoltage disconnect provisions built in.

Low battery monitor

A simple solution to undervoltage protection may be to add a hobby grade low battery monitor alarm. These sound a loud alarm when any cell goes below a user set threshold voltage. The LED display will also show the individual cell voltage and total pack voltage. This plugs into the balance connector of the LiPo battery. They are inexpensive and available at hobby stores or online at typical outlets. Here are some examples:

• Amazon - ""

• Amazon - ""

Introduction

If you're thinking about using the CAN protocol on your drone, this guide will walk you through using our UCANS32K146 to create a CAN interface.

Since there isn't a native CAN bus on the NavQ, we can use a protocol called SLCAN to communicate CAN messages across a UART connection. We have built a binary for the UCANS32K146 that acts as an SLCAN transfer layer. This means that we can add a CAN bus to NavQ by just connecting the UCANS32K146 to the UART3 port.

Setting up SLCAN on NavQ

To enable SLCAN on NavQ, run these commands:

Now you can use SocketCAN or python-can to send and recieve CAN messages over the slcan0 interface. As an example, here is how to send a CAN message from the command line:

Flashing your UCANS32K146 with the SLCAN conversion binary

Follow the guide at the link below to flash the SLCAN binary to your UCAN board:

Overview

In this section, we will guide you through the process needed to detect AprilTags on your NavQ. There are a few things that need to be done to accomplish this:

1. Install ROS2 image tools

2. Build and install AprilTag detection nodes

3. Calibrate the camera on your NavQ using a checkerboard pattern

Prerequisites

Before we start, you will need a few things:

Checkerboard

To create a checkerboard for camera calibration, download this PDF:

Desktop Setup

In order to calibrate the camera, you will need to set up your NavQ with a mouse, keyboard, and monitor. Use the included microUSB hub and HDMI connector to do so.

Installing required ROS2 software

Install the following packages with the apt package manager by running the commands below:

Once that is finished, move on to the next step.

Calibrating the camera

Hook up your NavQ to a monitor with the provided HDMI cord and connect a USB mouse + keyboard through the included microUSB hub. Open the terminal by clicking the icon at the top left of the screen and open the bash shell by running:

Have your printed checkerboard ready in a well lit environment and run the camera calibration software by running the following commands:

Now use the link in the note above to run through calibarating the camera.

Detecting AprilTags

Building apriltag_msgs

A prerequisite for the apriltag_ros node is apriltag_msgs. Clone the repo and build it by running these commands:

Make sure to source the install/setup.bash file so that apriltag_msgs can see it when being built.

Building the apriltag_ros node

First, in order to detect AprilTags, we need to build the apriltag_ros node written by christianrauch. You can clone his repository by using this git repo:

To make his repo work with ROS2 Foxy, you will need to make a small change in the CMakeLists.txt file. Go to line 26 in that file and delete the apriltag:: token in the AprilTagNode apriltag::apriltag part.

Next, you'll want to save that file and run colcon build in the apriltag_ros folder. Once it is done building, you'll want to source the install/setup.bash file. Add this line to your .bashrc:

Creating a new package to concatenate camera information to each camera frame

In order to make the apriltag_ros node work, we need to make sure that camera info messages are being sent in sync with each camera frame published by the cam2image node. We have written an example node that does just that. You can download it here:

You will need to replace the matrices in the node file to match your camera calibration parameters. The source file is located at pypysub/py_pysub/publisher_member_function.py. Once you have done that, make sure to build and install the node and source the install/setup.bash file.

Running the code

To run the code, you'll need to run the following ROS nodes:

Prerequisites

Devices required

In this guide, we need a few things:

1. NavQ Companion Computer mounted with Google Coral Camera attached

2. Laptop/Phone with QGroundControl Installed

3. Both NavQ and mobile device connected to the same WiFi network

Setting up QGroundControl

In QGroundControl, click the Q logo in the top left, and configure the video section as seen in the image below:

This will set up your QGroundControl instance to receive the UDP video stream from the NavQ.

Connecting your NavQ to your router and getting IPs

Follow the WiFi setup guide using connman in the Quick Start guide to connect your NavQ to the same router as your mobile device. You will need to use the serial console to do this. Once you have your NavQ connected, you can run ifconfig in the serial console to find the IP address of your NavQ.

You can SSH into the NavQ to run the GStreamer pipeline once you have the IP.

Running the GStreamer pipeline

With your NavQ on, SSH into it by using the IP address you noted when connected to the serial console. Once you're successfully SSHed in, you should note the IP address that you logged in from as seen here:

This is the IP of your computer that you should be sending the video stream to.

To run the GStreamer pipeline, run the following command:

Once you run that command, you should be able to see the video stream from your NavQ on QGroundControl!

Taking a picture

To take a picture on your NavQ using GStreamer, run the following command:

To take video, you can run the following pipeline:

Configuring Windows

Step 1 - Enable Mobile Hotspot

HoverGames Interposer Board (HGI)

The HoverGames Interposer Board has a large amount of connectors and I/O for you to connect your devices, sensors, switches, LEDs, and more. This section will give you an overview of the connector pinouts on the HGI. The picture below has a few silkscreen labels for pinouts on each connector, but some connectors have multiplexers to make them more flexible.

UART2

UART2 is used for the serial monitor, and should not be used for anything other than the serial monitor. It should not be altered.

UART3

UART3 will mainly be used for serial communication to the FMU in HoverGames, but it can be used as an SPI port if you're not using it for the drone.

UART4/I2C/GPIO

The bottom 9 pin JST-GH connector in the image of the HGI is used for UART4/I2C/GPIO.

The UART4 pins do not have flow control on this connector. There is no multiplexing on this connector as well. The pinout is below.

Linux GPIO Pin IDs

SPI/GPIO

The SPI/GPIO port has a full pinout for SPI as well as 3 GPIO pins. The SPI pins can be muxed to a full UART 4 port with flow control. The pinout is below.

Linux GPIO Pin IDs

GPIO Headers

The GPIO header pads on the HGI are not labeled correctly with the silkscreen. The layout is shown below with TP labels and schematics.

The 8MMNavQ is a small purpose built experimental Linux computer based on the . It is focused on the common needs of Mobile Robotics systems.

The system is built as a stack of boards, the top board being a SOM (system on module) containing the Processor, memory and other components with strict layout requirements, and where the secondary boards are relatively inexpensive (often 4 layer boards) and allows for versions with customization to be easily built.

This is a new set of boards and software enablement and will undergo several iterations. Our intent is to provide a "friendly Linux" with typical packages and additional tools included rather than the typical highly optimized and stripped down Linux found in deeply embedded products.

The 8MMNavQ features:

1. NXP i.MX 8M Mini SOM with LPDDR4 DRAM and eMMC Flash.

2. A secondary board with SDCARD, Networking, MIPI-CSI (Camera) and MIPI-DSI (Display) interfaces

   • MIPI-DSI to HDMI converter

Applications

The NavQ is suitable for many purposes, including generic robots and various vision systems.

• Drones, QuadCopters, Unmanned Aircraft, VTOL

• Rovers

• Road going Delivery Vehicles

Two specific complete developer tool examples are the , and the NXP-CUP car.

Software

The intent of the 8MMNavQ in HoverGames is to enable participants with a solution that allows them to harness common robotics packages and libraries such as:

• ROS

• OpenCV

• GStreamer

The 8MMNavQ runs linux with a package manager, so you should be able to install the packages that you need to complete your projects successfully and efficiently.

This work is licensed under a .

Here are a few videos of some of the capabilties of NavQ:

While the 8MMNavQ is a standalone computer, it has been designed with NXP HoverGames coding competition in mind. And specifically the NXP KIT-HGDRONEK66 using the RDDRONE-FMUK66 flight controller.

• www.HoverGames.com

specific features include

• NavQ can connect to HoverGames (RDDDRONE-FMUK66)

  • via serial

  • via Ethernet (using 100BaseT1 2 wire ethernet adapter)

NavQ SOM

The SOM includes the processor, RAM, memory, and WiFi chip for the NavQ.

• NavQ as provided is an experimental board

• NXP Friendly Linux is experimental and in development

NXP, EMCRAFT AND SOFTWARECANNERY, provides the enclosed product(s) under the following conditions:

This reference design is intended for use of ENGINEERING DEVELOPMENT OR EVALUATION PURPOSES ONLY. It is provided as a sample IC pre-soldered to a printed circuit board to make it easier to access inputs, outputs, and supply terminals. This reference design may be used with any development system or other source of I/ O signals by simply connecting it to the host MCU or computer board via off-the-shelf cables. Final device in an application will be heavily dependent on proper printed circuit board layout and heat sinking design as well as attention to supply filtering, transient suppression, and I/O signal quality.

The goods provided may not be complete in terms of required design, marketing, and or manufacturing related protective considerations, including product safety measures typically found in the end product incorporating the goods. Due to the open construction of the product, it is the user's responsibility to take any and all appropriate precautions with regard to electrostatic discharge. In order to minimize risks associated with the customers applications, adequate design and operating safeguards must be provided by the customer to minimize inherent or procedural hazards.

For any safety concerns, contact NXP, EMCRAFT AND SOFTWARECANNERY, sales and technical support services. Should this reference design not meet the specifications indicated in the kit, it may be returned within 30 days from the date of delivery and will be refunded replaced by a new kit. NXP, EMCRAFT AND SOFTWARECANNERY, reserves the right to make changes without further notice to any products herein.

NXP, EMCRAFT AND SOFTWARECANNERY, makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does NXP, EMCRAFT AND SOFTWARECANNERY, assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. Typical parameters can and do vary in different applications and actual performance may vary over time. All operating parameters, including Typical, must be validated for each customer application by customer’s technical experts.

NXP, EMCRAFT AND SOFTWARECANNERY, does not convey any license under its patent rights nor the rights of others. NXP, EMCRAFT AND SOFTWARECANNERY, products are not designed, intended, or authorized for use as components in systems intended for surgical implant into the body, or other applications intended to support or sustain life, or for any other application in which the failure of the NXP, EMCRAFT AND SOFTWARECANNERY, product could create a situation where personal injury or death may occur.

Should the Buyer purchase or use NXP, EMCRAFT AND SOFTWARECANNERY, products for any such unintended or unauthorized application, the Buyer shall indemnify and hold NXP, EMCRAFT AND SOFTWARECANNERY, and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges NXP, EMCRAFT AND SOFTWARECANNERY, was negligent regarding the design or manufacture of the part.

Fault_N on USB C chips

Action - Mask this interrupt in the register FAULT_STATUS_MASK (0x15h):bit 4 -- Force Discharge Failed Interrupt Status Mask (to be zeroed).

Resolve in the software, since both the PTN5110 (TCPC) and NX20P3483 (power switch) connected to the I2C bus. Polling of the NX20P3483 will address this errata.

This issue will be resolved in the next board revision (RDDRONE-HGI-2A)

SD 3.0 Power Switch is missing

Action - disable SD3.0 support in UBoot and/or avoid SD3.0 cards

This issue will be resolved in the next board revision (RDDRONE-MEDIABOARD-2A)

The SD3.0 PWR switch will be added:

3rd Mounting hole on carbon fiber plate

Issue - The 3rd mounting hole for the NavQ was missed on the carbon fiber mounting plate. This is needed to secure the board and avoid vibrations.

Action - Please drill a 3mm hole manually or use double sided tape on this side of the baord mounting. This must be done to avoid vibration of the board during flight.

If you would like to take a look at the schematics of each board in the NavQ, you can download the .zip file at the bottom of this page. The table below gives detail for each folder inside the .zip file.

• USB-UART serial debug console (included with HG2 Kit)

• LTE CAT-M1 cellular modem

• PMDTEC Time of Flight (TOF) Camera

• Lighthouse tracking module

• NXP 100BaseT1 2-wire Automotive Ethernet

• Edgelock SE050 Secure Element

• 5" high resolution MIPI-DSI LCD

• MIPI-DSI to HDMI adapter

• PCI.e M2.Module - Kingston SSD

• Non contact gesture tracking module

• Kingston eMMC, LPDDR4, Industrial SDCARD

• RJ45 breakout.

Getting started with your NavQ kit

The NavQ is a device that will allow you to add extra compute to your HoverGames drone system. With an i.MX 8M Mini processor, you will be able to reach new boundaries of vision and sensor data processing.

This LTE Cat M1 modem is a small form factor module for development that includes the PX4 type connectors suitable for connection with the NavQ.

For development, use on a rover or ground station there is a 5" LCD panel that can attach to the NavQ MIPI DSI output.

Specs: <TODO>

Hardware

• 5/10/2020 - Production Hardware in manufacturing

To order a NavQ, you'll currently need to purchase directly from the Emcraft website. If you are a HoverGames 2 participant and have had your application accepted be sure to use your coupon code.

See links below

• :

Easy-to-use script

We have created an easy-to-use script to resize the flashed image on your device. Since the image is smaller than the storage device, it is not properly expanded when first flashed. You can run the following script to expand the filesystem.

To run the script, run the following commands for the boot device you're currently using:

For eMMC:

For SD card:

Making the script executable

The script should be executable when it is included in the image. If it isn't, then you'll need to make it executable by running the following command:

Manually expanding space

You may run into an issue where you run out of space on the eMMC or SD card when installing ROS. To expand the rootfs partition, follow these steps:

Once you're done with those steps, run this command:

and reboot. You should now be able to install ROS Melodic without size issues.

Commands for fdisk

If you prefer to just see the commands, these are the commands you need to run in fdisk in order to resize your disk.

NavQ Cables

The NavQ ships with several cables. They allow for several configurations when powering the NavQ

USB-C

When working on the bench you may wish to power the NavQ from USB-C input cable. This cable is provided. It would also be possible to power the NavQ while on a drone from a separate USB-C battery pack like those for Cell phone power.

Drone power cable supply

Overview

Currently, the HoverGames-Demo image is in a beta state. Over time we will be improving the image by fixing bugs and including even more software so that it's more of an out-of-the-box experience. Here are some of the current fixes at the moment to get a working system.

Quick Workarounds

• WiFi sometimes does not automatically connect to the last WiFi network after reboot.

  • Workaround: Open connmanctl, run disable wifi, and reconnect using the instructions in the Quick Start Guide.

Setting timezone

Setting the timezone on your NavQ is necessary to ensure the apt package manager works. First, you'll need to locate the correct timezone file at /usr/share/zoneinfo. There should be a folder for your country and a file in that folder for the closest city to you.

For example, if you're in Central Time USA, you'd use the following commands:

Now, you can run sudo apt update and sudo apt upgrade to get your system up to date.

Prerequisite

The RDDRONE-FMUK66 has a two wire 100BaseT1 Ethernet interface on board. The 8mmNavQ board does not include T1 Ethernet however an adapter may be used. To run the T1 Ethernet connection between FMUK66 and NavQ use a separate media converter.

There are several editors that can be used in Linux. Nano is a lightweight command shell editor that is popular. There are many others to choose from

Some discussion on the topic:

Assuming you already have internet access on your NavQ, to install nano on the demo image type the following.

This section is for various linux commands that may be useful when using the NavQ, and the Demo image.

There are many communications interfaces supported on NavQ through the JST-GH connectors on the HoverGames Interposer Board. The page links below are guides for each one

Intro

If you've ever run into a situation where you need to view a raw stream from the NavQ's Google Coral Camera, or need to run a lightweight GUI application on NavQ, you can do so using the guide below.

Instructions

Installation

You can run the commands below to start a VNC server on your NavQ.

Connecting

You can use TightVNC to connect. You'll want to use the IP address of your NavQ at port 5901.

Introduction

To be able to have several end nodes communicating via mavlink simultaneously we need to set up mavlink-router on the NavQ. The end nodes can be

• A process for onboard control running on NavQ.

• A QGroundControl (QGC) computer the NavQ connects to via a data link such as WiFi.

• Other mavlink enabled peripherals on the vehicle.

• Another program running on the same remote PC as QGC

Prerequisites

Set up TELEM2 on the FMU

Connect to your FMU over USB and open QGroundControl. Navigate to Settings -> Parameters -> MAVLink and set these parameters:

Also, you'll need to make sure that the settings in Settings -> Parameters -> Serial look like this:

Installation and compiling mavlink router

To install and compile mavlink router follow the steps below (internet access required on your NavQ)

1) Connect to NavQ console via ssh / serial

2) Type the following commands

Mavlink-router configuration

Configuration of mavlink router is done via a single configuration file /etc/mavlink-router/main.conf This file needs to be created from scratch. An example configuration file is available in the mavlink-router sources -

Setup the config file with minimal configuration

You can leave out the unused connection. Via the UdpEndpoint QGConMobile section the mavlink stream is forwarded to a QGC computer/mobile device assuming it has 192.168.43.1 and NavQ is connected to this network via e.g. WiFi.

Enabling auto-start of mavlink-router

Enable the auto-start of mavlink-router via systemd and start it

Checking status of mavlink-router

You can check the status of mavlink router using the command

Since several NavQs might be present in a Wifi Network it's essential to set an unique hostname to determine which one is the correct NavQ you want to connect to.

To change the hostname you need to modify /etc/hostname . We suggest the following format:

navq-[Vehicle Mavlink SysID]

e.g. If Mavlink SysID is 10 the NavQ should be named navq-10

Adjusting the hostname with nano

Adjusting the hostname with echo command

After a reboot the new hostname will be visible on the network.

I2C Example

The NavQ includes an I2C port in one of the JST-GH connectors. You may use this port to communicate to other devices in your drone system. In this example, we will go over the process of connecting a Teensy LC to the NavQ over I2C to control some WS2812 LEDs.

TODO

1. Add guide for using C/Python SMBus libraries for controlling I2C

2. Add more pictures/visuals

3. Explain teensy code

Prerequisites

Hardware

1. Teensy LC

2. NeoPixel LED Strip (Ex. )

3. JST-GH connectors and pre-terminated wires

Software

1. Teensy side

   1. Arduino IDE

   2. TeensyDuino

Preparing the JST-GH connector

To create the I2C connector, you'll need to order some JST-GH hardware. Here is a link to a digikey page where you can purchase connectors:

And here is a page where you can purchase the jumpers:

In the hardware overview (link here: ), you can see the pinout for the I2C connector. Here is another screenshot of it:

The 5VP pin is on the left-most side of the connector, and GND is on the right-most side. I2C2_SDA is pin 4, and I2C2_SCL is pin 5. The JST-GH connector is positioned with the retention clip facing away from you when you are determining the left/right sides.

Wiring the Teensy

You'll need to do some soldering for the first step in this project. In the two pictures below, the NeoPixels are connected to the LED 5V, LED GND, and LED SIG pins. The JST-GH connector to the NavQ connects to the SDA/SCL pins and 5V + GND pads on the back of the Teensy.

One thing to keep in mind is that even though the Teensy LC does not include pullup resistors to 3.3v for the I2C lines, pullups are not required since the NavQ has internal 4.7k pullups on it's own I2C bus (on the SoM).

Pictures

Here are a couples images of this setup:

Teensy code

We have written some simple example code that changes the color of the NeoPixel LEDs when the Teensy recieves I2C data. In the example below, the slave address of the Teensy is 0x29, and the color of the LEDs change from green to white when a 0x1 byte is sent to the Teensy. If any other byte is sent to the Teensy, the color changes back to green.

NavQ commands

Add navq user to i2c group

To use the i2c commands without root, you'll need to add the navq user to the i2c group. To do this, you can run the following command:

Checking connection

Once your Teensy is connected using the I2C JST-GH connector, you need to confirm that the NavQ recognizes the Teensy as an I2C device. To do this, you can run the following command on the NavQ:

You should see a device at address 0x29. If there is no device at address 0x29, you'll need to check your wiring.

Sending data to the Teensy

To send data to the Teensy, you can use the following command:

This will change the LEDs to white. You can swap the 0x1 with a 0x0 or any other byte to switch back to green.

Controlling I2C bus with Python/C

Controlling the I2C bus with console commands is great, but what about when we want to integrate those commands into code? Well, with Python and C, we can control the Teensy over I2C by using some libraries supplied in both the Linux kernel and through pip.

Python

First, you'll need to install the smbus pip package. To do this, just run in your terminal:

Once that is installed, you can run a simple script to select a 1 or 0 to send to the NavQ to change the color of the LEDs.

The expected output of this script is as follows:

By selecting 1 or 0, you can change the color of the LEDs to white or green.

C

To control the I2C bus with C, you can use the following code:

Controlling GPIO through the command line

There are several GPIO pins on the various JST-GH connectors on NavQ. To control these GPIO pins, follow the instructions below.

Exporting GPIO pins

In order to use GPIO pins, we need to export them in Linux first. To do this, we need to know the GPIO number for the pin we want to access. We can compute this number using the following formula:

For example, if we want to access the GPIO1_IO12 pin on the UART4/I2C/GPIO connector, we would find that the GPIO number is:

If you want to find out what pins correspond to what GPIO numbers, we have tables in the Hardware Overview/Pinouts and Connector info section here:

Once you know the GPIO number of the pin you want to access, exporting the pin for use is easy. All you have to do is echo the pin number to /sys/class/gpio/export. For example, if we were to export GPIO1_IO12, we would run the following in our NavQ console:

Changing the pin direction

Next, we will want to change the direction of the GPIO pin for our specific use case. There are two options: in and out. To do this for GPIO1_IO12, you can run the following in your NavQ console:

Reading or Writing the GPIO pin value

To read or write a value to the GPIO pin, we will follow a similar process to changing the pin direction. A pseudo file named value is created at /sys/class/gpio/gpioXXX/value that holds a 1 or a 0. If you echoed out to the GPIO direction file, you can control the pin. To control the GPIO1_IO12 pin, just run the following in your NavQ console:

If you echoed in to the GPIO direction file, you can read the value file and find the current state of the pin. To do this for the GPIO1_IO12 pin, you can run the following in your NavQ console:

Controlling GPIO programmatically (in C)

Prerequisites

1. Create new group called gpio

2. Create new udev rules file

Create a file at /etc/udev/rules.d/99-gpio.rules and add the following to it:

This will allow you to access the GPIO pseudofiles without being root.

Source Code

HoverGames-Linux Distros

We have two separate Linux distributions that you can build for NavQ. There are pros and cons to both.

We have pages for several common software packages. Click the links below or follow the guide on the left of your screen.

The i.MX 8M Mini parts are rated 0C to +95C. We do not expect they will need any additional heat-sinking, especially while flying, but you can monitor the core temperature with the following command:

cat /sys/class/thermal/thermal_zone0/temp

To use the package manager (apt) on the Demo image, you'll need to change your timezone.

First, you'll need to locate the correct timezone file at /usr/share/zoneinfo. There should be a folder for your country and a file in that folder for the closest city to you.

$ rm -f /etc/localtime
$ ln -sf /usr/share/zoneinfo/<country>/<city> /etc/localtime

For example, if you're in Central Time USA, you'd use the following commands:

$ rm -f /etc/localtime
$ ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime

Now, you can run sudo apt update and sudo apt upgrade to get your system up to date.

Controlling PWM on NavQ

The PWM chips are tied to the onboard LED on NavQ. There are three PWM chips: pwmchip0, pwmchip1, and pwmchip2. Each of these "chips" have one PWM line attached to them: pwm0. To use these PWM lines, you will need to use the sysfs interface.

Using the sysfs interface to control the onboard LED

Step 1

Log into the root user on NavQ by running this command:

Step 2

Navigate to /sys/class/pwm and run the following commands:

Step 3

Now that our PWM lines are exported for each chip, we can change the duty cycle of the PWM lines and enable them. The default frequency is 2730667 Hz. For a 50% duty cycle, we will use half of this number: 1365333. Apply this duty cycle to each chip by running the following commands:

Step 4

We will now enable each line. The colors for each chip are as follows:

pwmchip0: RED

pwmchip1: GREEN

pwmchip2: BLUE

To enable the colors, run the following commands:

Running these commands in succession should enable the LEDs in a RED, GREEN, BLUE pattern until you reach a white LED.

Controlling the onboard LEDs programmatically

Introduction

This "Project Guide" is written to show some of the capabilites of NavQ. In conjunction with a Teensy LC and a strip of WS2812B LEDs, you can add a forward-facing battery indicator light to your drone.

Prerequisites

Software

The software needed to run this project on your NavQ is as follows:

1. ROS Noetic

2. MAVROS

You can install this software using the guides here:

Hardware

The hardware needed is the same as the hardware from the I2C guide here:

Code

At the moment, we're just going to paste the code here, and a more detailed guide will be written later.

Teensy code

This code should be uploaded to the Teensy using the Arduino IDE.

NavQ code

The ROS node should be placed in the home folder ('/home/navq/')

The service file should be located in /etc/systemd/system/.

The Launch script should be located in /usr/local/bin/.

Making the ROS node run on boot

Once all of the necessary files are placed in their respective directories, you need to make the systemd service run at boot. To do this, run in the terminal:

MAVLink / MAVROS

The 8MMNavQ can control your HoverGames drone by communicating with the RDDRONE-FMUK66 over MAVROS. A UART cable will be included in the kit that connects the UART3 port on the 8MMNavQ to the TELEM2 port on the RDDRONE-FMUK66.

ROS on NavQ

ROS on NavQ will allow you to interface with sensors, control your drone using MAVROS, and more. To get started, follow the install guide below and then continue to the next sections.

Creating a systemd service to auto-start the microRTPS agent on NavQ

Generate a start up script for the micrortps client under /usr/local/bin

with content

Save the file and exit nano. Make the file executable

Generate a systemd service file to start the startup script at boot

with content

Save the file and exit nano. Check if the process starts

You should see an state active (running), quit with <q> Enable the systemd service file finally to be active at boot

Auto-start the microRTPS client on the FMU

Building PX4 with microRTPS

In order to use the microRTPS client on NavQ, you'll need to build PX4 with the _rtps tag for the fmuk66-v3 build target. To do this, you will need to have both the FastRTPS and Fast-RTPS-Gen packages installed. You can just follow the previous guide on your Linux development VM or computer.

Once you have successfully installed those two packages, you can navigate to your cloned PX4 repository and run the following:

Flashing your FMU with the updated binary

You will need to flash your FMU with the updated RTPS binary. If you don't know how to do this yet, follow the guide here:

Creating a startup file on the SD card

To make the microRTPS client start at boot on the FMU, you will need to have an SD card inserted. On your SD card, make a file at /etc/extras.txt and insert one of the following options:

Please refer to the following pyeIQ documentation:

Note that eIQ support is only included on imx-image-full-imx8mpevk.wic pre-built image [1]. *** THIS IMAGE is only for 8M Plus!

Please take a look on switch_image application, we are using TFLite 2.1.0. This application offers a graphical interface for users to run an object classification demo using either CPU or NPU.

# pyeiq --run switch_image

We also have a TFLite example out of pyeIQ, please refer to instructions below. Details can be found on i.MX Linux User's Guide [2].

# cd /usr/bin/tensorflow-lite-2.1.0/examples

# ./label_image -m mobilenet_v1_1.0_224_quant.tflite -i grace_hopper.bmp -l labels.txt

The i.MX Linux User's Guide [2] also provides instructions on how to get our latest Linux BSP [1] up and running. *** NOTE FOR 8M Plus only!

[1]:

[2]:

FastRTPS and the microRTPS Agent

FastRTPS and the microRTPS agent are needed on NavQ in order to bridge uORB topics from PX4 to ROS2 on NavQ over a UART or UDP connection. Follow the guide below to build and install these packages.

Follow the link below for more details on microRTPS and PX4 ROS Com:

Installing FastRTPS and PX4 ROS Com on NavQ

Prerequisites

FastRTPS installation

First, we will install the FastRTPS project from eProsima. Use the following commands below to do so:

px4_ros_com installation

Next, we will build and install the necessary software that will allow us to use ROS2 to communicate with the microRTPS bridge. First, run the following commands:

Run the following commands to enable a 1GB swapfile:

Now, build the workspace:

Sourcing ROS2 bash files

In order to run all of your specific ROS2 software successfully, you must source the install/setup.bash files in each of your ROS2 workspace folders. Add the following lines to your .bashrc to do so:

Next steps

Continue to the next page to set up a systemd service that will automatically start the micrortps agent on your NavQ. The guide will also cover how to automatically start the client on the FMU.

With OpenCV on NavQ, you will be able to harness a vast library of computer vision tools for use in HoverGames. OpenCV is installed out of the box on the HoverGames-BSP image and can be installed easily through the package manager on the HoverGames-Demo image. If you'd like to get a jump start on OpenCV, follow the guide below to create a program that detects red objects.

Quick Example

Let's go through a quick example of running OpenCV on the NavQ to identify a red object in an image taken on the Google Coral camera. This example will be written in Python and uses OpenCV.

Installing OpenCV

If you are using the default OS that is shipped with the NavQ, you can skip this step.

If you're using the HoverGames-Demo image, you'll need to install python3-opencv. To do so, run the following command in your terminal:

Imports

First, create a new python source file (name it whatever you want!). We only need two imports for this program: opencv (cv2) and numpy. Numpy is used to create arrays of HSV values.

Capturing an image

To capture an image, we must first open a camera object and then read from it.

Downsizing the image

To make our OpenCV pipeline run faster, we're going to shrink our image down to 640x480 resolution. This resolution isn't so small that the image quality will be reduced enough to make a difference in detecting objects, but it will make OpenCV process our image much quicker.

Another pre-processing step that we will run is a box blur. This will get rid of small artifacts in the image that can throw off our pipeline and will make detecting large objects much easier.

Color filtering

In order to find objects that are red in our image, we will apply an HSV filter to the image to create a mask of the color red in the image.

Finding contours

To find the location of the objects in our image, we will find contours in the mask and sort them by total area. This will allow us to filter out smaller objects that we aren't interested in. We will also be able to detect the objects' position in the image and draw a box around them.

Storing the generated images

Finally, we will store the images we generated from this program: the mask and the final image with annotations (bounding box and text).

Running the code

To run the code, you'll need to use python3. Run the following command (<file.py> will be the filename that you saved the code to):

Source code

Here is the complete source code if you'd like to run it on your own NavQ as an example:

ROS2 Foxy Fitzroy Install Guide

Follow the guide at the link below to install ROS2 Foxy Fitzroy on your NavQ running the Demo image.

Gazebo is one of several simulators that work with PX4 and ROS.

Simulation is important in order to test code without risk of damaging real hardware. It can be critical in uncovering faults that would otherwise be very difficult to trigger. This is not a tutorial on Gazebo, but a list of some resources to get started.

• PX4.io Gazebo developer guide https://dev.px4.io/v1.9.0/en/simulation/gazebo.html

• Youtube videos e.g.

• Read about .

• Try out , which is a fun way to learn both Gazebo and ROS. (smile)

What is telerobotics?

Telerobotics is a platform in which robots can be controlled over the internet. A good example of this is Twitch Plays. Twitch Plays allows users to play games on a stream by giving commands through Twitch Chat.

Now you may be wondering, "Well Twitch Plays isn't controlling a robot, that's a video game!" and you'd be correct. There is an alternative for robotics though! It's called Remo.TV, and we have written a module for the NavQ to be supported on the site.

Remo.TV is a website where anyone can log in and control robots over the internet. With NavQ, your family and friends can easily control your HoverGames Drone or NXP Cup Rover through Remo.TV. Below we have written a guide for you to set up your drone or rover with the service.