Experimental nature

Because NavQPlus is experimental and contains a new set of boards and peripherals, please expect and plan for software enablement to undergo several iterations. Our intent is to provide an Ubuntu PoC (Proof of Concept) "user-friendly Linux" with typical packages and additional tools included, rather than the traditional Yocto-based distribution that is typical of the highly optimized and stripped down Linux operating systems used in deeply embedded products. Since this Ubuntu PoC is also built on top of Yocto, it is still able to be reduced and optimized for full commercial deployment as well.

Building the Linux image from source is complex and time consuming. A 3rd party has prepared a docker image which can be used and instructions to be followed in order to be successful in building from source without being an Expert. Please follow this guide in order to build the latest image from source, in a docker window.

Install I2C tools

If not already present, the first step is to install the I2C tools to be able to use the I2C ports.

Adjust I2C user 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:

Check the I2C connection

Now to check the connection and confirm that the port is working correctly. Connect something to the I2C JST-GH port, then run the command below. It shoudl show you raw output from most devices connected on the I2C bus(es). Note that the onboard NXP secure element SE05x will not respond to this command.

Example

The official schematics for NavQPlus are published on:

A copy is provided here for convenience, but note that it is possible that it becomes out of sync/out of date with the official source. Please use the NXP official source for any critical requirements.

Note that NavQPlus is an open design using i.MX 8M Plus SOC from NXP. The SOM used is identical to the one on the larger NXP EVK. The carrier board includes a number of additional features and has its own BSP derivative in order to support these components. You are welcome to reproduce or modify the carrier board to your own specifications.

NavQPlus Carrier board

This is the main board for NavQPlus (8mpnavq) and can be used to reference the connectors and test points.

NavQPlus SOM module

This SOM is identical to the NXP EVK SOM, with the exception that the IO are jumped for 3v3 voltage instead of 1v8

Typically embedded processors will operate without a desktop environment. Also note that an desktop environment is different from simply outputing graphics using something like QT.

• XFCE4 was used by HoverGames3 participants, running on vncserver (so accross a network through ssh rather than locally through HDMI output.) 12/28/2022

Introduction

The 8MPNAVQ or "NavQPlus" is a small purpose-built Linux computer evaluation kit (EVK) based on the . It is focused on the common needs of mobile robotics systems, with a small form factor, -compliant JST-GH connectors, and available software stack including Ubuntu Linux and .

The entire design is available for companies building their own similar hardware. NavQPlus 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.

Note that the SoM is almost identical to the larger with the exception of the I/O voltage level being changed to 3.3V. This makes NavQPlus an excellent stepping stone or bridge from the large EVK to a system that can be duplicated for testing in situ, or even copied directly for your application.

Features

1. NXP i.MX 8M Plus SoC on a SoM with LPDDR4 DRAM and eMMC flash.

   • 4x Arm Cortex-A53 core

   • 1x Arm Cortex-M7 core

Block Diagram

Applications

The NavQPlus is suitable for many purposes, including generic robots, various vision systems, and AI/ML applications.

• Unmanned Aerial Vehicles (UAVs)

  • Such as multicopters and VTOL (Vertical Take-off and Landing) aircraft

• Rovers and other unmanned ground vehicles (UGVs)

Two specific complete developer tool examples are the , and the .

Software

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

• ROS/ROS2

• OpenCV

• GStreamer

The 8MPNavQ 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.

Feedback

Introduction

General specifications have been requested for NavQPlus. Currently there are no official qualified specifications.

Physical Hardware

The CAD model below and associated measuring tools can be used to determine physical characteristics of interest. The model may also be downloaded in a variety of file formats by following the link to open in Fusion360.

Electrical Specifcations

PLEASE NOTE: These are unofficial specifications only. The values below may be used for guidance, but are not guaranteed.

Voltage input

• 5-20V

• Power supplied via High voltage USB PD power switch(es)

  • Power input and can be from dedicated connector or through USB-C

Power consumption

• A detailed power analysis has not been done. Below are estimates

  • Expectation is MAX 5W and typical 3W

  • 5W =~12V@450mA

Enclosure dimensions

• CAD files available for board outline and case though the

• 90mmx70mm exclusive of case mounting tabs

• Tabs 82mm at max width.

Weight

• 98.4grams with Fin type heatsink attached*

  • * production units use a flat aluminum plate which reduce weight further

Please refer to the NXP.com landing page https://www.nxp.com/navqplus for NavQPlus for availability, pricing, availability and distribution channels.

NavQPlus Part numbers

PLEASE NOTE: There are currently TWO variants of the NavQPlus available the part numbers start with 8MPNAVQ:

• 8MPNAVQ-8GB-XG This variant does not include the IX Industrial gigabit ethernet Connector and PHY on board. All other components are installed including 100BaseT1 and WiFi. Ethernet over USB-C "gadget mode" is also available.

• 8MPNAVQ-8GB-G This variant includes the IX industrial connector and Gigabit Ethernet PHY

Third party manufacturers

Presently the following third party companies are able to provide commercial support for NavQPlus, including software support, prototyping derivatives, and/or volume manufacturing of the SoM or carrier board. Please contact the NXP Mobile Robotics team if you have a variant that you would like to let people know about:

Refer to the HoverGames disclaimer below when using NavQPlus with a drone or similar vehicle.

It is expected as a user of NavQPlus, you will have basic knowledge of how to operate an embedded Linux computer in a headless terminal environment. While NavQPlus can support a desktop environment, it is not a "PC" or desktop computer, and therefore many graphical applications designed for these devices will not work due to device specific libraries and graphics drivers.

Resources:

If you are not comfortable operating a Linux computer in a terminal environment, below are links to some resources that may help.

BSD-3 License

Example code shown in this document has the following copyright and BSD-3-Clause license:

Copyright 2023 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 must be 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 HOLDER 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.

FCC information:

• Contains Transmitter Module FCC ID: VPYLB1ZM or Contains FCC ID: VPYLB1ZM

• FCC CAUTION: Changes or modifications not expressly approved by the party responsible for compliance could void the user’s authority to operate the equipment.

• This transmitter must not be co-located or operated in conjunction with any other antenna or transmitter.

Canadian IC information

• Contains IC: 772C-LB1ZM

NavQPlus is an open design and 3rd parties may create add-on modules

Contact the vendors below for more details:

Emcraft:

• TOF camera from PMD

• Several RPI camera modules

• mini PCIe adapter

Google

• Coral Cam

• Coral TPU Neural net accelerator

NavQPlus is a standalone embedded linux device. There are many peripherals that will attach and interface with it, or can be made to interface with the correct drivers. In addition, the Mobile Robotics team works with several complimentary devices and boards which work with the NavQPlus:

• MR-B3RB (Buggy3 RevB): a robotics platform in the form of an ackermann steering small car

• iRobot Create3: AKA Turtlebot 4, ROS development platform

• RDDRONE-T1ADAPT: Adapter board from 100BaseT1 to RJ45

• MR-T1ETH8: T1+RJ45 Ethernet Switch

• MR-CANHUBK344: MCU board with S32K344, 6 CAN , T1 Ethernet

  • CANHUB-ADAP: plug on board with IMU and GPS connectors

• MR-VMU-RT1176

  • Pixhawk V6X standard Vehicle Manangement Unit, with IMU

    • Note both NuttX and Zephyr Supported on this platform

