PX4 support for Gemstone is still in the development phase. It runs on the
main-domain R5F core, and some peripherals on the board, such as CAN Bus, are
not yet available. The board also has no barometer or GPS, so altitude and
absolute position estimation are limited.
t3-gem-o1 configuration
created for the bare NuttX build. The flight software starts automatically
when the board boots, and the QGroundControl ground control application
connects to the vehicle over the network.
Unlike a standalone NuttX build, PX4 vendors both NuttX and its application
framework as git submodules. A recursive clone therefore pulls the correct,
Gemstone-tuned NuttX automatically, so there is no need to download or build
NuttX separately.
1. Compilation
1.1. Downloading Source Codes
On Ubuntu/Debian systems, first install the tools needed for downloading and
compiling with the package manager:
PX4 references the Gemstone NuttX and NuttX‑apps as git submodules, so the
sources are downloaded with a single recursive clone:
If you cloned without --recursive, fetch the
submodules afterwards with git submodule update --init --recursive.
1.2. Setting Up the Python Environment
PX4’s build system relies on a set of Python tools such as kconfiglib,
empy and jinja2. Because recent Debian/Ubuntu releases restrict
system‑wide pip installations, install them into a virtual environment
(run from the PX4-Autopilot directory cloned in section 1.1):
Activate the environment with source ~/px4-venv/bin/activate in every new
shell before building.
1.3. Compiling the Project
PX4 builds a specific board target directly, so no separate configuration step
is required. With the Python environment from section 1.2 active, compile the
Gemstone board image:
This performs a parallel build and produces
build/t3gemstone_o1_default/t3gemstone_o1_default.elf (the image loaded onto
the R5F core) along with .bin and .px4 files.
2. Running
Like the bare NuttX image, PX4 runs on the main-domain R5F core and is loaded
from Linux or U-Boot using the remoteproc mechanism. While PX4 runs on the R5F
core, Linux continues to run on the A53 cores.
Program files to be loaded onto the cores via remoteproc must be copied to the
/lib/firmware directory with predefined names. At system startup, the
remoteproc mechanism will automatically load the programs onto the relevant
cores. Follow the steps below to run PX4 using remoteproc.
-
Copy the compiled image to the board (the board is reachable at
192.168.7.2 when connected over the USB Type-C cable):
-
On the board, place the image in the
/lib/firmware directory with the
predefined name and reboot:
-
Connect a USB-to-TTL device to the UART-MAIN1’s GPIO-14 (TX) and
GPIO-15 (RX) pins on the 40-pin HAT, then open the NuttShell console
from your PC (exit with
Ctrl-A followed by Ctrl-X; the device name
may differ, e.g. /dev/ttyUSB1, if other USB serial adapters are
connected):
-
From the opened
nsh console you can inspect the running system with
commands such as ver all, top, and uorb status.
3. Using the Sensors
The on‑board InvenSense ICM‑20948, a 9‑axis IMU with an accelerometer,
gyroscope and an integrated AK09916 magnetometer, is connected to the R5F over
SPI. The boot script (section 4) already starts the driver together with the
rest of the flight stack; the commands below are useful when experimenting
with the driver on its own:
Here -s selects the SPI interface, -b 1 the SPI bus, -c 3 the
chip‑select, and -M additionally enables the magnetometer. Once the driver is
running, you can stream the live sensor data through PX4’s uORB middleware with
the listener command:
To observe the overall system, uorb top lists the publication rates of all
active topics and work_queue status shows the timing of the driver’s work
queue.
4. Flight Stack Autostart
When the R5F starts, PX4 starts all of its components automatically: the sensor driver, attitude estimation, the
flight controllers and the telemetry link. The board is configured as a Generic Quadcopter X airframe. No manual
startup commands are needed.
You can verify that the system is running from the nsh console. The uorb top command lists the data topics that
PX4’s components publish, together with their update rates; sensor and attitude topics updating at a steady rate mean
the flight software is alive:
The listener command prints the live content of a topic. For example, the vehicle’s current orientation:
5. Networking and QGroundControl
PX4 and the Linux side are connected by a network link: eth0 on NuttX and eth1 on Linux.
- NuttX IP:
192.168.10.2
- Linux
eth1 IP: 192.168.10.1
- MAVLink Port: UDP
14550
5.1. Installing the Network Module
Install the network module package and reboot the board:
5.2. Configuring the Link
Configure the Linux side of the link (required after every boot):
Configure the NuttX side from the nsh console and verify the link:
5.3. Reaching the Board Network from the PC
Connect the Gemstone board to your PC via USB Type-C cable and add a route so that the 192.168.10.0/24 network is
reachable through the board:
Find your PC’s own address on the board network; it is used as the MAVLink target in the next step:
5.4. QGroundControl Connection
QGroundControl (QGC) is the application used to monitor and control the vehicle from a PC. Install it from
qgroundcontrol.com and start it.
Start the telemetry link from the nsh console, replacing 192.168.7.60 with your PC’s address from the previous
step:
QGC will automatically detect and connect to the vehicle if UDP autoconnect is enabled (default setting).
6. Troubleshooting
6.1. No eth1 Interface on Linux
Check that the virtio_net module is loaded:
If the command prints nothing, load the module manually and check again:
6.2. No MAVLink Connection
Verify network configuration from the PC; the board must answer:
If there is no answer, repeat the steps in Networking and QGroundControl.
Check that the telemetry link is running and transmitting on the NuttX side; the tx rate value must be greater
than zero:
Ensure QGC UDP autoconnect is enabled in Application Settings.
