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.
Hi @Benja ,
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.
Thank you very much for the help so far!
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)
You can perfectly use ROS 2 Foxy on Ubuntu 20.04
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:
- Use Ubuntu 20.04 with ROS 2 Foxy on Raspberry Pi 4B+
- Update Pixhawk 4 Mini to the latest beta release through QGroundControl (on Windows!)
- Set the
COM_RC_IN_MODEto Stick input disabled through QGroundControl (on Windows!) - Follow the ROS 2 User guide to set up the ROS 2 workspace and build the packages
- Create a new ROS 2 node that sends OffboardControlMode messages (for an example see the Offboard Control example)
- 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.
As I see, if your tracking system provide all this data (Horizontal/Vertical/3D Velocity/Yaw):
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
your local position.
Will turning your PX4 to offboard mode, arming and etc. will simple like taking candy from a baby 
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 
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?