Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
NavQ Linux companion computer platform with Vision for Mobile Robotics based on NXP i.MX 8M Mini SOC. Found at: https://nxp.gitbook.io/8mmnavq/
NavQ was used in HoverGames2 program and this document is supporting information. However it was not commercialized. The NavQPlus (NavQ+) is the replacement upgraded version of NavQ available on NXP.com and through global distributors.
Note that some software and information here is still completely relevant to NavQPlus NavQ may also be referred to as: 8MMNavQ, MR-8MMNavQ or RDDRONE-8MMNavQ
Also take a look at some of our other Gitbooks:
The 8MMNavQ is a small purpose built experimental Linux computer based on the NXP i.MX 8M Mini SOC. 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.
Please check for Linux updates regularly. Feedback and needs will be incorporated and updated as much as possible and reasonable.
There is a discussion forum here for questions specifically about NavQ
And a general HoverGames forum here.
The 8MMNavQ features:
NXP i.MX 8M Mini SOM with LPDDR4 DRAM and eMMC Flash.
A secondary board with SDCARD, Networking, MIPI-CSI (Camera) and MIPI-DSI (Display) interfaces
MIPI-DSI to HDMI converter
A Google Coral camera module
A third HGI (HoverGames Interposer board) with common interfaces and specific drone and rover interfaces which follow PX4 standards.
The NavQ is suitable for many purposes, including generic robots and various vision systems.
Drones, QuadCopters, Unmanned Aircraft, VTOL
Rovers
Road going Delivery Vehicles
Robotic Lawnmowers
Robotic Vacuum
Flying vehicles (PX4)
DIYRobotCars
Marine vessels
Camera and Vision processing modules
Time of Flight (TOF) Cameras
AI/ML inference
Cellular gateway
Vision systems in other applications
e.g a hospital bed monitor that detects if a patient is sitting up or at risk of falling out of bed.
Two specific complete developer tool examples are the NXP HoverGames Drone, and the NXP-CUP car.
The NavQ was prepared with the intention of working with and supporting the NXP HoverGames Drone program
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
Tensorflow
pyeIQ
And more!
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.
Here are a few videos of some of the capabilties of NavQ:
- newer supported version, available on NXP.com
challenges
- car/buggy racing series
This work is licensed under a Creative Commons Attribution 4.0 International License.
NavQ is a companion computer reference design for HoverGames and commercial development of drones and rovers.
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.
As a result of HoverGames planning, the NavQ also makes a great companion computer for many other PX4 or Ardupilot flight controllers
HoverGames specific features include
NavQ can connect to HoverGames (RDDDRONE-FMUK66)
via serial
via Ethernet (using 100BaseT1 2 wire ethernet adapter)
via USB (requires specific configuration)
RGB LED onboard for status reporting
USB-C console for debugging
Power input via USB-C or JST-GH power header
MicroUSB port for peripherals (hub, usb cameras, sensors)
IX industrial Ethernet jack
Serial ports using JST-GH connectors
I2C/SPI port using JST-GH connectors
3 wire LED strip connector with power supply
Wifi and Bluetooth
MIPI Camera intereface (Google Coral Camera default)
eMMC and removable SDCard memories
MIPI DSI for display (particularly for Rover applications)
The SOM includes the processor, RAM, memory, and WiFi chip for the NavQ.
The NavQ SOM (System on Module) contains the brains of the NavQ. On this board, we have our i.MX 8M Mini processor, 2GB of LPDDR4 memory, 16GB of eMMC flash storage, and a QCA9377 WiFi AC + BT 5.0 chip. There are connectors on the bottom of this board that allow for modularity.
The NavQ's dimensions are 3" W x 2" L x 7/16" H.
The Media Board consists of an SD Card slot, MIPI connectors for a camera serial interface as well as a display serial interface, and a PCIe connector.
Image of Google Coral Camera + MIPI to HDMI Adapter:
The Google Coral Camera dimensions are 25mm x 25mm, as shown in the tech specs here:
https://coral.ai/products/camera/#description
The HoverGames Interposer Board (HGI) is the final board in the stack and has a multitude of I/O for your needs in HoverGames. Connect sensors, switches, and LEDs to the NavQ using the HGI to drastically improve your drone system, and even control your drone using NavQ using offboard control with MAVROS.
Name
Details
NXP i.MX 8M Mini Processor
Quad ARM Cortex-A53, Cortex-M4 @ 1.8GHz
LPDDR4 Memory
2GB
eMMC Flash
16GB
Qualcomm WiFi/BT
802.11ac + BT 5.0
Name
Details
SD Card slot
MicroSD card compatible
MIPI CSI
Google Coral Camera connection
MIPI DSI
MIPI to HDMI adapter for full desktop
Name
Details
UART
3 UART ports for serial communication through JST-GH connectors.
USB-C
Powers the board and serves as an interface for flashing new firmware.
MicroUSB
Connect USB devices to this port such as keyboards and mice. USB hub included.
SPI
JST-GH connector for SPI interface.
Hirose IX Industrial Ethernet
IX Industrial ethernet cable is included.
2 Wire Automotive Ethernet
JST-GH connector for 2-wire ethernet as well as GPIO.
JTAG
Pads are available for JTAG. You may solder your own JTAG connector.
Boot Mode Switches
You can use these switches to boot from eMMC or SD card, or boot into fastboot.
GPIO
Through-hole points for GPIO headers.
RGB LED
WS2811 RGB LED available for status
NavQ as provided is an experimental board
NXP Friendly Linux is experimental and in development
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.
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)
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:
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.
Board
Rev
Item
RDDRONE-
HGI-1A
PTN5110 FAULT_N should be pulled up
and connected to INT of NX20P4383UK
Board
Rev
Item
RDDRONE-
MEDIA-1A
The design is missing a power switch required by the SD 3.0 standard
These components are designed to interface and work with the NavQ.
Unless otherwise indicated, the following add on modules are not included with the NavQ HoverGames 2 kit (HG2).
In addition They may not all be available, and may be experimental in nature.
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.
100BaseT1 2-Wire Automotive Ethernet media converter
Additional RDDRONE-T1ADAPT media converter details can be found here: https://nxp.gitbook.io/rddrone-t1adapt/
NXP's TJA1101 is an Ethernet PHY that provides a two-wire 100BaseT1 Ethernet interface. The Ethernet MAC side of this interface is not unusual, and the traffic on the line is "regular Ethernet"
NXP's Flight controller for Mobile Robotics - RDDRONE-FMUK66 includes a 2-wire Ethernet interface on board. In order to connect this with the 8MMNavQ this media converter can be used. The RDDRONE-T1ADAPT is also useful when connecting to other experimental modules such as V2X or an Automotive 5/10 port switch.
On RDDRONE-T1ADAPT power is supplied via a 3 pin JST-GH connector. There is a matching 3 pin JST-GH connector on the 8MMNavQ. A simple 1:1 cable is used. Optionally a USB-C cable can be used to provide power (only) connection. A 2 pin JST-GH connector is used for connecting Ethernet between this board and another - such as the RDDRONE-FMUK66. A simple 1:1 cable is used.
There are also locations marked on the bottom side of the board for soldering in wires for both power and 2-wire Ethernet
There is a small NXP LPC processor on board to configure the back to back PHYs and manage setup and LEDs. This board comes pre-programmed and there is no user software required. Contact hovergames@nxp.com or your local NXP representative if there is a specific need to access the software.
How to order your own NavQ
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
NavQ has been superseded by NavQPlus. As of Dec 2022, there are no original NavQ available to the general public. (Commercial customers can work directly with EmCraft on build to order) . Following HoverGames3 competition a commercial version of NavQPlus EVK will be available in 2023 on :
:
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.
NXP has a tool for flashing i.MX hardware called UUU (Universal Update Utility). You can download UUU from here:
It is recommended to download the "Latest Release", not the "Pre-Release" at the top of the page.
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.
You must agree to all of the applicable licenses and agreements at the following link before downloading the Linux software. It is hosted here:
NOTE: This file is only needed for flashing with UUU to the eMMC/SD Card. If you want to flash your SD Card with dd or Win32DiskImager, this file is not needed.
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:
Once you're done flashing, you can use this image to select the boot mode: eMMC or SD card.
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:
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:
There are advantages and disadvantages to each storage medium. eMMC is faster, but is locked to 16GB size and is non-removable. SD cards can be of any size you like and are removable, but they are quite a bit slower.
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!
To flash the image, you'll need to use dd
on Linux/Mac or Win32DiskImager
on Windows.
Replace the X in "/dev/sdX" with the letter of your SD card in linux. You can use a program like "GParted" or "Disks" to find the letter of your SD card.
Replace the X in "/dev/rdiskX" with the number of your SD card in Mac. You can use diskutil list
to find the number of your SD Card.
Download Win32DiskImager:
Currently the HoverGames-Demo Linux image is packaged as a .img file. In future releases, it may be packaged as a .wic.bz2 file. If it is packaged as a .wic.bz2 file, you'll want to extract the .bz2 file before flashing using Win32DiskImager.
Open the program and select your SD card. Choose the .wic OR .img file, then click "Write".
Ensure your NavQ is working correctly with these fixes
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.
These fixes are for the build on 7/24/2020. This page will be updated for each new release.
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 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.
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.
This script should be in the home folder of the demo
image. If it isn't there, or if you lost it and need it, it is linked below.
To run the script, run the following commands for the boot device you're currently using:
For eMMC:
For SD card:
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:
If you don't want to use the script, you can run the commands below.
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:
If you're on the eMMC, you'll use /dev/mmcblk2. If you're on an SD card, use /dev/mmcblk1. By default the NavQ boots from the included SD card in your kit.
Once you're done with those steps, run this command:
and reboot. You should now be able to install ROS Melodic without size issues.
If you prefer to just see the commands, these are the commands you need to run in fdisk in order to resize your disk.
mavlink-router routes MavLink data dynamically between several end nodes
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
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:
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
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 - https://github.com/intel/mavlink-router/blob/master/examples/config.sample
As of today the mavlink-router make install does not create the /etc/mavlink-router directory and main.conf file. Therefore please use the following commands to create the directory and file initially.
~$ sudo mkdir /etc/mavlink-router
~$ sudo touch /etc/mavlink-router/main.conf
The configuration above assumes that the NavQ gets mavlink data from FMU either via UART3 (/dev/ttymxc2) or UDP. If you use UART please set on the FMU the corresponding serial port to 921600Bd. For this the SER_TELx_BAUD (x = number of telemetry port) parameter needs to be adjusted to 921600 8N. If you use lower speed QGroundControl might fail to load parameters.
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.
Enable the auto-start of mavlink-router
via systemd
and start it
You can check the status of mavlink router using the command
T1 Ethernet between FMUK66 and NavQ
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 RDDRONE-T1ADAPT media converter.
The 8mpNavQ or "NavQPlus" will have two Ethernet interfaces. it is planned that one of these interfaces will natively be configured as 100BaseT1
It is not recommended to use DHCP in a vehicle such as a drone, since you generally don't want the network to change without knowing about the explicit details. Therefore since there is no DHCP and FMUK66 by default has a fixed IP of 10.0.0.2, we need to set a fixed IP on the NavQ for eth0
to be able to communicate via Ethernet to FMUK66.
It is suggested to use IP address 10.0.0.3 for navq.
The linux program connman
is used for configuring the network settings . To force connman
to use a fixed IP ( as in case when no DHCP is available) the following file needs to be created.
It is important is that you have a Ethernet cable connection before, otherwise connman will not register the network.
The IP4 settings are in the order of ownIP/netmask/router. Note that 10.0.0.3 is set as router since in this particular hardware configuration no other device is there.
T1 Ethernet is supported by PX4 on FMUK66 with latest master.
To enable the RDDRONE-FMUK66 mavlink telemetry via UDP sending to a specific IP you must add the following file on the FMUK66 SDcard:
/etc/extras.txt
In the example configuration above, 10.0.0.3 is the IP address of NavQ on the vehicle. More detailed description of the mavlink start parameters can be found here: https://dev.px4.io/v1.9.0/en/middleware/modules_communication.html
Additionally the MAV_BROADCAST parameter on the FMU needs to be set to "2 - only multicast".
Distributing MavLink data can be done by installing mavlink-router on NavQ.
Connecting to the root console on NavQ using the USB--UART adapter
The root console will allow monitoring of the board from initial boot. Since modern PCs don't tend to include serial ports anymore, a small FTDI USB-UART adapter is provided to convert the serial port to USB.
Plug the 6 pin JST-GH cable from the USB-UART converter into NavQ connector "UART2/I2C2"
Plug the USB-UART into your pc like you would a dongle or memory stick
Your PC operating system should respond right away when it recognizes the USB-UART. On windows it will play a "usb connect sound"
There should be a red light illuminated on the USB-UART board (even when not plugged into the NAvQ)
Follow the terminal configuration below and power on the NavQ
Troubleshooting Tip: If the COM port does not show in Device Manager or you don't hear the "usb connect sound" double check that the USB-C connector is fully plugged in and seated into the USB-UART adapter board.
Troubleshooting Tip: If the USB UART is not detected on your PC, in some instances you may need to download FDTI USB-UART driver software. It can be found here: https://www.ftdichip.com/Drivers/D2XX.htm
A terminal program will be required to communicate over the serial console. The following example is for a Windows 10 PC using the terminal program PuTTY.
Default NavQ terminal settings are: 115200 Baud, N, 8, 1 (no Parity, no flow control)
In Windows 10 use Device manager to determine which COM port is assigned to the FTDI USB-UART serial adapter. The open PuTTY window shown below is the root console of the NavQ.
There are several options for a terminal program that can be used. This example is for PuTTY on a Windows PC. Other programs and other hosts can be used. Example using PuTTY to connect to the serial console via a USB-UART adapter. In this example the COM port was determined above by looking at Windows 10 Device manager.
How to mount the NavQ using the plate and standoffs provided
The suggested method of mounting the NavQ to the Drone frame is shown below. Improvements and suggestions are welcomed. Please message on community.nxp.com here: https://community.nxp.com/community/mobilerobotics/hovergames-drone-challenge
Use two of the Hex standoffs together to make ~35mm total standoff height between the top plate and the NavQ mounting plate
The NavQ can mount to the small carbon fiber plate using screws, standoffs or double sided tape.
We did allow for mounting the NavQ with screws, HOWEVER one of the three mounting holes did not get drilled. Please drill the third hole by hand if you wish to mount with screws. Alternatively you can use two screws and some double sided tape for the missing screws. You should use tape or a 3rd hole, because otherwise the board will vibrate too much.
Note the use of short hex standoffs instead of nuts under the main top-plate because they are easier to hold with needle nose pliers without needing to disassembe the complete frame.
One modification tried was to add a second standoff "hanging" from the front so that the camera module could stick between these two front standoffs to with double sided tape.
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
Assuming you already have internet access on your NavQ, to install nano on the demo image type the following.
Suggested proposal for the hostname of NavQ
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:
e.g. If Mavlink SysID is 10 the NavQ should be named navq-10
After a reboot the new hostname will be visible on the network.
Some discussion on the topic:
This section is for various linux commands that may be useful when using the NavQ, and the Demo image.
We have two separate Linux distributions that you can build for NavQ. There are pros and cons to both.
The HoverGames-BSP image is based on NXP's Yocto BSP for i.MX 8M Mini. This distro is not as easy to use, and requires much more effort to get a working system, but currently it is the only system that is allowed for use if you want to use NavQ commercially. If you need tight integration and a small system that has only the packages you need installed on it, or if you're a company looking to use the NavQ in production, this is the one for you.
The HoverGames-Demo image comes with the APT package manager as well as some other pre-installed software specific to i.MX 8M Mini. This distro is the easiest to use due to it's great compatibility with pre-existing binaries coming from official repositories. You can install ROS, OpenCV, and more on this image just as you would on a normal desktop computer. This makes the Demo image great for quick development and iteration. To use this image, you must agree to a Demo license stating that you will not use NavQ comercially with this distribution.
You'll need to use a computer with Ubuntu 18.04 installed, and we recommend a high amount of cores + RAM to build these images in a decent time frame. You will also need a large HDD or SSD (>500GB) to store the build files. A table of recommended specs are below:
Follow the guide at Yocto's website to install the necessary build tools for Ubuntu/Debian, or just install the list of packages below:
We have a GitHub repo with instructions for both the HoverGames-BSP and HoverGames-Demo images. The BSP image can be built using the master
branch, whereas the Demo image can be built using the demo
branch. The link to the repo is below.
Component
Recommended Hardware
CPU
Recent 6-core Intel i-Series or AMD Ryzen processor with HyperThreading or SMT (Simultaneous Multi-Threading)
RAM
16GB DDR4 or more
Storage
500GB SSD recommended, HDD will suffice but will be slow
Operating System
Ubuntu 18.04 (Not 20.04!)
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
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.
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.
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.
NOTE: ROS1 support is good, but the Mobile Robotics team at NXP's focus is on ROS2. There is a lot more documentation on ROS1 than ROS2, but ROS2 may be easier to use in the long run. We suggest that you do not cross-polinate with ROS, i.e. only use ROS1 or ROS2, not both. Keep in mind that any documentation under the ROS1 section is for ROS1 only, and vice versa.
NOTE: HoverGames participants should be using the Demo image. If you flashed your NavQ with the image from the HoverGames website, or if you're using the image that came installed on the SD Card included in your kit, you're using the Demo image.
When you install ROS Noetic on your NavQ, make sure to install the base version of ROS and not the desktop version. If you install the desktop version, critical gstreamer packages for NavQ can be overwritten and therefore become non-functional.
To install ROS, you need to be on the Demo image. You can follow the guide for installing ROS Noetic Ninjemys at http://wiki.ros.org/noetic/Installation/Ubuntu
If you're using NavQ comercially and are running the HoverGames-BSP image, you'll follow these steps.
ROS Melodic is automatically installed on the HoverGames-BSP image. It includes MAVROS by default. You will need to do a little bit of setup, though, once you first boot your image.
Run the following commands to enable ROS on the HoverGames-BSP image:
You'll also want to download the following script and run it to install GPS geoids:
Now, you can continue with the ROS tutorials for setting up a build environment and installing your first package. We will go over this in the next section.
NOTE: ROS2 is new, but we suggest you use it over ROS1, as ROS1 will be deprecated in the near future. You may run into issues with the ROS2 section of this Gitbook. If you have any issues with the guide, please email landon.haugh@nxp.com if external, or use Teams/Email if internal. MAVROS is not compatible with ROS2. MicroRTPS and PX4 ROS Com replace MAVROS.
Follow the guide at the link below to install ROS2 Foxy Fitzroy on your NavQ running the Demo image.
Note 1: at Setup Sources step you might get an error message by curl. To avoid this, run the following commands:
Note 2: at Install ROS2 package step, run the ros-foxy-ros-base
installer, as the Desktop tools are not needed on NavQ:
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.
NOTE: FastRTPS and PX4 ROS Com work differently from MAVROS (ROS1). PX4 ROS Com subscribes to uORB topics rather than MAVLINK messages. See below for a diagram of how microRTPS and PX4 ROS Com works.
Follow the link below for more details on microRTPS and PX4 ROS Com:
First, we will install the FastRTPS project from eProsima. Use the following commands below to do so:
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:
URGENT: Building px4_ros_com requires a lot of ram. Enabling a swap disk is highly recommended. This will take up 1GB of space on your storage medium.
Run the following commands to enable a 1GB swapfile:
Now, build the workspace:
This will take a long time to build on NavQ. In our experience, it takes anywhere from 45 minutes to an hour. Make sure you have a stable connection to NavQ over UART or SSH, and do not let the NavQ lose power!
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:
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.
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