Solving Raspberry Pi-Pixhawk Telemetry Connection

A comprehensive guide to diagnosing and fixing serial communication issues between your flight controller and companion computer

Introduction

Establishing a reliable telemetry connection between a Pixhawk flight controller and a Raspberry Pi companion computer is crucial for advanced drone operations. However, this connection can sometimes fail without obvious reasons, leaving developers frustrated.

In this article, we'll walk through a real-world case where a telemetry connection that worked on one Raspberry Pi failed on another identical setup, and how we systematically diagnosed and resolved the issue.

The Problem

Initial Setup

The hardware configuration consisted of:

Pixhawk flight controller with TELEM1 port connected via JST-GH 6-pin connector
Raspberry Pi companion computer with GPIO serial connection
Rpanion-server software for communication

The Issue

Despite identical hardware configurations working on another system, the new Raspberry Pi refused to establish telemetry connection with the Pixhawk. The Rpanion-server interface showed no connection, and attempts to diagnose the issue initially yielded no clear answers.

The Challenge

The most puzzling aspect was that an identical setup worked perfectly on another Raspberry Pi, suggesting the issue wasn't with the fundamental approach but with something specific to this particular device or its configuration.

Diagnostic Journey

Initial Investigation

We began by examining the Rpanion-server interface, which showed no active connection to the flight controller. The first step was to verify the physical connections:

Confirmed JST-GH 6-pin connector was properly seated in Pixhawk's TELEM1 port
Verified correct wiring to Raspberry Pi GPIO pins (TX->RX, RX->TX, GND->GND)
Checked for power issues or loose connections

Software Configuration Check

Next, we examined the software configuration on the Raspberry Pi:

# Checked current kernel command line
cat /proc/cmdline

# Output showed:
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 [...] console=ttyS0,115200 [...]
 

This output revealed the smoking gun: console=ttyS0,115200 - the Linux system was using the serial port as a console for system messages and login, which completely takes over the port and prevents any other software from using it.

Identifying the Root Cause

The issue was a serial console conflict. The kernel parameter console=ttyS0,115200 was reserving the serial port for system use, making it unavailable for Rpanion-server to communicate with the Pixhawk.

The Conflict

The serial console was enabled, taking exclusive control of the GPIO serial port. This is a common default setting on many Raspberry Pi images, especially those designed for general-purpose use rather than embedded applications.

The Implication

With the serial port occupied by the system console, Rpanion-server couldn't access it to establish communication with the Pixhawk, resulting in the failed telemetry connection.

The Solution

Step 1: Disabling the Serial Console

On Raspberry Pi OS, this is typically done using raspi-config or by modifying /boot/config.txt. However, our system was running a custom Ubuntu-based distribution that didn't include these tools.

# Instead, we edited the kernel command line parameters
sudo nano /boot/firmware/cmdline.txt
 

Step 2: Modifying the Kernel Parameters

We located the kernel command line in /boot/firmware/cmdline.txt and removed the serial console parameter:

# Before:
console=serial0,115200 multipath=off dwc_otg.lpm_enable=0 console=tty1 [...]

# After:
multipath=off dwc_otg.lpm_enable=0 console=tty1 [...]
 

We carefully removed console=serial0,115200 while preserving other important parameters.

Step 3: Rebooting and Verification

After saving the changes, we rebooted the Raspberry Pi:

sudo reboot

After reboot, we verified that the serial console was no longer active:

cat /proc/cmdline

# Output now showed:
coherent_pool=1M 8250.nr_uarts=1 [...] multipath=off dwc_otg.lpm_enable=0 [...]
 

The console=serial0,115200 parameter was successfully removed, freeing up the serial port for use by Rpanion-server.

Step 4: Configuring Rpanion-server

With the serial port now available, we configured Rpanion-server:

Set the Serial Device to /dev/serial0
Set the Baud Rate to match the Pixhawk's SERIAL1_BAUD parameter (57600)
Stopped and restarted telemetry to apply the new settings

The telemetry connection was successfully established immediately after these changes.

Conclusion

Successfully Resolved

The telemetry connection between the Raspberry Pi and Pixhawk was successfully established after disabling the serial console that was occupying the GPIO serial port. The solution was simple but required understanding how Linux manages serial ports and where to configure these settings on a custom distribution.

Key Takeaways

Serial Console Conflict: The most common reason for serial communication failure on Raspberry Pi is the enabled serial console.
Distribution Differences: Different Raspberry Pi distributions (Raspberry Pi OS vs. Ubuntu) manage serial configuration in different locations.
Diagnostic Approach: Always check cat /proc/cmdline to see if a serial console is enabled before investigating other potential issues.
Minimal Impact: Disabling the serial console doesn't affect system functionality if you have alternative access methods (HDMI, SSH).

Prevention

To avoid this issue in future deployments:

Use Raspberry Pi OS Lite for embedded applications rather than desktop distributions
Disable the serial console during initial setup with raspi-config
Consider using USB connection between Pixhawk and Raspberry Pi instead of GPIO serial for easier setup
Document the configuration steps for future reference