• RDDRONE-BMS772: Battery Management 6S

• UCANS32K146: CAN Node board

• HDMI displays (Many off the shelf small displays)

Refer to nxp.com/navqplus order page for the exact details on what is included in the NavQPlus version that you have ordered.

The exact contents is based on the version kit ordered, Typically the following items are included:

• 8M Plus SOM + Baseboard, flat heatsink, 3d printed enclosure

  • Wifi Antenna attached

• Communications cables

  • FTDI USB-UART Serial console cable and adapter board/Cable

  • IX-industrial to RJ45 Ethernet cable (not on -XG version)

• Power Cables

  • 5-Pin JST-GH power cale to RED SYP type cable

  • RED SYP type cable to XT-60 battery connector

• Camera

  • Omnivision OV5645 on innowave module. (typical)

  • Several cameras are available to connect to the MIPI CSI interface.

The NavQPlus is an embedded Linux device. You will need terminal access via a PC or Laptop in order to interface with the board. While a Windows PC can have terminal programs, you will find that working in a Linux host environment will allow you greater flexibility, capability and being able to cross compile software more easily. Most examples will be shown assuming a linux host PC running Ubuntu 22.04 or later is attached.

Ubuntu Desktop

Learn about installing Ubuntu Desktop on a development PC using the link below:

https://ubuntu.com/download

NavQPlus Enablement

NavQPlus has specific enablement that is not typically found in generic EVK's from NXP. , and other software has been enabled in order to work with robotics development systems. Consider using the a pre-built binary or following the 3rd party reference on

Introduction

This chapter will cover the basics of connecting to the NavQPlus.

For a quick setup guide follow the instruction on the previous chapter. For more detailed information follow the hardware reference section.

The NavQPlus kit comes with an FTDI type USB-C to UART adapter cable and a small adapter board for this cable to the serial port JST-GH connector . This adapter is used for a serial debugging console on the NavQPlus.

USB to UART adapter

Executive Summary: Connect the included USB to UART adapter to the UART2 port on the NavQPlus, and open your favorite serial console application (e.g. PuTTy for Windows users, Minicom on Linux). Open a serial console and set the baud rate to 115200. If there is no output on the screen, try to press enter to get a log-in prompt.

Connect USB cable+ adapter to your computer. Then plug in the JST-GH connector from the adapter into UART2 (A53 Debug/Console) port on NavQPlus.

Serial Terminal Software

Use your favorite serial console software such as PuTTY (Minicom, MobaXTerm, or screen) to access the NavQPlus serial console directly.

Console Baud Rate

The baud rate is 115200.

Successful Boot?

If correct code was loaded, and the boot switches also set back to the correct boot source (SDCARD vs EMMC), then in the terminal software you should see the Linux boot details printing out.

Default username and default password

The system will ask for the username and then the password. The default username/password is as follows:

At this point you can start using Linux on the NavQPlus.

Ubuntu PoC

The software available for the NavQPlus includes an Ubuntu Desktop environment based on Ubuntu opensource distribution as a Proof of Concept (PoC). It should be clearly noted that this Ubuntu PoC is NOT an official Canonical distribution.

Canonical outlines this mission philosophy of supporting free and opens software here:

Canonical Ubuntu commercial support

Canonical does independently support commercial development on NXP i.MX processors and they are available on a contractual basis to provide commercial support for Canonical Ubuntu on NXP processors.

3rd Party Commercial Support

The NavQPlus was prepared in cooperation with one of our Gold partners Emcraft. It should be noted that various NXP partner program partners are available for commercial support including hardware and software support. Please refer to the NXP partner program webpages for further details:

NavQPlus should boot normally after applying power. While booting, the device will output detailed status information to the serial console, accessible on the UART2 connector. Using the console can provide invaluable debugging information that is difficult to find elsewhere. Once the boot process has completed, the system console is also available by starting an SSH session over (USB-)ethernet or Wi-Fi.

Power requirements for successful boot

If the applied voltage at PWR_IN is too low, the boot process could hang upon initializing the CPU in the Linux kernel. Please make sure that your power input is 5-20V. The NavQPlus has relatively low current requirements and typically will not draw more than 4 watts of power when all on-chip peripherals are enabled, however the board may also supply power to external devices. Ensure that your power source is able to maintain a stable voltage level at the requested current.

U-Boot - Observe full boot process through the serial console

The boot process starts with U-Boot, loading the device trees in the boot partition and loading the Linux kernel. If you desire to observe the complete boot process, you will need to monitor the output on by using the provided USB to serial converter cable.

Shell login

Once the NavQPlus has booted to the shell, the default login credentials are as follows:

Username: user Password: user

Following these 8 steps, you will be able to start using the NavQPlus in no time. When needed, more information is available in the detailed instructions chapter. Also checkout the TurtleBot4 / iRobot Create3 documentation, and the other parts of this GitBook.

1. Download an Ubuntu image

Download the latest Ubuntu image for NavQPlus (in .wic file format) from GitHub:

• For use with iRobot Create3 (AKA Turtlebot4)

• For use with NXP MR-B3RB

2. Download the UUU tool

uuu is an NXP command line tool that runs on a PC and can commnicate directly with the MPU on the NavQPlus. To flash the eMMC memory on your NavQPlus (next step), you will also need to download the uuu tool ("Universal Update Utility"). Download the latest release from GitHub:

Make sure to download the correct application for your platform. The .exe file is a Windows executable. The file named "uuu" without extension is a x86/64 Linux binary.

3. Set the boot switches to flash mode

Before plugging in the board, find the  on your NavQPlus and flip them to the "flash" mode. See the table and picture below for reference.

4. Flash the eMMC memory

The NavQPlus firmware is preferably installed on eMMC memory for reliability reasons, even though it may be convenient during development to use the SD card. Especially if you are flying a drone, vibrations may cause (occassional) failure of the physical connections to an SD card.

Connect the NavQPlus to your computer using the leftmost USB-C port (USB 1). The two status LEDs should light up as shown above.

Open a command line window. Run the following command to check that the NavQPlus is recognized by UUU:

You should see that there is a device detected. To flash your board, use the command below (adapt the filename/version to match the image file that you downloaded in step 1):

Once this process has finished, make sure that the flash process was successful by comparing the program output to the image below.

5. Set the boot switches to eMMC mode

You should now (again) change the  to boot from eMMC (also see step 3).

6. Log in for the first time

Power on the NavQPlus by plugging in a USB-C cable to the centermost USB-C port (USB2). Make sure to provide enough power (a >5W supply is recommended). The NavQPlus will boot, and you will be able to confirm it has fully booted by observing the LEDs on board. The three LEDs by the USB1 port should all be on, as well as two LEDs next to the CAN bus connectors.

To log into NavQPlus for the first time, you can either use the included USB to UART adapter, ethernet, or USB gadget mode.

USB to UART adapter

Connect the included USB to UART adapter to the UART2 port on the NavQPlus, and open your favorite serial console application (e.g. PuTTy for Windows users, Minicom on Linux). Open a serial console and set the baud rate to 115200. If there is no output on the screen, try to press enter to get a log-in prompt.

If the boot was successful, in the terminal it will ask for the username and then the password. The default username/password is as follows:

At this point you can start playing around already with the NavQPlus. However, it is recommended to also follow the last steps.

Ethernet

