Pixc4-Jetson Documentation Version 0.1 (Alpha), Last Update 7/3/21

PIXC4-JETSON DOCUMENTATION VERSION 0.1 (ALPHA), LAST UPDATE 7/3/21

INTRODUCTION

The PixC4-Jetson is a professional-quality, highly integrated microcontroller-based Flight Management Unit (FMU), powerful single-board computer and peripheral support system (USB, MIPI, Ethernet, M.2 slot, etc.) in a small form factor, designed to be integrated into end-user platforms. The term “PixC4” is derived from the Pixhawk, on which the FMU design is based (FMUv5) and C4, representing Command, Control, Compute and Communication.

The PixC4-Jetson is designed to be a turn-key solution for advanced unmanned platforms, eliminating the months or years of software and hardware development which typically goes into making such systems.

Command/Control functionality is provided by the FMUv5-based hardware, which is designed around the latest high-stability and low-drift inertial measurement units (IMUs) and a military-grade compass. Compute functionality is handled by an Nvidia Jetson Nano, Xavier NX or TX2 NX which plugs into the onboard 260-pin card edge connector. Included software provides IP network connectivity to the FMU and supports several commercial IP/MANet radios from Horizon31, Doodle Labs, Persistent Systems, Silvus Technologies and Microhard as well as cellular and satcom modems. Pre-installed open-source software from Horizon31 provides ultra-low latency video encoding and streaming, fully customizable so the user can modify to their specific needs. Additional provided software includes advanced VPN connectivity over cellular, ATAK integration and cloud connectivity to Horizon31’s MAVNet system.

The architecture flow diagram for the PixC4-Jetson is shown below:

Figure 1. Left: PixC4-Jetson board with the Jetson module removed. Right: A typical passive heatsink configuration.

COMPLIANCE AND ORIGIN

The PixC4-Jetson is designed, manufactured and supported in the United States. All software development is done in the United States, by US Citizens. Every server used in conjunction with the MAVPN and MAVNet technologies is hosted in a United States data center. There is no network connectivity or data storage located outside the United States, or administered by any entity domiciled in an adversary country.

Horizon31, LLC strives to use components from US-owned companies, and refrains, to the extent possible from using components manufactured by an entity domiciled in an adversary country to include Democratic People's Republic of Korea, the Islamic Republic of Iran, the People's Republic of China, the Russian Federation, or, as determined by the Secretary of Commerce, any other foreign nation, foreign area, or foreign non-government entity engaging in long-term patterns or serious instances of conduct significantly adverse to the national or economic security of the United States. The PixC4-Jetson is NDAA compliant.

QUICK START GUIDE, PIXC4-JETSON DEVELOPMENT KIT

To get started, we will assume that your initial testing is with a PixC4-Jetson Development Kit, which includes the following: • PixC4-Jetson board with Nvidia Nano • Universal Carrier Board • JST to RJ45 cable • USB to serial console cable • ELP USB Camera terminated in JST • XT30-terminated wall power supply

1. Set up your network: a. Set your host computer to a static IP address of 172.20.1.1001. This will be the default endpoint used for video streaming and telemetry. You will be able to change this as needed in the future. 2. Set up the PixC4-Jetson hardware: a. Snap the PixC4-Jetson board into the Universal Carrier Board b. Connect the provided USB camera to one of the 4-pin JST GH USB connectors on the Universal Carrier Board (J21 through J24). c. Connect the Universal Carrier Board Ethernet connector to your network using J9 on the Universal Carrier Board (JST SM04B-GHS-TB(LF)(SN) to RJ45). We recommend starting with a direct connection to your host computer (or use an Ethernet switch) to verify functionality, then move to your radio network. d. Apply power to the stack using the supplied power supply plugged into J27. e. You should see green power LEDS, FMU start up sequence LEDs, and eventually Ethernet activity LEDs along the top edge of the PixC4-Jetson as shown below.

1 For Windows 10, see: https://www.hellotech.com/guide/for/how-to-set-static-ip-windows-10

For Ubuntu, see: https://linuxconfig.org/how-to-configure-static-ip-address-on-ubuntu-18-10-cosmic- cuttlefish-linux

