Anyone here experienced with controlling drones?🤯

[See71]

1. What is the correct procedure to start a drone?
2. The drone is able to accurately receive its current position data and calculate the corresponding PID control output.
3. However, I did all of this while the drone was still connected to Betaflight, so I could monitor the receiver channel values.
4. Then I manually moved the drone and observed the receiver channel values again.
5. However, the behavior doesn't seem right — the channel values are unusually high, and I'm hesitant to attempt a real flight.
6. I’d really appreciate any insights or suggestions you might have.🙏🙏🤝

[Luo-ouL]

First, determine the drone’s flight mode—whether it's hover mode or trajectory tracking mode. The principle behind trajectory tracking is essentially hovering at each waypoint in sequence, so during early stages of debugging, it’s fine to focus solely on hover mode.

The logic of hover mode works like this: the drone continuously receives position and velocity data. Then, we send it the desired hover position once and arm the drone. Once armed, the drone starts up, and the PID controller kicks in. The position and velocity data serve as the PID inputs, and the controller outputs an “acceleration value” in the range of -1 to 1. This value is then scaled (multiplied by 811 and offset by 992) to generate the channel values observed in Betaflight. (Note: Betaflight’s midpoint is 1000, so there might be minor differences.) Normally, the PID controller gradually adjusts the output until the drone stabilizes and hovers steadily at the target point.

If the channel values are too high, there could be a few possible reasons:
1.The drone's current position is too far from the target hover point.
2.The PID parameters are not well-tuned—for instance, the proportional gain k might be too large.
3.The positioning data is inaccurate.

Roughly speaking, if we only consider the proportional term of the PID controller (which dominates during initial response), the channel value is proportional to k × error, which explains the first two issues. Also, I suggest carefully checking your positioning accuracy, because reliable positioning is the foundation for stable hovering.

Here are a few debugging tips:
1.Add some print statements in the callback functions and connect the drone’s ESP32 to your computer. Use a serial monitor to observe the printed values like position, velocity, and setpoint in real time.
2.Output the raw positioning data and carefully verify whether the positioning is truly accurate, not just seemingly accurate.
3.Try commenting out the “ground effect” compensation code temporarily—I vaguely remember disabling it during my early testing phases.
4.You can also try holding the drone in your hand and arming it to see if the motors spin up. As long as you can disarm it at any time, this should be safe for testing. I recall that Betaflight requires quite a few conditions to be satisfied before arming is allowed.

You're very close to achieving stable hover—wishing you the best of luck!

[See71]

Thanks a lot for your guidance! Now my drone can actually take off, but it's quite unstable — tuning the PID is really difficult. Also, I wanted to ask: is a PID update frequency of 2000 Hz appropriate? My actual image frame rate is around 70 FPS, so I adjusted the PID sampling frequency to 100 Hz. I've learned the basics of PID control so far.
Huge respect to anyone who can make a drone fly smoothly — that’s some serious skill!👍👍👍👍👍

[Luo-ouL]

I'm using a 2000Hz sampling rate and haven't run into any issues. A higher sampling rate is generally a good thing.

[See71]

I changed the PID to 2000Hz, and it really works well.
It's really hard to tune.