To connect to the board over ethernet, connect the included ix Industrial ethernet cable to NavQPlus, and connect the RJ45 connector to your computer, switch, or router on your local network. You can log into NavQPlus over SSH. More information on this setup is explained in the . The default hostname for NavQPlus is imx8mpnavq or use the IP adress from your board instead. To SSH into NavQPlus, you can run the following command:

It will also ask the password after a successful connection to your board. As mentioned above the default password is user.

USB Gadget Ethernet

The IP address of the usb0 network interface on NavQPlus is statically assigned to 192.168.186.3. If you want to use USB gadget ethernet to connect to NavQPlus, you will need to assign a static IP to your existing gadget ethernet interface on your computer.

First go to your network settings and click on the plus icon on the top right.

The network configuration is as follows:

IP Address: 192.168.186.2

Network Mask: 255.255.255.0

Once you have set up your USB-C gadget ethernet interface on your computer, you can SSH by running:

7. Expand Image (if needed/desired)

The flashed images MAY need expanding to utilize all the available storage. After logging into the NavQPlus, open a terminal and run:

• Expand image on the eMMC memory (if you followed the instructions above):

• Expand image on the SD card (if you chose to flash the image on the SD card):

8. Change the default username and password

To change the default username and password, use the commands below.

Username (replace <new_username> with your desired username):

Password (you will be prompted to enter the current and new password):

What's Next?

Now with the NavQPlus setup complete, you can start to install other software packages and run your own code. For example, (Robot Operating System) is commonly used as a framework for controlling robotic systems, with plenty of compatible packages being available.

There are two ways to power the NavQPlus. You can power it through the PWR IN port or through the middle* USB-C port (*dependent on software image loaded)

This is because it is possible that the USB-C power management logic may be configured in software in a manner that limits current or resets the power management in the time between the bootloader running and the Linux image running . This leads to unexpected behavior at power up. If you suspect something unusual is occurring on power up or you see the board rebooting, please try powering through PWR_IN first.

The PWR IN port accepts an input in the 5V-20V* range. (Technically higher (24V?), but has not been fully validated or characterized)

The PWR IN port pinout schematic is as follows: (center pin is unused). Pin 1, 2 are the power input, Pin 4, 5 are negative (GND).

The input power voltage connection PWR_UNREG is 5V-20V

Unexpected Power Resets

If you encounter unexpected resets, it could be any of the following issues

Insufficient Current Available:

That your power supply is not able to provide enough current for the board or the board + peripherals resulting in a brownout condition when internal blocks, interfaces, peripherals turn on and draws additional current.

Supplying power with a LiPo battery may help debug if you have a bench or wall adapter power supply limitation.

Power Glitch from other boards:

The PWR IN port is connected to an onboard power control switch that can sense reverse current spikes on the power supply and de-assert a power good signal, causing a reset. This may happen when another device is sharing the power supply and "glitches" the power supply when plugged in live. A reverse blocking diode and additional bulk capacitors on a power distribution board or inline with the power cable may be desired.

Linux Image problems:

