Cannot arm drone with companion computer: "Arming denied! manual control lost"

Okay, I will try with the new bridge on monday and update how that goes!

Okay I just tested with QGroundControl on Windows, and I could set the COM_RC_IN_MODE parameter just fine, so it’s a problem with the linux version of QGroundControl. I have now set the parameter to the value 4, but I I have the problem that radio setup needs to be done (Detected 0 radio channels. To operate PX4, you need at least 5 channels.).

I remember disabling this check with setting the COM_RC_IN_MODE parameter to 1, but now that it’s changed it won’t arm without a radio connection. As I said earlier, I’m not going to use a radio as I want to control the drone fully through the raspberry Pi. Is there a way to disable radio checks and also set the COM_RC_IN_MODE parameter to 4?

Okay, another update: I finally managed to arm the drone, but after a few seconds it gets disarmed.
The steps I took were as follows:

  1. Use Ubuntu 20.04 with ROS 2 Foxy on Raspberry Pi 4B+
  2. Update Pixhawk 4 Mini to the latest beta release through QGroundControl (on Windows!)
  3. Set the COM_RC_IN_MODE to Stick input disabled through QGroundControl (on Windows!)
  4. Follow the ROS 2 User guide to set up the ROS 2 workspace and build the packages
  5. Create a new ROS 2 node that sends OffboardControlMode messages (for an example see the Offboard Control example)
  6. Arm through QGroundControl

The log from the pixhawk can be found here. It looks like the pixhawk (or the connection to the pixhawk) restarts every few seconds, which triggers a failsafe. If you want, I also have the log of the MicroXRCE-DDS agent. Do you have any idea why the failsafe triggered?

(If this is off-topic, please let me know, and I will make a new topic for this particular problem.)

Hi!

You said:

have a raspberry Pi connected to the pixhawk, which reads location data from a beacon-based indoor tracking system

but in your log all position are invalid. Did you realy feeded local data from tracking system to PX4?

Because it look like…

Also you didn’t send any setpoint, if setpoint don’t comming for few seconds offboardmode will be denided.

What in your param EKF2_AID_MASK?
It shoud be 24.

Hello, I am currently in the beginning stages of my project. I have not yet set up the beacon positioning system, and want to be able to control the pixhawk through the raspberry pi first. I have made a ROS 2 node that sends the offboardcontrol messages as a heartbeat, and another that sends a random vehicle attitude setpoint. The log of this can be found here. With this setup I was able to successfully arm the drone and make the motors spin using setpoints. I will try more when I understand how the setpoints work, after which I will try to make the drone fly.

Also, could you explain a bit more about what the EKF2_AID_MASK parameter does? In the documentation that’s deprecated, and setting it to 24 would mean setting the newer EKF2_EV_CTRL to a value of 3, which corresponds to Yaw sensor aiding, but I can’t really find what that means.

Ok.
In my PX4 no EKF2_EV_CTRL, but EKF2_AID_MASK is.

Default EKF2_AID_MASK - “1” it’s mean PX4 use only GPS. But if I want to use external tracking system without GPS, I must set mask=24 - don’t use gps, and use vision position, and vision yaw, because indoor internal magnetometer is bad.
image

As I see, if your tracking system provide all this data (Horizontal/Vertical/3D Velocity/Yaw):
image
Your EKF2_EV_CTRL will be “15”
And GPS_1_CONFIG = Disable.

You should send this data to your PX4 by mavlink_msg_vision_position_estimate_pack (don’t know how it’s look like in ROS2). IMHO from it shuod begin. After you will see in QGC
image
your local position.

Will turning your PX4 to offboard mode, arming and etc. will simple like taking candy from a baby :grin:

1 Like

That’s great, I will definitely use that, thanks for the info!

1 Like

Hi @SemvdH
Try this combination

COM_RCL_EXCEPT = 5
COM_RC_IN_MODE = 4

COM_RCL_EXCEPT controls for which modes you can loose RC without triggering any failsafe

