Hello!
I am using a Linux based companion computer (CC) to perform some real time processing along with the Pixhawk Cube Orange flight controller.
The companion computer reads the mavlink messages from the flight controller via pymavlink. But I discovered that for reading the mavlink messages on CC, we need to start mavproxy.py first.
At the same time, I also need the telemetry data to my GCS (MissionPlanner).
However, when the telemetry data is being sent to the ground station, the CC cannot start mavproxy and gives an error stating that the port is busy.
Any solution on how I can access the telemetry data as well as mavlink messages on CC at the same time?
Thanks
Can you clarify the below questions -
How Companion Computer is connected to your Flight controller?
Where the GCS (Mission planner) is running?
If both are running on the same device, you can use Mavlink forwarding to achieve your requirement.
1 Like
This is the basic connection:
So I guess mavlink forwarding wont work in this case.
Yes, Mavlink forwarding wont work in that case.
I hope you have connected the Companion Computer (Raspberry pi) and Pixhawk Cube orange as shown below:
And configured SERIAL2_PROTOCOL = 2 and SERIAL2_BAUD = 921 params
Now, You can directly read the Mavlink messages on CC using pymavlink without starting mavproxy.py. Below is the example Python script:
from pymavlink import mavutil
# Connect to the vehicle (modify the port and baud rate as needed)
serial_port = input("Enter serial port in this format '/dev/ttyAMA0': ") # Change this to your specific connection string
baud_rate = int(input("Enter baud rate: "))
mav = mavutil.mavlink_connection(serial_port, baud=baud_rate)
# Wait for the heartbeat from the drone to ensure a successful connection
mav.wait_heartbeat()
print(f"Heartbeat received, System_ID: {mav.target_system} Component_ID: {mav.target_component}")
If /dev/ttyAMA0 doesn’t work you can try /dev/ttyUSB0 (in case of USB) or /dev/ttyS0 - Reference
1 Like
Thanks for the reply!
I am able to read the messages on my CC. However, a few correction in the connection diagram you referred to. The CC is connected to the FC as shown below:
When the telemetry data is being read on the mission planner on the laptop, at that time if the CC runs a script, the script outputs an error stating that the port is busy.