As mentioned above, when powering from USB-C, the specific Linux image should be checked to ensure that the Linux Kernel is not resetting the USB power when it starts up after the bootloader is completed. (i.e the bootloader configures USB-C, then the Linux Kernel may also be set to re-configure/reset the USB-C also and in the process switching it off again.

The NavQPlus may be considered a generic embedded Linux Computer. When running Ubuntu POC, most linux packages may be installed using apt or apt-get. As with any Linux machine not all packages are suited to the specific hardware.

There is also specific emablement related to the i.MX 8M Plus SOC chip that is used. Please refer to NXP.com for more details. This includes things like hardware acclerated video using gstreamer and hardware accelerated neural net processing using eIQ on the NPU module. Note that the MR-B3RB documentation will demonstrate the usage of NavQPlus as a Robotic platform running ROS and is considered one of our reference development tools. Following the software guides there may be preferable, and provide more detail.

NavQPlus models typically ship with one Omnivision camera module which is either from Innowave or Google Coral Camera. 3rd parties may also have other cameras. An additional camera can also be added to the second MIPI port. Note that other USB or Ethernet cameras can also supply image data to the NavQPlus. Please refer to NXP.com documentation for i.MX 8M Plus for details on camera usage in LInux.

Video example using gstreamer

To take an image using an attached MIPI camera module on NavQPlus, use the gstreamer command. An example command is as follows:

sudo gst-launch-1.0 -v v4l2src device=/dev/video3 num-buffers=1 ! jpegenc ! filesink location=capture1.jpeg

Boot Switches Configuration

NavQPlus can be configured to boot from either SD card or eMMC. It also has a flash mode that allows you to flash either the eMMC or SD card over USB-C®. See the table below for the boot switch configuration.

The NavQPlus has the ability to connect via ethernet in several different ways.

• Through the IX Industrial® Type A port. The provided IX to RJ45 adapter cable will allow connecting to RJ45 *Preferred

• Using the USB-C port with "gadget bode" Ethernet over USB

• Through the 100 Base T1 automotive ethernet. A media converter such as RDDRONE-T1ADAPT, or a switch such as MR-T1ETH8 would allow connection to a typical RJ45 100Base-T port.

• Using a USB-C Ethernet adapter dongle

USB to Ethernet Adapter

Here is an example of how the NavQ+ can also be connected through the USB-C port. For this method, a separate adaptor is required to convert the USB-C to RJ45.

To be able to connect to the board through SSH it must be connected to the same network. This is possible by using a router and connecting your network cable to it then the NavQ+ and your PC to it. With this connection SSH can be established between your PC and the NavQ+. Below is an example of how the router could be connected.

After everything is connected correctly a connection can be made through SSH. This is done with the following code, on your PC terminal:

or you can input the IP address of your NavQ+:

You will be asked to input the password.

The default password is user.

At this point you may want to consider following steps to connect the NavQPlus WiFi to a local network.

Introduction

When new images are released, we will provide a link to them. To flash NavQPlus, normally there are two options. You can either flash the eMMC chip on-board, or flash the SD card included with the kit. The eMMC runs faster but is not removable like the SD card. The SD card is easily removeable and can be programmed quickly and directly from a PC. It is up to you to choose which one to use.

NXP Images

The official source for linux on NavQPlus *will eventually be NXP Linux Factory, however at the time of this writing it is a work in progress.

See below for instructions on how to flash the SD card or eMMC.

Third party images

The following images are prepared by 3rd parties and support the NavQPlus.

• For use with iRobot Create3 (AKA Turtlebot4)

• For use with NXP MR-B3RB

Emcraft Release Images

Voxelbotics Release Images:

Rudis Labs Images:

Flashing image to an SDCard

The NavQPlus typically comes with a 16GB SD card or larger that you can flash with the pre-built Ubuntu 22.04 image. See below for instructions to flash your SD card on each platform.

Flashing SD card using Windows PC

Several free programs are available to flash an SD card with an image, we use .

Once you have downloaded Win32DiskImager, insert your SD card into your computer, open the program, and select the navqplus-image-{vX.X}.wic file as your image.

Next, select your SD card under Device.

Once the flashing process has finished, you should get a message saying that the write was successful.

Flashing SD card using Linux / Mac

To flash your SD card with the image you downloaded in step 1, we suggest using dd.

To do this, open a terminal and navigate to the folder that you downloaded the

navqplus-image-{vX.X}.wic file.

Once you are there, insert your SD card, and find the device path for it. Typically, it will be something like /dev/sdX on Linux or /dev/diskX on Mac.

Once you have found your device path, run the following command in your terminal to flash the SD card:

Linux:

Mac:

Once this is done, your SD card will be flashed with the image.

Set Boot Switches for SD Card Boot

• Remember to check that your are set to boot from SD.

Flashing the eMMC

(Flashing eMMC using uuu utility)

To flash the eMMC on your NavQPlus, you will need to download , a tool created by NXP to flash NXP boards. Make sure to download the correct application for your platform. The file titled "uuu" with no file extension is a binary file for use on x86/64 Linux.

• After downloading uuu, find the on your NavQ+ and flip them to the "Flash" mode.

• Connect NavQ+ to your computer using the centermost USB-C port.

• Run the following command to make sure that the NavQ+ is recognized by uuu:

<TODO: Add image of output>

• You should see that there is a device detected. If so, you can continue flashing. To flash your board, use one of the commands below depending on how the image was supplied:

EMMC image supplied in .zip format then:

EMMC image supplied as .bin and .wic files:

• Once this process has finished, make sure that the flash was successful by comparing to the image below. If so, configure your to boot from eMMC.

TODO: Add image

Configuring WiFi on NavQPlus

An alternative tool to connect NavQPlus to your local Wi-Fi network is the nmtui command. This command presents a GUI in your terminal to connect to Wi-Fi. The interface is relatively straightforward. To run nmtui, run the following command:

sudo nmtui

The preferred method as mentioned earlier is to use the non-GUI way to connect to Wi-Fi or manage your network connections, use nmcli by running the following command:

Once you are finished connecting to your local WiFi network, you can exit the application. Your NavQPlus will continue to connect to this WiFi network even after a reboot.

Configuring WiFi, System Hostname, Username or Password

Configuring WiFi on NavQPlus

To connect NavQPlus to a WiFi network, use the nmcli command. The interface is relatively straightforward, to connect with nmcli, run the following command:

If struggling to connect to a network, see if it is visible by running:

Once connected to the WiFi network the NavQPlus will continue to connect to that network even after a reboot.

About nmcli

The netowork connections will be saved and NavQPlus will automotically connect to these networks when they are present. Note that the priority of connections can be set as well as removing connections. For more information see the nmcli linux command.

What wifi network is the NavQPlus currently connected to?

To see what Wifi network the NavQPlus is currently connected to run without sudo:

nmcli device wifi list

Or if running with sudo it will be the network preceeded with a star.

Connecting to NavQPlus over WiFi

Once setup to connect over a local WiFi network, SSH into the NavQPlus over WiFi by running:

Or depending on network setup:

Examples

Please refer to the MR-B3RB documentation as it is most up to date on configuring a working simulation. Setup and scripts provided there will configure the envoronments for simulation

Gazebo Ignition

Vehicles using NavQPlus running ROS and other software can be modelled and simulated in Gazebo Ignition. There are several NXP models listed for the Ignition Fuel library here:

These models can be referenced "live" from within Gazebo-Ignition, or downloaded in advance.

DoBots Asimovo

Asimovo is a cloud based simulation environment that can offload the resource requirements for your local computer, as well as offering guided team collaboration and learning. They have experience using NavQPlus and our simulation models.

Accessing the cameras using OpenCV in Python

Below are short examples of using openCV. Refer to NXP.com or other guides for more detail.

Getting started

To install OpenCV for Python to the image, run the following command:

Getting images from the camera using gstreamer pipelines

To access the Google Coral Camera(s) on NavQ+ in OpenCV, you may use the following VideoCapture instantiation:

You may change the source resolution by editing the width and height values in the GStreamer pipeline. See below for a list of supported resolutions and framerates.

Introduction

This is an example of how to use a Webserver running locally on the NavQPlus. Note that this is one of several methods available. In this example the idea is to control the robot (or anything), using low level commands written with shell scripts commanded from an HTML page. By not using a higher level language such as Python it helps make the robot responsive and quick to act.

A WebServer is used to control the NavQPlus using low level commands written with shell scripts commanded straight from a HTML page. This page will explain how to set-up a WebServer and control your NAVQ+.

The webserver we will use is called Lighttpd, for more information on the Lighttpd read the following link:

First step is to install Lighttpd WebServer and components. Use the following code in your NAVQ+ serial console application:

This is the output you should receive after running all three codes above:

Lighttpd is looking for an index.html page at /var/www/html. We will change it, so the index.html will be placed under /var/www. For that, we must edit the Lighttpd config file using nano (if you do not have nano see ):

In this file you should change:

To:

It should look something like this:

Then exit the file and save. For the changes we made just now to take effect, we must reboot the web server. To do that enter both commands in order:

At this point the web server is running and if a page index.html is located at /var/www, we can access it from any browser, typing the NAVQ+ address you can see the default web page by lighttpd. Get the NavQ+ IP address and input it into your browser search bar.

Now let's try and place an example template webpage and access it.

Stop the server for the next few steps.

Clone the following repository to somewhere where you will remember in your home file.

After cloning the repository, you will copy some of the files to /var/www. This can be done with these commands:

Now access the page again using the IP address of your NavQPlus, you should get this:

You have managed to make a simple webserver. This webpage can be quite useful to use as a GUI for robot controls as displayed in the example page above.

This chapter will describe some of the hardware features present on the NavQ+.

This hardware interfaces section of the NavQPlus document is intended as a high level look at the connectors present on the board and their intended usage. Here we may also go into more detail where the interface is unique to the NavQPlus carrier board design and where it may differ from the i.MX 8M Plus EVKs. For complete in depth details regarding the IP block providing the specified interface please refer to NXP.com and the datasheet and reference manual for the i.MX 8m Plus system on a chip.

NXP Buggy3 RevB uses NavQPlus and the MR-CANHUBK344 together to form an Ackermann steering robotic development platform. Pre configured ROS2 and Zephyr Software to run this platform is provided. For best initial experience follow the MR-B3RB guide.

Use the MR-B3RB gitbook as a technical reference for NavQPlus when you are expanding upon the MR-B3RB or need to interface new peripherals.

Using IX Industrial Ethernet

IX industrial ethernet defines a new rugged and small connector type for traditional 100BaseTX and 1000BaseTX interfaces. These traditionally would use RJ45 with plastic clips whereas IX industrial is primarily metal shell and clip design. The signals used are exactly the same and only the connector changes to the IX connector. Both IX-to-IX cables as well as IX-to-RJ45 cables are available off the shelf.. Plugging an IX-to-RJ45 cable into the NavQPlus will allow you to connect via ethernet to a laptop. An IX-to-IX would allow connection to the NXP ethernet switch board or similar industrial equipment. Note that the was was also made for mobile robotics with the intention of demonstrating the NavQPlus being able to connect to a multitude of T1 devices such as and cameras. The IX Ethernet interface on NavQPlus is capable of gigabit 1000BaseTX speeds.

Use 100BaseT1 instead of IX Ethernet port

There are two boards from the mobile robotics team that can also convert from T1 Ethernet back to a 100BaseTX:

• , there is also a

Pipeline examples

Take an image

Record a video

Streaming examples:

• On PC: RX Pipeline to receive the stream from the NavQPlus AI/ML companion computer:

gst-launch-1.0 udpsrc port=50000 ! "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! decodebin ! queue ! autovideosink

• On NavQPlus (e.g. from SSH connection):

gst-launch-1.0 v4l2src io-mode=dmabuf device=/dev/video3 ! "video/x-raw,width=1920,height=1080,framerate=(fraction)30/1" ! vpuenc_h264 ! h264parse ! rtph264pay ! udpsink host=10.0.1.101 port=50000

• Video Test Source instead of camera: gst-launch-1.0 videotestsrc ! "video/x-raw,width=640,height=480,framerate=(fraction)10/1" ! vpuenc_h264 ! h264parse ! rtph264pay ! udpsink host=10.0.1.101 port=50000

• Camera Tuning: 1) Get the video subdevice using:

