Hello Community,
During the experiment, we have some doubts about airborne control, visual positioning, EKF2, etc., and hope you can give us some help.
In the first stage, to check the basic flight capability of the UAV, we took GPS as the locating source and used the remote controller to control the UAV in POSITION mode. It flew smoothly, which verified its basic flight capabilities. Then we tried to use the onboard computer to publish ROS topics to PX4, controlled the UAV to fly autonomously in OFFBOARD mode according to a pre-generated trajectory. It succeeded. But there was a question that the local position Z of UAV was very unstable in this configuration when the UAV was on the ground, it oscillated over a large range of values, which mean that when use onboard computer control, if you want the UAV to reach a specific altitude, you need to add an value of Z positioning error estimated when the UAV is on the ground to the desire altitude, and then send it to PX4, which is very inconvenient. Below are the log files recorded in this stage:
Control the UAV using RC:
Use the onboard computer to control UAV flight with a circular path:
In the first stage, some questions are confusing us:
Q1. Why did the value of local position oscillate when the UAV was on the ground, and why did the degree of numerical oscillation decrease after taking off? (Actually, when we controlled the UAV by a remote controller or computer for fixed altitude flight, the UAV’s altitude was fixed.)
Q2. When PX4 was connected to a computer through micro-USB, sometimes the UAV couldn’t be disarmed. (The GPS indicator light is linked to UAV status. The light is red when the UAV is not ready to fly.) However, when we opened QGC, the light turned green, which means it was ready to fly. Is opening QGC also a necessary part of flight, whether manual control or computer control? What operations does QGC perform to change the state of the UAV?
Q3. When flying using computer control (OFFBOARD mode), we tried to change from offboard mode into position mode by toggling off the offboard switch, but it had no effect. The only way to achieve manual control was to shut down the ROS node that published topics through MAVROS. We couldn’t find the cause of the above problems. We want to know how to change the priority for UAV control.
Q4. There’s a step named PID Tuning. Do the parameters listed inside have an influence on manual control or offboard control? At the beginning, we used autotune to set the parameter, but the UAV kept moving when in STABILIZE mode and had a risk of collision due to the outdoor experiment. (Pilot didn’t push the joystick) So, in the end, we manually adjusted parameters and conducted a manual test flight after each adjustment. Is there any way to autotune outdoors?
Q5. We sent ‘mavros_msgs::PositionTarget’ messages (coordinate_frame = FRAME_LOCAL_NED) to PX4 to control the UAV to track the trajectory. The world frame used in this message was ENU, but the frame used in PX4 was NED referred to officially given document. The actual flight trajectory was consistent with the set trajectory. Is the world frame in similar messages always transformed by MAVROS from ENU to NED automatically?
Q6. After the UAV experienced several uncontrolled crashes, the UAV kept losing altitude after takeoff. We found that although the altitude of the GPS almost remained unchanged, the altitude of EKF2 kept increasing. We also find that there was an error after takeoff in logged messages: [CRITICAL] Accel 0 clipping, not safe to fly! We guess that the altitude accelerometer is destroyed. Is it the real reason? We solve this problem by replacing the PX4. The log files are as below:
After replace:
Additional messages:
1.The version of PX4 firmware is 1.15.4, the version of mavros is 1.20.0, and the autopilot board is Holybro Pixhawk 4.
2. The onboard computer is Jetson Orin NX, and the operating system is Ubuntu 20.04.
3. The camera we used is T265, and the visual positioning algorithm is the camera’s built-in VIO algorithm.
4. The whole experiment is outdoors.