Companion Computer Receives mavlink messages from FC but the FC does not execute commands from Companion Pc

ArduCopter
1

I have a Cuav x7+ running Arducopter 4.5.6 which is connected to a raspberry-pi 4B.

My raspberry-pi seems to be receiving mavlink message from the FC, however, the commands sent by the raspberry-pi are not being acknowledged by the FC.

For now I only want to perform simple actions only, like changing flight modes. I am using pymavlink to send and receive the messages, and I am only trying the scripts available in ardusub wesbite. But it is not working. Prior to this I have used the same scripts on SITL as well, they work well in SITL.

I have checked the wire connections multiple times. To check if it is due to the firmware version, I have tried a few other versions as well. But the status is the same.

I have tried sending commands from maxproxy as well but, the commands are not being executed via maxproxy too.

2

Can you post the script?

Is this MAVProxy running on the Raspberry Pi?

3

Thank you for the reply.

I am using the following script from this website to try and change the flight mode.

import sys
# Import mavutil
from pymavlink import mavutil

# Create the connection
master = mavutil.mavlink_connection('/dev/ttyS0', wait_ready=True, baud=115200)
# Wait a heartbeat before sending commands
master.wait_heartbeat()

# Choose a mode
mode = 'STABILIZE'

# Check if mode is available
if mode not in master.mode_mapping():
    print('Unknown mode : {}'.format(mode))
    print('Try:', list(master.mode_mapping().keys()))
    sys.exit(1)

# Get mode ID
mode_id = master.mode_mapping()[mode]
# Set new mode
# master.mav.command_long_send(
#    master.target_system, master.target_component,
#    mavutil.mavlink.MAV_CMD_DO_SET_MODE, 0,
#    0, mode_id, 0, 0, 0, 0, 0) or:
# master.set_mode(mode_id) or:
master.mav.set_mode_send(
    master.target_system,
    mavutil.mavlink.MAV_MODE_FLAG_CUSTOM_MODE_ENABLED,
    mode_id)

while True:
    # Wait for ACK command
    # Would be good to add mechanism to avoid endlessly blocking
    # if the autopilot sends a NACK or never receives the message
    ack_msg = master.recv_match(type='COMMAND_ACK', blocking=True)
    ack_msg = ack_msg.to_dict()

    # Continue waiting if the acknowledged command is not `set_mode`
    if ack_msg['command'] != mavutil.mavlink.MAV_CMD_DO_SET_MODE:
        continue

    # Print the ACK result !
    print(mavutil.mavlink.enums['MAV_RESULT'][ack_msg['result']].description)
    break

I cannot change the flight mode to any other flight modes using the script. Also there are three different methods to change the flight mode in the above script, two of which have been commented out. I have tried using all three methods.

The line to send command for changing the flight mode is executed and it seems to get stuck at the line that waits for the COMMAND_ACK message.

I can however read the messages like GPS_RAW_INIT and EKF_STATUS_REPORT using this script:

import sys
# Import mavutil
from pymavlink import mavutil

# Create the connection
master = mavutil.mavlink_connection('/dev/ttyS0', wait_ready=True, baud=115200)
# Wait a heartbeat before sending commands
master.wait_heartbeat()

print("Connected")

gps = master.recv_match(type='GPS_RAW_INT', blocking=True)
print(gps)
ekf = master.recv_match(type='EKF_STATUS_REPORT', blocking=True)
print(ekf)

Yes the Mavproxy is running on the raspberry pi. The following is the snippet of it.

image

In the above snippet, you will notice even if I send command to change the flight mode to guided mode multiple times, it remains in stabilize mode.

4

Is there a possibilities the wire contact is intermittent?
Assuming your RX to TX and TX to RX is correct.
Try to use a multimeter to check the resistance value between points and health.

5

There does not seem to be any issue with wire connection.

6

how about serial/Uart/com/Telem port baud rate compatibility?

7

The raspberry-pi is connected to the TELEM2 port of the FC via serial. The SERIAL2_BAUD is set to 115 (meaning a baud rate of 115200?) . The script I am using is also using the baud rate of 115200 to connect.

8

interesting, I have both Pi and Jetson board experience and never come across your issue.

Do you have the access right on the /dev/ttyS0 port?
Have you used the wrong port?

#Pi Ubuntu 22.04.xx
await drone.connect(system_address="serial:///dev/ttyAMA1:921600")

#Jetson Jetpack 5.x
res = await asyncio.wait_for(drone.connect(system_address="serial:///dev/ttyTHS0:921600"), 45)
9

As I mentioned previously, I can connect to the FC using /dev/ttyS0 port and listen to heartbeats and other messages like GPS_RAW_INIT and EKF_STATUS_REPORT etc. This might not be possible if the access to the port was wrong or the wrong port was used, right?

10

Not sure, I usually use this to verify with a PC console to remove hardware or access issues.

Looks like you are on your own, we usually do not face this basic two-way communication issue.

Or are you trying to change to Guide mode indoors?

11

I’m not 100% sure, but I don’t think you can switch to guided before arming. Normally, in SITL, I have to do this procedure: mode loiter, arm, takeoff altitude, mode guided.

But I’m not sure if you’re having trouble only with switching to Guided, or if you’re having trouble sending any kind of command.

1 Like
12

Ok, that’s quite interesting, of note the parameters are not being downloaded. It does look like there’s an issue somewhere in the Tx line from the RPi to Flight controller.

In MAVProxy, can you try wp list and fence list and see if you get any output? You don’t need to have any missions or fences loaded in advance.

I’d suggest:

  • Have you checked there’s no other services using the UART on the RPi? Sometimes there’ll be a console service running on there
  • Check the SYSID_ENFORCE parameter is set to 0 on the flight controller.
  • Try using the USB connection on the Flight Controller
13

oh ya, Raspberry pi, @rnjbdya , share your Pi config.txt file.

14

I have a similar setup running Ubuntu on a RasPi. To properly access the serial connection I had to make sure I have access to the serial port

sudo chmod 0660 /dev/ttyS0

and stop the serial getty service

sudo systemctl mask serial-getty@ttyS0.service
sudo systemctl stop serial-getty@ttyS0.service

But since you can receive telemetry, I assume that’s already working for you.

Next thing to make sure sure is that you use the same MAVLink ID in ArduPilot (parameter SYSID_THISMAV) and Pymavlink. Not sure though how to do it in Pymavlink since I use MAVROS.

15

@rnjbdya Have you managed to solve this problem? I think I am in a similar position here.

16

any update on this. same issue on jetson over ip

17

@vinura @heinen

Sorry for late reply.
I was able to get it to work using the USB only but I could not get it to work using the Telemetry port. Now I have moved on to other projects.