media-ctl -p /dev/media0

remember the sub-device of the camera ( ov5645tn) in the media video chain, e.g. /dev/v4l-subdev2

2) List the available user and camera controls and try them out (e.g. contrast, saturation, auto white balancing etc.):

v4l2-ctl -l -d /dev/v4l-subdev2

• Streaming and Storing to a h264 compressed file simultaneously including text overlays for 30 seconds:

gst-launch-1.0 v4l2src io-mode=dmabuf device=/dev/video3 num-buffers=900 ! "video/x-raw,width=1920,height=1080,framerate=(fraction)30/1" ! tee name=t ! queue leaky=1 ! textoverlay text="Live" ! vpuenc_h264 ! h264parse ! rtph264pay ! udpsink host=10.0.1.101 port=50000 sync=false t. ! queue ! textoverlay text="recorded" ! vpuenc_h264 ! mpegtsmux ! filesink location=record_$(date +"%Y-%m-%d_%T").mp4

Note: The VPU is encoding two streams in parallel as we have different text overlays on the live stream and the recorded file

Note on hostapd

To avoid needing to set up a Wi-Fi router hostapd can be installed so that the NavQPlus acts as an access point. Additionally a DHCP server can be configured. This way you can directly connect to the WiFi network spawned by the NavQPlus:

Shown highlighted below, the IP address 10.0.1.101 is coming from the DHCP server on the NavQPlus.

NavQPlus works with the ROS2 Turtlebot4 reference platform which is the iRobot Create3 platform. This includes Lidar interfacing.

Details on this setup can be found here: https://iroboteducation.github.io/create3_docs/hw/navqplus_hookup/

Bringing up the CAN buses on NavQPlus

CAN 2.0

CAN-FD

There is an LED next to each CAN bus PHY on the board that will light up after running one of these commands.

These interfaces support the Linux SocketCAN library. Here is a good link showing some simple SocketCAN example code:

CAN Bus Locator

There are four CAN-FD connectors, they are connected "pass-through" style so that the bus may continue on, or a termination resistor network be plugged in.

• J21 and J22 are connected to CAN1 hardware signals / CAN0 logically in Software

• J19 and J20 are connected to CAN2 hardware signals / CAN1 logically in software

CAN Bus Schematic

CAN BUS LEDs

These LEDS are connected to the enable signal going to the CAN PHY

CAN BUS SIC PHYs

NavQPlus uses TJA1463 CAN SIC PHYs. These are compatible and drop-in replacement for traditional CAN-FD PHYs.

The TJA1463 CAN signal improvement capability (SIC) transceiver with sleep mode is part of the TJA146x transceiver family that implements CAN SIC as defined in CiA 601-4. By meeting the CAN physical layer as defined in ISO11898-2:2016 and SAE J2284-(1-5), the TJA1463 is fully interoperable with high-speed classical CAN and CAN FD.

CAN signal improvement significantly reduces signal ringing on a network, allowing reliable CAN FD communication to function at 5 Mbit/s in larger topologies. In addition, the TJA1462 features a much tighter bit timing symmetry performance to enable CAN FD communication up to 8 Mbit/s.

The TJA1463 is backwards compatible and a drop-in replacement for classical CAN and CAN FD transceivers, such as NXPs TJA1043 and TJA1443

Potential improvements

Because of their improved reliability handling of bus signals, it may be possible to implement:

• Higher bus speeds (Note however that 512kBaud negotiation speed remains the DroneCode standard and is also most common in automotive applications)

• Unterminated/poorly terminated stubs

• Central termination of the CAN bus

CAN Termination

The preferred split termination method from Automotive applications is applied on board the NavQPlus. These parts may need to be removed if you wish to terminate your CAN bus at a different node. Note that as mentioned above, it may be reasonable to use the NavQPlus as a central termination point in a CAN-SIC network.

Additional CAN boards

Shown below is an example of the NavQPlus attached to a "CAN Node" board. A small termination network board is included with the UCANS32K1SIC. The CAN Node board can used for generic CAN-SIC (CAN-FD) node development for sensors and actuators. Essentially it is an S32K1 automotive MCU with the UART/SPI/I2C/PWM pinned out for general purpose use.

This image uses Netplan to configure the network manager which is "Networkmanager".

Setting the IP address using ifconfig will NOT be applied persistently, and can/will be overridden periodically by Networkmanager This manages network conflicts for controlling IP networks like Ethernet and WiFi. Network Manger has several command line utilities

• nmcli to get current network status

• nmui is a termnial user interface to modify connections

  • set static IP/ DHCP

  • set DNS

  • connect to a wifi network

Examples are provided in the and sections.

You can follow this tutorial below in order to set Static IP with NavQ+ :

You may wish or need to modify your NavQPlus to accept additional camera types. This is not difficult, but does require care.

The Production "RevB version" of the NavQPlus makes a small adjustment to the MIPI CSI Clock line in order to be more compatible with a variety of image sensors. This is also the configuration used with the OV5645 fixed focus image sensors from Innowave that ship with the RevB board As shown in the image below, the resistors R21 and R37 shoudl be 0 Ohm (or solder jumpers) and the resistors R22 and R38 should be removed. (DNP/DNI).

Accessing the external I2C bus

The i.mx 8M Plus has a number of I2C busses on board. Internally they are connected to a variety of onboard peripherals. Normally you will not need to address these peripherals directly, and they will be handled by Linux drivers.

• I2C1 - SOM only for PMIC control

Connecting the Innowave OV5645 Camera

<todo> add more detail

The innowave camera comes pre-installed with the latest revision (2024) of the NavQPlus. It is a fixed focus camera unlike the autofocus google coral camera. The installation and removal is very similar to the the instructions below for the Google coral camera.

The flex cable has marking on it "this side up" that should be visible when looking at the connector side of the board. i.e you can read "this side up" and also read the silkscreen "CSI 1"on the bottom of the board at the same time.

Additional T1 Ethernet boards

The following boards also from the NXP Mobile Robotics team may be helpful when working with 100BaseT1 2-wire Automotive Ethernet. They are an adapter and a network switch. In addition to these baords, you may find other NXP EVKs and 3rd party boards that can also be used. In some cases you may need to adapt the two wire, two pin connector to match your own requrements.

Introduction

UART1 is assigned to communicate with the Bluetooth portion of the WiFi/BT Wireless module on the NavQPlus Baseboard. Therefore it is not available for general use (outside of creating your own modified custom baseboard).

Introduction

UART3 is available for general use. Hardware flow control is supported.

Note from the schematic clip below, that the MPU can multiplex these signals with SPI1. This is normally configured in the Linux image and is not the default configuration.

Port configuration

NavQPlus includes two USB 3.0 Type C ports that are capable of acting as PD devices.

