I have a hexarotor x drone with a Pixhawk 4 Mini. I have connected a Raspberry Pi 4B+ to the pixhawk through the TELEM1 port. I do not have an RC remote and no GPS connected. I have set the COM_ARM_WO_GPS parameter to 1 and the COM_RC_IN_MODE parameter to Joystick/No RC Check.
When I want to arm the drone in QGroundControl, in the overview it says pre-flight checks: Error, and when I try to arm the drone, I get the message Arming denied! manual control lost and a pop-up saying MAV_CMD_COMPONENT_ARM_DISARM command temporarily rejected. When I try to arm the drone through MAVproxy I get the error Got COMMAND_ACK: COMPONENT_ARM_DISARM: TEMPORARILY_REJECTED AP: Arming denied! manual control lost. Also, when I try to change the mode to Offboard I get the error Got COMMAND_ACK: DO_SET_MODE: TEMPORARILY_REJECTED in MAVproxy.
It seems the pixhawk doesn’t want to arm, but I have no idea why. Can anybody help me with this?
Hello, I don’t speak french, so I google translated your response, and it seems you say you moved the GPS further away from the other electronics, which solved your issue? I don’t plan on using a GPS and thus have set the COM_ARM_WO_GPS variable to 1, which should allow me to arm the drone without GPS.
To writte in english is not quite eaysy for me. Anyway, my problem was having moved the GPS. nothing else. So it dosn’t the same case that yours. Sorry. I think there is another variable that allow you to override arming condition. It seems that i saw it somewhere. But ??
Hi @SemvdH , which px4 version are you using?
There are 5 possibilities for COM_RC_IN_MODE, Joystick/No RC Check does not match with any of them, which one did you try? If you don’t want any kind of RC or joystick, you need to set it to value 5 “stick input disabled”.
Moreover, in which mode are you trying to arm? You cannot arm in a mode that requires RC o joystick input
I am using PX4 v1.13.3 (the latest stable version in GQC)
I think it is mode 1, but I didn’t know about setting the value to 5, I will try tomorrow, since I will have the drone then (it’s at work right now).
I usually start in manual or guided flight mode. Do those require RC input? Also, when I try to switch to, for example, OFFBOARD mode through MAVProxy, the operation also gets rejected.
I will try your suggestions tomorrow and answer again, thank you very much for the help!
EDIT: I just read the flight modes overview documentation and the Offboard mode requires no RC input but it does require a position fix. I have no GPS connected and am not intending to use a GPS (but a beacon based positioning system), is it enough to only have set the COM_ARM_WO_GPS parameter?
Hi @Benja ,
I tried to set the COM_RC_IN_MODE to value 4, which is (according to the parameter reference) the mode to disable stick input. However, I get the error “value must be within 0 and 2”. Do you know how I can change it?
Hi @Benja , I didn’t solve the issue yet. I set the COM_RC_IN_MODE to 4 (by forcing it through QGroundcontrol) and when I request the parameters through mavproxy I can see the value is indeed 4, but when I try to arm the pixhawk or set it in offboard mode, it still gets rejected. Are there any other parameters I should change? I already set COM_ARM_WO_GPS to 1.
Let me see if I understood correctly.
You want to fly without RC / Joystick in OFFBOARD mode without GPS in v1.13.
I tested on v1.13 and the latest QGC, I can change COM_RC_IN_MODE to Stick input disabled (4) without issues (in simulation), I can’t see now why it gives you that error.
You cannot arm in a mode that requires manual control without manual control. But you can use offboard. I’m not really into offboard control from mavlink commands but in general terms you need to send the offboard setpoins, and as you don’t have position estimate (neither GPS, not external vision), you must use attitude setpoints Offboard Mode | PX4 User Guide : SET_ATTITUDE_TARGET
Then you will be able to switch to offboard mode and the arm.
note that v1.13 and main differ quite a lot regarding offboard mode: in v1.13 you need to send the setpoints before changing mode to offboard, while in main you can change mode anytime (as long as you are in disarmed state) and then you can arm only if the setpoints are provided. Nevetheless, position estimate is required only if you want to control it (the docs has been updated in main), therefore you can use offboard + attitude setpoints without position estimate.
You are correct. I have a raspberry Pi connected to the pixhawk, which reads location data from a beacon-based indoor tracking system (Terabee Robot Positioning System).
I want to control the pixhawk based on that location data and commands sent from the raspberry pi through ROS2 with the PX4-ROS2 bridge. For now I am using mavproxy to test sending commands from the raspberry pi.
I’m using PX4 v1.13.3, not v1.13. Could this be a problem? I will try to use v1.13 and see if that changes anything.
As for the difference between v1.13 and main, does that also include the release/1.13 branch?
Thank you very much for the help and I will update as soon as I can.
As for the problem with QGroundControl and not being able to set the COM_RC_IN_MODE parameter, I can not seem to get it to accept the value. I tried flashing the v1.13.3 px4_fmu-v5_default.px4 and px4_fmu-v5_rtps.px4 firmwares from the release/v1.13 branch and also the v1.14-beta2 and v1.13 firmware, but I still get the error that the value has to be between 0 and 2:
Because of this, I get another error in QGroundControl saying I need to complete the radio checks.
I also tried v4.0.0 and v4.1.5 of QGroundControl, instead of v4.1.7, which also didn’t change anything.
I am pretty much at a loss for how to fix this, in all the documentation I should be able to just set the value. I will try sending attitude checkpoints next
Did you try the latest stable: v4.2.6 ? EDIT: I just tried v4.1.7 and I was able to replicate your issue. Therefore it is just a QGC version problem.
v1.13.3 is the latest stable, the one that you should use.
v1.13 and main are quite different right now as we are almost releasing v1.14. release/1.13 is the branch where the major bugfixes (or things like new board support) for v1.13.x are pushed. Every one in a while new tags are created from that branch, the next one will be v1.13.4
FYI, If you want to use ROS 2 with PX4, I suggest you to look into the new bridge ROS 2 | PX4 User Guide (main) . However, this new feature is only available starting from the beta versions of v1.14 . The latest is GitHub - PX4/PX4-Autopilot at v1.14.0-beta2
I did, but I get an error when trying to launch on my computer running linux, which is an active bug. I might try it on my Windows PC and see if that changes anything.
I already tried that with Ubuntu 22 and ROS 2 Humble, but it gave me errors during compilation that I didn’t have with the v1.13.3 version. If I cannot get it to work with v1.13.3, I will try again with the new version and with the new bridge. Would you recommend using the beta version?
Right now I have the bridge with v1.13.3 working, apart from the same issue as described in this post, where I cannot receive any data. There, the person with the issue compiled ROS 2 from source, but I don’t see the point of doing that in my case.
My course of action right now is to try QGC on a Windows PC to see if I can properly change the COM_RC_IN_MODE parameter and if I can get the pixhawk to arm, and if that doesn’t work I will try with sending attitude setpoints first. I will also try the new bridge, but can that also run on Ubuntu 20 with ROS 2 Foxy? I already tried with Ubuntu 22 and ROS 2 Humble, but that didn’t work. Unfortunately the drone is at work right now, so I will only be able to test next week. I will update if I make any progress.
The new bridge is way better than micrortps, however you must be careful when trying v1.14-beta2 as it contains a lot of new features (like the new failsafe management and the control allocation)
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?
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.)
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.