3. Set up your GCS. We recommend using QGroundControl as your test GCS: a. Install QGroundControl on your host PC. (https://docs.qgroundcontrol.com/master/en/getting_started/download_and_install.html) b. In QGroundControl, open Application settings > General > Fly view > General Settings, Video Settings Source = UDP h.264 Video Stream, Port = 5600 and check the “Low Latency Mode” box. See below:

4. QGroundcontrol is preconfigured to accept UDP connections on port 14550, so unless you have a firewall configuration issue or there is a connection problem, QGCS will automatically connect to the PixC4- Jetson’s telemetry feed. 5. You should now be getting a video feed in QGroundControl’s “Fly” view. 6. Congratulations, it works!

PRE-LOADED SOFTWARE

A summary of the software pre-loaded on the PixC4-Jetson is provided below:

• FMU Firmware o Typically, the PixC4-Jetson is shipped pre-loaded with the Ardupilot firmware of your choice. E.g., ArduCopter 4.0.7, ArduRover 4.1, etc. • Nvidia Jetson Pre-loaded software: o H31Proxy: This software provides IP network connectivity to the FMU, handles the MAVNet communication interface to Horizon31’s server, provides ATAK CoT messages and more. o H31Cellular: Provisions the cellular service and starts the cellular network connection. o H31Video: Provides low latency video/audio encoding, streaming and conversion pipelines. This is open-source software the user can modify as needed. o MAVPN: Provides a layer 2 virtual private network connection via Horizon31’s servers. Horizon31 hosts a STUN/TURN server to assist with firewall traversal.

Additional documentation for each of these software packages is available. In general, Horizon31 provided software uses the file structure and set up info below:

• Makefiles are used, with make install handling installation, and make provision setting up configuration files. • Software is located in /usr/local/bin • Config files are located in /etc/system/*.conf • Service files are located in /lib/systemd/system

MECHANICAL DESIGN

The PixC4-Jetson is designed as a self-contained module which can be plugged into a host carrier board using two Hirose FX23L-80S series high-density connectors. Typically, the host carrier board is expected to provide the following functions:

• Provide regulated 5V power derived from the system battery to the PixC4-Jetson • Implement redundant power supplies if desired • Route signals from the PixC4-Jetson to the appropriate devices such as motors, servos, GPS, cameras, etc. via vehicle-specific connectors.

This design architecture is highly future-proof and provides an ideal level of end-user customization, design flexibility and expansion options. While we encourage customers to integrate the PixC4-Jetson into their platform, we also offer a “universal” carrier board solution which can be used as a design template, a development kit or used in end-products (Figure 3).

High-density board to board connectors provides tight integration into end-user products. These connectors provide a rich set of IO including CAN, UART, I2C, Ethernet (X2), MIPI, USB (x4)

Figure 2. Bottom side of the PixC4-Jetson, showing the board-to-board connectors and an installed cellular modem.

The PixC4-Jetson is 83x59mm and weighs 33g (without a Jetson computer attached). The four mounting holes are sized for M2.5 screws and are inset 3.5mm from the board edge. Please see the dimensioned drawings below.

Figure 3. PixC4-Jetson Board Dimensions

Figure 4.PixC4-Jetson board to board connector locations.

A step file of the PixC4-Jetson is available for download: https://drive.google.com/file/d/1onluQSneBSUyq24HlbwWwnJlOzU78AJt/view?usp=sharing

The two board to board connectors are Hirose FX23L-80S-0.5SV and the mating connector is Hirose FX23L-80P- 0.5SV10 (10mm standoff version). Note you may be able to use the 8mm standoff version depending on your own carrier board design and the clearance available. Power and signals from the FMU and Jetson computer are routed via these two high-density connectors.

The FX23L-80S-0.5SV connector is shown below. Note that pin 1 is marked on the PixC4-Jetson with a small dot on the silkscreen, visible in the image above.

Figure 5. FX23L-80S-0.5SV connector drawing. This is the connector on the bottom side of the PixC4-Jetson

The Universal Carrier Board for the PixC4-Jetson (shown below) is included in the development kit and provides the necessary connectivity to get started implementing and testing a solution based on the PixC4-Jetson. This design is open-source and can be used as a design template for creating your own carrier board. The schematic and board layout files (KiCad) are available: https://github.com/horiz31/pixc4_jetson_universal_carrier_public

Figure 6. PixC4-Jetson Universal Carrier Board

The STEP file for the Universal Carrier Board is available here: https://drive.google.com/file/d/1p- Tw4490VoOuMsqg2tXlwOgqGBfQfWUK/view?usp=sharing Using the Universal FMU Carrier Board and The FMUv5 design is based on an STM32H7 microcontroller and STM32F103 IO Doodle Labs Radio processor. The FMU architecture is fully independent of the companion computer, and basic vehicle control functions do not depend on software running on the to Make an Jetson companion computer. The FMU system also shares a different power bus. Integrated “Stack” This design philosophy provides assurance that primary vehicle control and autonomy remains viable even if the companion computer fails or user developed software causes faults or processor overutilization. The Universal Carrier Board • Processor: STM32H743IIK6 contains 4 additional M2 • IOMCU: STM32F103 mounting holes which are • IMUs: ICM-20602 x2 and ICM42688 designed to mate to a • Compass: RM3100 Doodle Labs Smart radio • Barometer: MS5611 using short spacers (~1- • Firmware Support: Ardupilot, PX4 (future) 3mm). It is therefore possible to make a compact NVIDIA JETSON COMPANION COMPUTER stack composed of the PixC4-Jetson – Universal The Jetson computer is set up with Jetpack/Ubuntu and is pre-loaded with core Carrier Board – Doodle software to provide typical functionality for an advanced UxV setup. This includes Smart Radio. Connector J14 IP packet routing (unicast, broadcast or multicast) of the MAVLink telemetry and (Molex 504050-0691) on the low-latency video encoding (unicast or multicast) as discussed above. Universal Carrier Board provides power and The user is given root access via sudo and is free to add software. The Nvidia networking. The power on Jetson products are well-suited to computer vision, machine learning and artificial this connector is reverse- intelligence tasks. Common examples of software running on the companion polarity protected, but computer include obstacle detection/avoidance, collaborative vehicle unregulated battery management, advanced autonomy and many others. While we provide our own voltage. This ensures MAVLink packet router to support IP networking (H31Proxy), users are free to use adequate current delivery to alternate solutions including MAVROS, MAVProxy, DroneKit, MAVSDK, etc. the radio, but the user must To access the Jetson you can use either ssh over the network, or a serial console: ensure that the input voltage to the Universal Carrier The default username and password are below: Board does not violate the radio’s voltage input range.

Username: h31 Password: horizon31 NOTE: We recommend changing the password, using passwd

Option 1: SSH Over the network: Once you have networking configured (see Quick Start Guide above) you should be able to ssh to the Jetson using (from Windows command prompt or Linux terminal):

ssh [email protected] Note: Replace x and y with the actual address, which will be on a sticker on the board. Username/Password: See above

Option 2: Serial Console: You can use a serial console to access the Jetson via the development kit’s Universal Carrier Board console port (J7). We recommend an FTDI USB-to-serial cable such as FTDI TTL-234X-3V3-WE wired in the following pinout. Such a cable is provided with the development kit. Connect this cable to your host PC and use a program like TeraTerm, Putty or minicom to open a console session.

Connection Params: Baud rate is 115200, 8N1 Username/Password: See above

J7 (Universal Carrier Board) Connector: GHR-03V-S Pinout: PIN NUMBER FUNCTION TYPE 1 UART Rx 3.3V TTL Console Input 2 UART Tx 3.3V TTL Console Output 3 Ground Ground

COMMUNICATION

The PixC4-Jetson is designed to support advanced communication needs including BLOS over cellular and satcom. The PixC4-Jetson has an M.2 card slot which accepts Key B cellular modems. A nano-size (4FF) sim card holder is also included on board. Horizon31 offers a turn-key cellular setup where we provide a fully provisioned sim with global LTE/5G access through AT&T and partners.

Communication modalities available with the PixC4-Jetson include Line of Sight (often called Mobile Ad Hoc Networks (MANet, not to be confused with MAVNet), Cellular and satcom:

Line of Sight: This is the traditional method of GCS to vehicle communication, provided by IP radios from several companies including Horizon31, Doodle Labs, Persistent Systems, Silvus, Microhard and others. Most of these radios feature advanced meshing capabilities and are often referred to as Mobile Ad-Hoc Networking (MANet) radios. The H31Proxy software allows you to configure the type of network streaming used over this link. Traditionally the simplest setup is UDP unicast to a known GCS IP address. However, more complicated architectures are available. For example, you may multicast the telemetry to a group address or even broadcast the telemetry to the entire subnet if your radio supports it.

Cellular: By default, if you purchase a PixC4-Jetson with cellular, Horizon31 will ship it provisioned with a global AT&T sim card and access to the Horizon31 MAVPN service for a monthly access fee. MAVPN is a layer 2 Virtual Private Network (VPN) solution which allows the vehicle and GCS to communicate securely across the open internet. MAVPN can traverse firewalls and relay data as needed to provide a true peer-to-peer solution. With MAVPN running on the PixC4-Jetson and MAVPN running on your host computer, the two devices appear as if they are on the same LAN, so any networking or application-level software works seamlessly. In the H31Proxy configuration you have the option to set up the

telemetry for the MAVPN connection independently of the LOS connection. E.g., it is possible to multicast on LOS, but broadcast on MAVPN.

By customizing the GCS application, it is possible to create automatic failover scenarios, where a vehicle can seamlessly transition between LOS and cellular as the network quality changes or the limits of a LOS network are reached. Horizon31 provides an open-source example of how to implement such functionality using QGroundControl (https://github.com/horiz31/qgroundcontrol).

Iridium Satellite: The PixC4-Jetson is compatible with Iridium SDB modems. The Univseral Carrier Board includes an interface for the Rockblox 9603 Iridium SBD modem. Software is currently in development to use this interface for the MAVNet system (see below).

MAVNet: The Multimodal Autonomous Vehicle Network (MAVNet) is a patented (US Patent 11,005,662) communication architecture used by Horizon31 to provide scalable cloud-connectivity and web access to your vehicle. A process within the H31Proxy software implements the MAVNet interface, sending size-optimized packets to a central cloud server. A web-based GCS (https://gcs.horizon31.com) allows users to view vehicles on a 3D map, see telemetry data, view real-time video feeds and more. MAVNet relies on cellular for Internet access from the vehicle but can also use Iridium SBD for telemetry information. MAVNet is an industry first, and enables fleet management, cloud-based flight logs and a refined web-based user interface. Unlike other commercial solutions, MAVNet is scalable, allowing multiple users/viewers for the same vehicle or one pilot controlling multiple vehicles at the same time. Among MAVNet’s patented features includes the ability to send vehicle commands over different types of links, each with different characteristics (latency, bandwidth) and providing a logical, safe and predictable execution of those commands. Learn more about MAVNet on our website https://horizon31.com/mavnet/.

Figure 7. The MAVNet web GCS, zoomed out and showing 2 assets in east Tennessee.

VIDEO ENCODING AND STREAMING

The video encoding system packaged with the PixC4-Jetson is built on Gstreamer along with RidgeRun’s Gstd and Gstinterpipe. GStreamer is a pipeline-based multimedia framework that links together a wide variety of media processing systems to complete complex workflows. Gstd (or Gstreamer Daemon) is a Gstreamer framework for controlling audio and video streaming using an Interprocess Communications Protocol. GstInterpipe is a GStreamer plug-in that allows pipeline buffers and events to flow between two or more independent pipelines.

Gstd: https://developer.ridgerun.com/wiki/index.php?title=GStreamer_Daemon

GstInterpipe: https://developer.ridgerun.com/wiki/index.php?title=GstInterpipe

H31Video source code: https://github.com/horiz31/h31video

In the open-source H31Video project, users can see how these three systems are used to create complex video and audio pipelines. In the default configuration, video from a common h.264 USB camera is streamed to four endpoints. The h.264 USB camera we provide with the development kit contains three sources: h.264 encoded stream, a motion-JPEG encoded stream and a raw stream (x-raw). In the example H31Video code, we use the h.264 stream and the x-raw stream. We took this approach because the h.264 stream from the camera is of high quality and low-latency and it is preferred for the primary LOS link. However, other links warrant lower bandwidth connections (e.g., an ATAK application running on a phone looks ok with only 500 kpbs and does not need ultra- low latency). By using the two camera endpoints we are able to achieve flexibility in how we use the available bandwidth.

h.264 Encoded endpoint from camera

• Video bitrate is set to the desired bitrate (typically ~2Mbps is adequate) using the camera manufacturer’s driver. Video is streamed to the primary GCS (unicast or multicast if the GCS supports it) to an IP address routed to the primary radio interface.

x-raw endpoint from the camera:

• The x-raw camera endpoint is effectively split into 3 independent streams using Gstinterpipe. The first is h.264 encoded, scaled and streamed to an IP address routed to the MAVPN network interface (typically named edge0). This video source is used by a MAVPN-connected GCS. Because MAVPN connections from the vehicle are typically over cellular, we set this to a lower bitrate than the primary LOS stream above (1.0 Mbps). • The second x-raw split is h.264 Encoded at 1.0 Mbps, scaled and streamed to the H31 MAVNet server (video.horizon31.com) for distribution to users using https://gcs.mavnet.online. This stream requires Internet or it won’t start (typically via LTE or 5G Cellular) and should only be used with adequate upload speed. • The optional third x-raw split is h.264 encoded at 750Kbps, scaled and streamed to an ATAK multicast group. H31Proxy uses this address in the CoT message, so compatible devices (e.g., ATAK devices) can open this video feed by parsing the CoT message.

The video scripts are all open source, so the configuration above can be changed/adapted as needed for the end- user application. Using Gstinterpipe, complicated video control can also be achieved from the user’s application using inter-process communications. Likewise, additional video cameras can be integrated. MIPI/CSI cameras are supported by hardware, please ensure there is a driver available for the Jetson hardware you are using. Other

camera input types including HDMI can be implemented by using the proper adapter hardware on a custom carrier board (e.g., HDMI to CSI-2 bridge, Toshiba TC358743XBG) or with 3rd party adapter boards such as the Auvidea B102.

SELF-HEATING DESIGN

Modern, high-precision inertial measurement units (IMUs) are much more temperature stable than the designs of several years ago, making built-in board heating largely unnecessary. However, the IMUs on the PixC4-Jetson are placed in a “shielded” location underneath the Nvidia Jetson to take advantage of self-heating from the compute module’s thermal radiation.

HEAT MANAGEMENT

The PixC4-Jetson board itself does not need additional thermal management, but the Jetson companion computer needs (at minimum) a passive heatsink. Alternatively, commercial heat spreader plates are available that can be used to mate the Jetson Nano/Xavier NX/TX2 NX to a metal structure or external, air-exposed heatsink.

All radios typically used with the PixC4-Jetson will also need thermal management. Please refer to the manufacturer’s documentation.

VIBRATION ISOLATION

For many vehicle types, vibration isolation is not required. However, if your vehicle is powered by or contains an internal-combustion engine or uses props more than 30”, vehicle flight performance may benefit from vibration isolation of the PixC4-Jetson. The PixC4-Jetson board does not provide separate vibration isolation of the IMUs because testing shows this is ineffective for low-frequency vibrations present in large multirotor and IC-powered vehicles. Rather, isolating the entire PixC4-Jetson is recommended, as this allows the user to take advantage of the board and companion computer mass to help damp low frequency vibrations while also protecting the critical electronics from potentially harmful vibrations. Please contact us for assistance using commercial vibration isolators or designing a custom solution.

NETWORKING CONFIGURATION

Each PixC4-Jetson is configured to a static IP address from the factory. There is a sticker on the board with this IP address. Default configuration uses the 172.20.0.0/16 address space.

Because of complications with DHCP in deployed UxV scenarios, we recommend using a “flat” network wherein each device is assigned a static IP address. However, users can change the network configuration on the PixC4- Jetson as needed using standard Linux networking toolsets.

Each PixC4-Jetson comes with the following telemetry/video network configuration (please see /etc/system/h31proxy.conf and /etc/system/video.conf):

• Telemetry on LOS network: unicast to 172.20.1.100:14550 • Telemetry on MAVPN: unicast to 173.20.1.100:14560 • Video on LOS: unicast to 172.20.1.100:5600 • Video on MAVPN: unicast to 173.20.1.100:5601 • ATAK CoT messages: multicast to 239.2.3.1

In this configuration, if the host computer is set to a static IP address of 172.20.1.100 on the standard network interface, and 173.20.1.100 on the MAVPN interface, telemetry and video should be available at the GCS over both networks.

To receive telemetry over the LOS network: no change is required as QGroundControl defaults to an open port on 14550.

To receive telemetry over the MAVPN network: add an additional UDP connection in QGroundControl (or other GCS) for port 14560.

To receive video over the LOS network: no change is required other than to enable h.264 video streaming (see Quick Start Guide).

To receive video over the MAVPN network: change the video receiving port to 5601.

This is a simple configuration, and much more complicated scenarios can be created, see details below for a multicast configuration.

MULTICAST SETUP

As a more complicated example, consider the use case where you wish to configure telemetry/video networking to leverage multicast groups, and to introduce dynamic video uniform resource identifiers (URIs) so that multiple vehicles can coexist on the same network and/or so video can be switched between multiple comms links (such as LOS and MAVPN/Cellular):

• Telemetry on LOS network: multicast to 224.10.10.10 • Telemetry on MAVNPN: multicast to 225.10.10.10 • Video on LOS: multicast to 224.11.x.y where x.y is the same as the telemetry source • Video on MAVPN: multicast to 225.11.x.y where x.y is the same as the telemetry source • ATAK CoT messages: multicast to 239.2.3.1

Windows Routing Setup with the above example

In this case, you need to make sure there is a route for the multicast packets coming in on the 224.0 and 225.0 groups with the appropriate interfaces. To add a default persistent route to windows, open a command window as an Administrator:

netsh interface ipv4 show interfaces Note the interface Idx for the edge and ethernet interface (this is assuming edge is already running of course). Assuming the Idx was 5 for MAVPN (edge0) and 7 for LOS (system’s standard ethernet interface), then

route -p ADD 224.0.0.0 MASK 255.0.0.0 0.0.0.0 metric 1 IF 7 route -p ADD 225.0.0.0 MASK 255.0.0.0 0.0.0.0 metric 1 IF 5 This command adds a persistent (-p) routes with a metric of 1 (lowest) on interfaces index 5 and 7

On Windows, if running MAVPN, it may need to ensure the MAVNPN network is a private network (rather than public), as public networks may cause UDP firewall issues. To do this perform the steps below.

Run Windows PowerShell elevated as admin:

Get-NetConnectionProfile Make note of the connection Name for the edge interface and determine if it is public. Assuming the name is "Local Area Connection":

Set-NetConnectionProfile -Name "Local Area Connection" -NetworkCategory Private

PixC4-Jetson Routing Setup

To set up the route temporarily on Linux (e.g., for testing)

sudo ip route add 224.0.0.0/8 dev eth0 sudo ip route add 239.0.0.0/8 dev eth0 echo 1 > /proc/sys/net/ipv4/ip_forward To set up the route permanently, edit /etc/network/interfaces, adding the following routing info to the end of the file.

sudo nano /etc/network/interfaces Add the following lines:

up route add -net 224.0.0.0/8 dev eth0 up route add -net 239.0.0.0/8 dev eth0 Within nano, use Ctrl-O to write the file, and Ctrl-X to exit.

Note that MAVPN sets up its own routes when it starts, and defaults to using the 225.0.0.0/8 address space.

H31PROXY VIDEO URI PROTOCOL

With the PixC4-Jetson, more complicated video encoding and switching scenarios are possible than with designs not optimized for UxVs. For example, H31Proxy and the provided video encoding solution provides multiple video endpoints per vehicle (e.g., one for the LOS network and one for the cellular/MAVPN) network. Additionally, multiple PixC4-Jetsons can co-exist on the same network and video endpoints on the GCS will need to be updated when a different active vehicle is selected. The H31 software stack implements this functionality by using the simple protocol below.

H31Proxy software ingests the video configuration file (video.conf) at startup and then parses the incoming mavlink messages from a connected GCS for a MAV_CMD REQUEST_MESSAGE sent to the component ID MAV_COMP_ID_ONBOARD_COMPUTER with a parameter 1 of VIDEO_STREAM_INFORMATION and a parameter 3 specifying the port the GCS is listening on for video.

In effect, the GCS queries the PixC4-Jetson for the video endpoint (URI) for the specified video port, and H31Proxy responds using a VIDEO_STREAM_INFOMATION packet which contains this URI. H31Proxy determines the active interface (e.g., LOS or MAVPN) by matching the port specified with the ports defined in the H31Proxy configuration file.

When the GCS receives and parses the VIDEO_STREAM_INFORMATION message it can then update the active video stream being displayed based on this URI. Horizon31 provides an open-source implementation of this setup

for QGroundControl (https://github.com/horiz31/qgroundcontrol) however it should be possible to implement a similar video setup in any GCS.

GCS PixC4-Jetson H31Proxy Software MAV_CMD_REQUEST_MESSAGE Sent to the vehicle SystemID, Component MAV_COMP_ID_ONBOARD_COMPUTER Param1: 269 (VIDEO_STREAM_INFORMATION) Param3: Current video port

VIDEO_STEAM_INFORMATION If a matching port is found in the config file, then the uri field provides the valid URI for this port.

The GCS should now update its video endpoint based on the URI received.

HARDWARE CONNECTIONS

The PixC4-Jetson hardware connections and LED locations are shown below. In practice, the primary connectors used are J5 and J6, the two Hirose FX32L high-density board to board connectors.

Connections are summarized below:

J31: USB-SS to the Jetson Computer

Connector: Standard USB-C Pinout: Standard USB-C 3.0 SS

J10: FMU SD Card

Connector: Molex 0473093351 Pinout: Standard SD Card J8: Optional 5V power in to the Jetson computer. Note: This is generally used for debug only. It is not protected from overvoltage. In practice, 5V power should be supplied via a carrier board and connectors J5 and J6.

Connector: JST B2B-XH-A(LF)(SN) Pinout: PIN NUMBER FUNCTION TYPE 1 Ground Ground 2 +5V Power to Jetson

J38: FAN

Connector: Molex 0530470410 Pinout: PIN NUMBER FUNCTION TYPE 1 Ground Ground 2 +5V Power 3 Fan Tach Signal Tachometer Signal from fan 4 Fan PWM Signal PWM Signal to control fan

J25: Debug USB port to the Jetson

Connector: JST SM04B-GHS-TB(LF)(SN) Pinout: PIN NUMBER FUNCTION TYPE 1 USB VBUS VBUS Input from USB Host 2 D- USB Data - 3 D+ USB Data + 4 Ground Ground

U40: Cellular SIM card slot (nano/4FF sim)

Connector: Molex 1042240820

Pinout: SIM card, adheres to ISO 7816-1, 2, 3. SIM card is size 4FF.

J7: FMU USB

Connector: Standard USB-C

Pinout: Standard USB 2.0

J36: M.2 Key B slot

Connector: TE 2199230-3

Pinout: Key-B, includes USB and SIM. See below:

J5: Board to Board connector (Jetson signals)

Connector: Hirose FX23L-80P-0.5SV10 Pinout: see below

J6: Board to Board connector (FMU signals)

Connector: Hirose FX23L-80P-0.5SV10 Pinout: see below. Note that J6 pins 81-86 are used for the Jetson power, NOT the FMU power. FMU power is supplied on pins 62-69.

J12: FMU Debug Port (compatible with Zubax Dronecode probe)

Connector: JST SM06B-SRSS-TB(LF)(SN) Pinout: see below PIN NUMBER FUNCTION TYPE 1 3.3V 3.3V out from FMU 2 UART TX Output from FMU Debug UART 3 UART RX Input to FMU Debug UART 4 SWDIO JTAG IO 5 SWCLK JTAG CLK 6 Ground Ground

J13: IO Debug Port (compatible with Zubax Dronecode probe)

Connector: JST SM06B-SRSS-TB(LF)(SN) Pinout: see below

PIN NUMBER FUNCTION TYPE 1 3.3V 3.3V Out from FMU, IO 3.3V Bus 2 UART TX Output from FMU Debug UART 3 UART RX Input to FMU Debug UART 4 SWDIO JTAG IO 5 SWCLK JTAG CLK 6 Ground Ground

ARDUPILOT FIRMWARE BUILD INSTRUCTIONS

Building Ardupilot for the PixC4-Jetson board is straightforward, but there are a few important notes. Start by setting up the build environment as documented here: https://ardupilot.org/dev/docs/building-setup- linux.html#building-setup-linux. We highly recommend using Ubuntu/Linux as the build environment.

By default, the io firmware packaged during the build process is for an STM32F100 with a 24 MHz clock. This must be changed because the PixC4-Jetson uses a STM32F103 with an 8MHz clock. We therefore need to make some minor edits to the iomcu hardware configuration file and then rebuild the io firmware:

1. Edit ardupilot/libraries/AP_HAL_ChibiOS/hwdef/iomcu/hwdef.dat

nano ~/ardupilot/libraries/AP_HAL_ChibiOS/hwdef/iomcu/hwdef.dat

2. Edit the file, changing the following lines:

MCU STM32F103 STM32F103xB OSCILLATOR_HZ 8000000 FLASH_SIZE_KB 128

The file should look like this when complete: https://github.com/horiz31/ardupilot/blob/PixC4- Jetson/libraries/AP_HAL_ChibiOS/hwdef/iomcu/hwdef.dat

3. Rebuild the io firmware

cd ~/ardupilot ./Tools/scripts/build_iofirmware.py

You can now continue the build steps for the target “PixC4-Jetson.” If you are building a version of Ardupilot which does not have the PixC4-Jetson hardware definition (hwdef) files included, you may download them and place them in the libraries/AP_HAL_ChibiOS/hwdef/PixC4-Jetson folder. To determine this, simply check if you have a libraries/AP_HAL_ChibiOS/hwdef/PixC4-Jetson folder. If you need to download these files, you can download them here:

https://github.com/horiz31/ardupilot/tree/PixC4-Jetson/libraries/AP_HAL_ChibiOS/hwdef/PixC4-Jetson

Download both files, create an ardupilot/libraries/AP_HAL_ChibiOS/hwdef/PixC4-Jetson folder and place the files in that folder.

Now build the bootloader for the PixC4-Jetson FMU:

cd ~/ardupilot ./waf configure --board PIXC4-Jetson --bootloader ./waf clean ./waf bootloader

If this completes without errors, you are now ready to build the firmware, copter in this example. The –upload switch will upload to the board directly if you use J7 (USB-C FMU port) on the PixC4-Jetson. Wait to plug in the USB cable until prompted because the PixC4-Jetson bootloader only accepts firmware uploads the first few seconds after initial powerup.

./waf configure --board PIXC4-Jetson ./waf clean ./waf copter --upload

Final notes: the PixC4-Jetson uses a new ICM42688P IMU that is not supported yet by all firmware builds. If building with a firmware which does not support this IMU, you can comment out the line below in the ardupilot/libraries/AP_HAL_ChibiOS/hwdef/PixC4-Jetson/hwdef.dat file by adding a “#” at the beginning of the line, e.g.:

#IMU Invensense SPI:icm42688 ROTATION_YAW_90

Important Ardupilot Parameters

Because the FMU connects to the Jetson using a UART, if you update/change firmware on the FMU, you must ensure the FMU’s serial port is still set up correctly. The following Ardupilot parameters should be set:

SERIAL2_BAUD: 500000 (see footnote 2)

SERIAL2_OPTIONS: 0

SERIAL2_PROTOCOL: MAVLink2

2 Be sure and verify that the baud rate has not been changed from the default speed. See /etc/systemd/h31proxy.conf.