PD modes, Controller, Peripheral mode, USB Gadget Mode are configured at compile time, and may change depending on what image you are using.

The default image as of the date shown here configures the USB ports as follows. (Last updated 10/13/2023 )

USB 1:

USB-C port closest to the edge of the board.

This port is used for connecting devices, such as USB-C hubs, cameras, sensors, and more.

USB 2:

USB-C port closest to the middle of the board.

This port is used for powering the board, as seen in the Power page in the User Guide. This port accepts USB-C PD, and also allows data transfer.

USB Gadget Ethernet is supported over this port with the interface usb0.

PCIe signals are on a flex cable connection located on the back of NavQPlus. A PCIe adapter has been prepared by a 3rd party to work with NavQPlus. It is not in production as of yet. Please contact hovergames@nxp.com for more details.

Introduction

UART4 is available for general use. Hardware flow control is supported.

Note from the schematic clip below, that the MPU can multiplex these signals with SPI2. This is normally configured in the Linux image, and is not the default configuration.

UART4 Locator

UART4 interface voltage

The signaling from the SOM to the NavQPlus carrier board on J11 is at 3V3

Alternative output is on the AUX connector at location J12 also at 3V3 signalling. However this is not the default linux BSP, and would require changes to the dtb files.

Schematic

J11/UART4 is the default location for UART4 signals. Also by default UART4 is assigned to the M7 Core on the i.MX8M Plus. An RTOS such as FreeRTOS or Zephyr would normally use it as the default console to the embedded MCU.

UART NetNames

Note signal names are differed on J11 vs J12. This is only a labelling detail, since the pinmuxing on the chip is used to "move" the UART4 interface from one set of pins on the MPU (and board to board header). In order to route these signals independently on the carrier board, they need their own net names.

UART ESD

All the UART signals are protected from ESD using the Nexperia IP4292CZ components. This is part of an optimized BOM as they are also required for the USB interfaces. In additional to its exceptional performance the board layout may be optimized because of being able to route traces straight under the component.

Software

UART3 may be accessed as a standard /dev/ttyS_ in Linux. <TODO-check wich ttyS number it is>

There are several ports which may have or may be configured for GPIO connection. In addition there are several SMT pads designed to allow access to GPIO and signals such as the PMIC controls. Refer to the schematics for details.

<<TODO - add more detail here, and pictures of the schematics. Add an example pin access if available>>

UART4 interface voltage

The signaling from the SOM to the NavQPlus carrier board on J11 is at 3V3

Alternative output is on the AUX connector at location J12 also at 3V3 signalling. However this is not the default linux BSP, and would require changes to the dtb files.

Schematic

Note that J11/UART4 is the default location for UART4 signals. Also by default UART4 is assigned to the M7 Core on the i.MX8M Plus. An RTOS such as FreeRTOS or Zephyr would normally use it as the default console to the embedded MCU. You may note that the signal names are differed on J11 vs J12. This is only a labelling detail, since the pinmuxing on the chip is used to "move" the UART4 interface from one set of pins on the MPU (and board to board header). In order to route these signals independently on the carrier board, they need their own net names.

All the UART signals are protected from ESD using the Nexperia IP4292CZ components. This is part of an optimized BOM as they are also required for the USB interfaces. In additional to its exceptional performance the board layout may be optimized because of being able to route traces straight under the component.

Introduction

UART2 by default is the Debug or Console port into the main A53 processors running Linux on NavQPlus. It is possible to reassign its use by modifying the Linux configuration and .dtb files.

UART2 Locator

UART2 interface and voltage

The signaling from the SOM to the NavQPlus carrier board on J10 is at 3V3. Full handshaking with CTS RTS lines is provided:

Console connection

Normal configuration and usage of UART2 is a console for bootup and Linux. The benefit of using the debug/console is that you can observe all details from powerup.

Details of the console connection including the Baud rate are provided under "Serial Console" in the Quickstart section of this gitbook. See the link below:

Introduction

100BaseT1 2-Wire Automotive Ethernet provides 100MBPS connections over simple twisted 2 wires for a distance of up to 15 meters. The line signaling on the wire is not directly compatible with traditional 100BaseTX (RJ45) connections, but a physical adapter may be used. Otherwise it is the same as traditional Ethernet.

T1 is lightweight and reduces the cabling weight. The interface also does not require the use of magnetics, so it also saves weight and cost in that regard. Typically you will find T1 Ethernet used on Radar, Cameras, MR-CANHUBK3 and NXP flight controllers for drones.

A MIPI DSI interface using a ribbon cable connector is available on the backside of NavQPlus. Refer to the schematics for details.

A Micro-HDMI interface is provided on the NavQPlus. This may be used to drive typical monitors or small LCD displays. Note only typical display timing and resolution is enabled/supported by default. A standard micro-HDMI cable may be used to connect to a typical monitor, or HDMI embedded displays.

The NXP PCF2131 Nano-Power Highly Accurate RTC with Integrated Quartz Crystal is included on board. The PCF2131 is a CMOS real time clock (RTC) and calendar with an integrated temperature compensated crystal (Xtal) oscillator (TCXO) and a 32.768 kHz quartz crystal optimized for very high accuracy and ultra-low power consumption. This IC has four timestamping hardware inputs. These can log events such as tampering or an enclosure being opened even when no power is applied to the rest of the board. See the Datasheet for this part for more information.

Note this RTC is in addition to the internal RTC for the i.MX 8M Plus.

Note that at time of publishing, there are several Linux drivers available from various public sources, but the one integrated with the NavQPlus BSP does not support this function yet.

DRAFT DRAFT DRAFT

Rest and PMIC Control "GPIO"

A series of test points are available to access the Reset and PMIC controls one the NavQPlus board. These could be used where a remote button or other external controls are desired.

Misc GPIO Locator

<TODO> - complete mapping from Schematic to board layout (image here)

There are multiple UARTS on NavQPlus.

Because of pinmuxing these can sometimes be assigned to different uses and locations depending on the specifics of the Linux BSP and DTB files. The default configuration for NavQPlus LInux image provided at time of publication will be described here. Please double check any notes on your specific Linux Image if something varies from this configuration.

Introduction

The AUX port contain is by default configured for I2C6 + GPIO. Alternative pinmuxing is available on AUX for UART4. Any alternative configurations are not default and need to be configured in the Linux Image and .dtb files

AUX interface voltage

The signaling from the SOM to the NavQPlus carrier board on J12 is at 3V3

Any alternative pinmuxed output configurations on the AUX connector would also be 3V3 signaling.

Aux Locator

Schematic

UART

Note that J11/UART4 is the default location for UART4 signals. Also by default UART4 is assigned to the M7 Core on the i.MX8M Plus. An RTOS such as FreeRTOS or Zephyr would normally use it as the default console to the embedded MCU.

GPIO

J12 "AUX" is includes two pins for GPIO labelled GPT1_CAPTURE1 and GPT2_CAPTURE2

ESD Protection

All the UART signals are protected from ESD using the Nexperia IP4292CZ components. This is part of an optimized BOM as they are also required for the USB interfaces. In additional to its exceptional performance the board layout may be optimized because of being able to route traces straight under the component.

Software

<TODO- describe how to access these GPT pins in software>

A LVDS LCD display interface using 1-2 ribbon cable connectors is available on the backside of NavQPlus. Refer to the schematics for details. This is an advanced configuration to drive LCD glass directly.