1 Like

@Artem_Borisov you are mixing information valid for v1.13 (EKF2_AID_MASK) and information valid for the upcoming release and the beta (EKF2_EV_CTRL).

1 Like

That’s great @SemvdH
Well yes, now you are going a bit off topics. Nevertheless, you are using the XRCE-DDS bridge over serial port with just 57600 as baudrate. That’s too low. Try increasing it as much as you can before it become unstable. In this way you will fix the

RTT too high for timesync

warnings and the reconnections.

Regarding how to provide EV data, if you are still experiencing issues please open a new topic :mechanical_arm:

I will try that, thank you!

That sounds like a good idea, I will try that as well.

Thank you very much for your help!

UPDATE: increasing the baud rate indeed solved the reconnecting and RTT too high for timesync issues! I have it set to 921600 and it works perfectly fine.

1 Like

Hi guys,

I tried everything mentioned in this post,

setting

COM_RCL_EXCEPT = 5
COM_RC_IN_MODE = 4

using high baud rate (921600), connecting the Raspberry Pi 4B to the Pixhawk (6c) using Telem 2,
I was able to read the gyro and accelerometer measurements.

but when I tried the Offboard Control example , nothing is happening all I get is this :
ros2 run px4_ros_com offboard_control
Starting offboard control node…
[INFO] [1682689773.044855171] [offboard_control]: Arm command send

I am connecting the PWM model to the pixhwak using (I/O FMU Out)

do you have any advise for me ??

Hi, could you explain a bit more about what you mean by connecting the PWM model to the pixhawk using the FMU out? I’m not sure what you mean by that. Also, are you using PX4 v1.14 beta and ROS 2 Foxy?

With Pixhawk 6c the flight controller module doesn’t have input or output pins for the PWM, they come as a separate modules ( 2 modules ).
So I contacted the motors to the PWM module and the PWM module is contacted to the Pixhawk 6c board through I/O contaction. You can have a look at the attached picture
image_CMhvxIkcZn~2

And I am using ROS foxy and PX4 v1.14 beta,

I checked the logs and I am having erros related to SD card and Magnetic field interference.

Also I want to add that I am connecting the Raspberry PI to the Pixhawk using FTDI cable contacted to TELM 2.

I just want to know how did you arm the quadcopter

I see, I didn’t know that was the case. Did you already test if the pixhawk can control the motors on its own? I tried this with the motor_test command (in QGroundControl → analyse tools → mavlink console).

Maybe you can try formatting the SD card again? What size SD card do you use? Also, for the interference, did you calibrate the sensors through QGroundControl?

Did you establish communication through the XRCE-DDS bridge? I first checked to see if communication was possible using mavproxy to check if the physical connection is working (I used this video). Then I tried using the bridge. Also make sure you set the parameters for xrce-dds correctly.

I formatted the SD card, and still having the messages:

  1. Preflight Fail: Yaw estimate error
  2. Strong magnetic interference

I will post this issue in the forum with more details, hopefully someone faced the same issue.

Okay, could you post a link to the new issue?

Here is the link

And I would like to thank you for following up with me

Hi,

I just want to confirm something from you:
in this test

https://logs.px4.io/plot_app?log=ab3766ea-b0c1-49f3-a3b2-6e4e7873f38f

you are using indoor positioning system like Super-Beacon
and a M8N GPS model (to make use of the campus).

because I am trying the Off-board mode from the PX4 website, and the drone is not arming,
and I don’t have any positioning system, I am depending on the barometer to estimated the altitude only

In that log I’m not using the beacon positioning yet, have you set COM_RC_IN_MODE to 4, COM_RCL_EXCEPT to 5 and COM_ARM_WO_GPS to 1?

Does the drone arm using the ROS 2 offboard example? If not, what error message are you getting?

Also, a little update to my drone project, I ended up ordering a GPS anyway because I wanted to fly using velocity and position control, and because the robot positioning system does not work as well as we expected.Today the GPS arrived and I will test it