This section contains assorted notes, tips, tricks and links that may be helpful when working with the NavQPlus.

Keep in mind the date and context when they were given, as it is quite possible the detail may not be relevant by the time you view it.

This group of pages intended to be more of a miscellaneous notes section.

Introduction

An RC remote control can be made to connect directly to the NavQPlus in order to transmit joystick and switch settings information. This can be then used in other software (ROS2) as input to control aspects of a vehicle directly or indirectly, such as reading an RC channel as an "arming switch". Note that this method uses a USB-UART adapter to facilitate the connection, but technically it is possible to create a direct serial connection.

Requirements:

• FlySky FS-i6S RC transmitter

• FS-i6B receiver

• NavQPlus baseboard with Ubuntu image release 22.04.3 or above

Wiring

Connect the FS-i6B receiver to NavQPlus using TTL-UART cable (you need to prepare this cable yourself).

Connect the cable to a general use UART connector (the board is equipped with 4 connectors, three of them are available for general use. (Note UART1 is assigned internally to communicate with the Bluetooth portion of the WiFi/BT Wireless module on the NavQPlus Baseboard). Check this for more details.

Connect the three TTL wires Black/Red/White to the FS-i6B receiver as depicted in the picture below:

After plugging the receiver to NavQPlus board, you should see a red LED blinking in the receiver. If your transmitter is already on, it should bind automatically to the receiver otherwise you can bind it manually under its system menu. After binding, the red LED should be constantly glowing.

Software setup

Under NavQPlus linux console, run the following command in the background in order to create a new joystick input device:

Now your receiver is attached, you can use it for your need (ROS, software simulation, ...)

In order to check it is detected properly, run jstest-gtk software.

The new controller should show up as "FS-iA6B iBus RC receiver". The bar graphs should change accordingly when you move the control sticks.

HowTo: Remove unattended upgrades

HowTo: Install nano

GNU nano is an easy to use command line text editor for Unix and Linux operating systems. It includes all the basic functionality you’d expect from a regular text editor, like syntax highlighting, multiple buffers, search and replace with regular expression support, spellchecking, UTF-8 encoding, and more.

Note: There are other text editors that can be used, Nano is a popular one. Some of the HowTo below will use Nano as the editor.

To install:

HowTo: Edit hostname

Run the following command to change your hostname. Assuming you want to use the hostname "compcom42".

Change the hostname in hosts file

HowTo: Set static ip configuration

Network manager is used for network config. See steps below

Determine the interface to be used

From <>

Set static ip

Wired connection 2 = 1000base-TX / eth1 Wired connection 1 = 100base-T1 / eth0

From <>

HowTo: Install ROS

ROS is already installed on the 

See

HowTo: Install VPN

See

We welcome user submitted 3d printer files for use with NavQPlus and NXPHoverGames, NXPRoverGames, NXP-CUP or other. Note you may also find 3D printer files in other NXP Gitbooks, and by searching Thingiverse or other 3d printer file repositories with some of the name above.

In addtion on the following pages there are also direct links to Fusion360 files used with NavQPlus, HoverGames drone, and MR-Buggy3

Here are some tips an tricks related to the desktop/laptop linux host computer that you may use to connect to your NavQPlus.

Ubuntu HOST laptop cannot screens share in MS Teams

Reported June 2023 - IAFG We often communicate, and have debug sessions using Microsoft Teams, (or Zoom). During a session on Teams it is helpful to share the screen of the Ubuntu Host.

Current Ubuntu distributions (22.04) may only enable Wayland graphics by default. However X is required in order for screensharing to work with TEAMs and ZOOM (possibly others).

Depending on your LInux distribution you may be able to switch to X simply by logging out. Use the small gear icon in the lower right of the screen to then select Ubuntu using X.

Follow this guide to enabling X on Ubuntu Linux to allow screen sharing:

Below is a copy of the instructions given in the link:

To disable Wayland and use xorg only:

1. Open your terminal and write sudoedit /etc/gdm3/custom.conf

2. Uncomment the value waylandEnabled=false -- just remove the #

Misc YouTube links that may be relevant to NavQPlus.

<TODO> Check links

MAYBE LINKS:

Simulating Robots with Gazebo and ROS | Getting Ready to Build Robots with ROS

Inference examples

The i.MX 8M Plus SOC in the NavQPlus contains a Neural Processing Unit (NPU) that can accelerate inference on the edge. There are some inference examples built into the NavQPlus image that will do image classification with the COCO dataset.

There is a TensorFlow Lite example in the /usr/bin/tensorflow-lite-2.6.0/examples/ folder. This example runs a mobilenet_v1 quantized image classification model. To run it, try the command below:

USE_GPU_INFERENCE=0 specifies that we want to run inference on the NPU. Removing this environment variable will run inference on the GPU.

To run inference on the GPU/NPU, you will need to use the libVX delegate, at the path /lib/libvx_delegate.so.

There is also a python script named label_image.py that contains example code for inference with TFLite.

These are user submitted 3d printer files for use with NavQPlus and NXPHoverGames, NXPRoverGames, NXP-CUP or other. Note you may also find 3D printer files in other NXP Gitbooks, and by searhing Thingiverse or other 3d printer file repositories with some of the name above.

NavQPlus Mounting plate on HoverGames Drone

R.Scott.C — 12/24/2022 10:59 PM

I designed and 3D printed a mounting plate for the NavQPlus for the quadcopter.

.

Disable onboard Ethernet

Q: I have connected to WiFi . Is there a way to stop the occasional messages regarding eth1: ? The messages are pictured above in my 2:49PM post, The messages show up every 300 seconds A: Ed S 12/28/2022 - One option is to unbind the driver:

echo -n "30bf0000.ethernet" > /sys/bus/platform/drivers/imx-dwmac/unbind

Note: The redirected file may be opened by the shell before the "sudo echo" command is executed, therefore If the shell is not already root (via "sudo -i") a different form is needed:

sudo sh -c "echo -n 30bf0000.ethernet > /sys/bus/platform/drivers/imx-dwmac/unbind"

There are both tall and short versions for the Google Coral camera mount used in HoverGames and MR-Buggy3. These links or clicking "Open in Fusion360" should take you to Fusion360 webpage where you can download the source files, STEP or STL for 3D printing as well as a variety of other formats:

Google Coral mount - Tall version

As used with MR-Buggy3 https://a360.co/3XfDLYm

Google Coral mount - Short version

As used and shipped with HoverGames Drone.

Camera mount on servo

This is a user contributed camera mount that can attach to a servo so the angle of the camera can be changed from pointing forward to pointing downward.

NXP provides eIQ tools for working with the NPU (Neural Processing Unit) that is integral to the i.MX 8M Plus processor

Please refer to the MR-B3RB gitbook document for instructions on configuring and using this platform.

Introduction

Setting up the MicroDDS Agent/MicroROS

One method used to communicate between the NavQPlus and the FMUK66v3 using T1 or Serial is by using MicroROS or the XRCE-dds Agent. To install these tools:

If using yocto, you can use the WIP meta package in your recipe.

Alternatively, you can install micro-ROS through the ubuntu snap store

Another way to get micro-ROS is through Github as a ROS2 package. You can use the colcon build tools after sourcing the ROS setup.bash script in "/opt/ros/galactic/setup.bash"

Follow the instructions for each package on how to run the agent. The agent is a broker for clients on the network (including the FMUK66) and allows topics from the pixhawk to be shared with the DDS global space.

To set up the NavQ+, follow instructions in the Setup Guide -eMMC for a static IP. The FMUK66 is IP "10.0.0.1". As an example, you can set the NavQ+ to "10.0.0.3" with a blank ipv4.gateway (no quotes or anything) on Wired Connection 1.

Then start the microdds agent that is installed in the home directory in the Micro-XRCE-DDS-Agent build folder.

On the FMUK66, ensure you have flashed to main and enter the following command.

You should see the topic listed in the mavlink console after running the client start, as well as topic, publishers, data writers, and creators on the agent side.

Description

The NavQPlus_MR-Buggy3 demo is a demonstration of the capabilities of the NavQPlus, the MR-Buggy3 platform, and NXP's CAN Bus hardware and software support for ROS2.

This guide will walk you through setting up the MR-Buggy3 demo on both your laptop and the NavQPlus. This demo consists of:

1. A Gazebo Ignition simulation environment with the MR-Buggy3 model running

2. Connection to the actual Buggy3 hardware meaning HITL (hardware in the loop) control of the real life MR-Buggy3

3. A showcase of the NPU (neural accelerator) on the NavQPlus running inference on the real world camera data as well as a virtual camera from the simulation environment

Setting up the laptop

To run this demo, you must have an Ubuntu 20.04 or 22.04 machine. It is recommended that you use a machine that has a dedicated GPU and that is running Ubuntu natively.

First step: Running the NXP install script

This install script first checks itself against the repo to ensure it is the latest version, then installs the packages needed for a baseline setting for the NXP mobile robotics team development environment on either a laptop, VM, or the NavQPlus targets. Download the nxp_install.sh script using a webbrowser to your local Linux machine.(Currently this) is located at

Run

chmod a+x install.sh

on this script and run it on your machine.

This will install ROS2 and all required dependencies.

Second step: Creating a ROS2 workspace and building sim_ignition_bringup

It is recommended that you create a ROS2 workspace at ~/git/ros2/, but you are free to create it wherever you want. In this guide, we will use that location. Follow the steps below.

Setting up the NavQ+

First step: Running the NXP install script

Follow the steps used above for your laptop to set up ROS2 on your NavQ+.

Second step:

You'll want to also create a ROS2 workspace on your NavQPlus. This step is similar to the step for setting up the laptop, but instead of cloning sim_ignition_bringup, you'll want to clone ros2_orchestrator. Follow the steps below.

Running the simulation

Once you have connected everything according to the block diagram shown below, you will be ready to run the demo.

Prerequisites

To run the demo, open 4 terminal windows. Start with the battery plugged in and powering everything over the PDB, and make sure that the ESC is turned OFF.

Terminal 1

SSH into the NavQ+, then navigate to ~/git/ros2/src/canfd_msgs/scripts/. Inside this folder, run ./launch_example.sh. You should see the UCAN board turn on, start sending heartbeat messages, and then stop. NOTE: You should also see a 64 byte CAN frame get sent. This is the initialization for the PCA9685 PWM Driver. Once this message is sent, you are free to turn on your ESC.

Terminal 2

Run ros2 launch sim_ignition_bringup sim_ignition_bringup.launch.py and wait for the simulation to fully start.

Terminal 3

SSH into the NavQ+, then run ros2 launch ros2_orchestrator orchestrate.launch.py

Terminal 4

This terminal is for checking ros2 topics, launching additional rqt_image_views, and other commands as needed.

You should now have a working demo! The simulated car should be driving around the track. In each of the rqt_image_view windows that open, you can view the various camera streams that are running. Camera streams that are labeled "Debug" show the NPU inference running.

Connecting to a WiFi network

We suggest using the nmtui command to connect to WiFi networks.

This command will show a terminal user interface for connecting to WiFi networks. It is recommended to connect to the NavQPlus over Ethernet before attempting to connect to WiFi.

Bugs and workarounds

<<<TODO review below for correctness based on latest Linux image 11/15/2022>>>

Ping spikes

Bug:

Currently when connected to a WiFi network and not connected to an Ethernet network, the NavQPlus will experience ping spikes in the range of up to 500ms. This is due to the WiFi chip attempting a periodic WiFi scan.

Workaround:

Currently there is no workaround for this issue. We are actively looking for a solution.

DNS bug

Bug:

You will notice that the NavQPlus is not able to connect to the internet after connecting to a WiFi network and rebooting. This is because NetworkManager will attempt to set a new DNS nameserver every boot.

Workaround:

To fix this, please follow the instructions below.

1. Delete /etc/resolv.conf

1. Create a new /etc/resolv.conf with the following contents:

1. Create a new file at /etc/NetworkManager/conf.d/90-dns-none.conf

Once you have completed these steps, reboot and you should have access to the internet over your WiFi connection.

Introduction

This page will go through a simple example using ROS on the NavQPlus. More examples and details can be found on the ROS webpage linked bellow. This example is a shortened version of the Publisher Subscriber for Python tutorial. You will need to have ROS2 installed already before trying this example.

ROS2 Publisher Subscriber in Python example

In this tutorial, you will create that pass information in the form of string messages to each other over a . The example used here is a simple “talker” and “listener” system; one node publishes data and the other subscribes to the topic so it can receive that data.

Step 1 - Create workspace

First step is to make a for your project to build in. Go to your home folder and create a workspace called /ros2_ws. With another directory inside /src for your project to be in.

Then move into the /src directory:

Step 2 - Create package

Now we want to create a package inside the directory we just created.

Your terminal will return a message verifying the creation of your package py_pubsub and all its necessary files and folders.

Step 3 - Publisher code

Navigate to the new directory location created.

Now download the example publisher code:

You should now see a new file located in the py_pubsub directory. To understand more about the code, follow the tutorial through the .

Step 4 - Subscriber code

For the subscriber code stay in the same directory and download the following:

With this done you will have both publisher_member_function.py and subscriber_member_function.py files in your directory. Plus, the __init__.py.

Step 5 - Add dependencies

The next step is to modify some of the files created to support the code we just downloaded. We will be adding the dependencies. Navigate one level back to ~/ros2_ws/src/pubsub.

Open the package.xml file with a text editor. We will be using nano for this tutorial.

After the <license> line add the following lines of code:

Your new file now should look something similar to this:

Exit the file editor and save.

Step 6 - Add entry point

The next file you will have to modify is the setup.py file.

Add the following line within the console_scripts brackets of the entry_points field:

Don't forget to save!

Step 7 - Building and running

First, go back to the root of your workspace:

Then, check if you have any missing dependencies in your code by running:

If everything is installed successfully you can build your package with colcon:

With the build finished we need to source the setup files.

Finally, we can run the code. You will need two terminals to run both the publisher and subscriber.

In one terminal run the publisher:

You should see that the code starts running and prints:

On the other terminal run the subscriber:

When you run the listener, you will start to see the message from the publisher:

Use Ctlr + C in each terminal to stop the code.

Summary

You created two nodes to publish and subscribe to data over a topic. Before running them, you added their dependencies and entry points to the package configuration files.

Introduction

This tutorial describes how to operate MR-Buggy 3 with Logitech Joystick using NavQPlus and FMURT6.

The synapse packages from CogniPilot are built on NavQPlus which will read input from the Joystick and send the appropriate commands to FMURT6 over ethernet.