0
$\begingroup$

Using the Mujoco Menagerie model for Crazyflie, I am trying to implement a cascaded PID controller to this model in a MuJoCo simulation. The drone's actuators are symolic, as in they represent thrust, x-moment, y-moment, and z-moment. Right now, I just need the drone to hover at given target location. This implementation is done using ROS2 Humble. The position and quaternion vectors are obtained straight from MuJoCo. From what I understand, the position units in MuJoCo are arbitrary.

My cascaded PID has the following structure: (1) Position PID taking as input the desired position and outputting desired velocity; (2) Velocity PID taking as input the desired velocity and outputting desired attitude; (3) Attitude PID taking as input desired attitude and outputting thrust, x-moment, y-moment, z-moment.

The desired attitude only yields the target roll and target pitch, which are then mapped to the body-frame w.r.t. the yaw angle using the rotation matrix. Then the drone points to wherever it is headed. Given the nature of the actuators, it seems I don't need an Attitude Rate PID Controller.

For now, for close enough distances, the drone manages to go and stabilize there. It does not manage to stay quite exactly at the target location given that it overshoots, which provokes the drone to turn back toward the target and it never quite stays still. Without the yaw angle conversion, it does eventually stay quite still. However, for further distance, the drone goes way too fast and overshoots and eventually becomes unstable. I noticed that this critical distance threshold is inversely proportional to the derivative gain of the velocity PID. I have not yet tuned the gains, just enough to get acceptable behaviour. I noticed that when the target yaw is fixed when the drone comes close to the target, it actually stabilizes for further distances as well.

Is it realistic and achievable to obtain an almost perfect positional controller with just a cascaded PID (a controller that for any distance it manages to fully stabilize itself with negligible error)? If so, is this achieved by tuning gains? If so, how can I tune these gains? From what I understand, I first need a mathematical model of the drone, which I don't have. I believe that this is quite a hassle to derive.

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ Why the negated roll/pitch/yaw commands? That’s purely a coordinate frame sign mismatch. Most likely: MuJoCo’s body x-axis points forward, y left, z up (aircraft convention). Your controller assumes x forward, y right, z up (ROS ENU). $\endgroup$ Commented Nov 8 at 15:29

1 Answer 1

Reset to default
1
$\begingroup$

I don't know why I have to publish the roll,pitch, yaw values negated; it does not work otherwise.

Thats just how the actuator is set. Nothing wrong with that.

If so, is this achieved by tuning gains?

Yes the PID will make it achieve the short targets, without a model it wont be perfect, but pretty close. A drone has a highly non linear behaviour, and a PID wont linearize this. But it will manage to hover or follow close targets. Regarding the overshooting the derivative term of the pid controller looks at how fast the error change (slope of the curve), meaning that when you are far away from your goal, the drone will go really fast to the target, and once you are getting close it will start slowing down, dampening the velocity.

If so, how can I tune these gains?

For tuning a PID controller without any model you have different methods (e.g. Ziegler–Nichols), a fully manual method would be something like:

  1. Start only with Kp (Kp=1; Ki=0; Ki=0).
  2. Slowly increase Kp from small until you get a reasonable response: 2.a. If system responds sluggishly increase Kp. 2.b. If you get oscillations, reduce Kp until oscillations stop.
  3. Set Ki small (0.01 - 0.1), Increase gradually until steady-state error is removed in acceptable time — don’t make it too aggressive or integral windup will cause overshoot.
  4. Add Kd with a small derivative time to reduce overshoot and damp oscillations. If you can set a filter for the derivative would be greate since it will also amplify noise.
  5. Iterate from step 2. (Reduce Kp sliglty if oscilations appear after adding Ki)

Regarding the 3 PID cascade, start first with roll, pitch, yaw tunning. Then the velocity loop, and finally the position loop. Each outer loop sould be slower than the inner loop so they dont fight each other. (your 100Hz and 500Hz timers takes this into account)

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thank you for your answer! As for the tuning, for the inner/attitude loop, I can set the target roll, pitch and yaw to 0 and then tune from there. That is, I can establish a fixed reference. However, for the velocity PID, well that depends on the position PID. Do I also just set a fixed desired velocity and tune from there? Regarding the mathematical model, how complicated can it be to derive it? It seems that quadrotors a pretty standard across design implementations, so surely any mathematical model for a quadrotor would be valid accounting for drone specific specs (like mass etc.)? $\endgroup$ Commented Nov 8 at 21:07
  • $\begingroup$ Do you actually get the velocity as the rate of change from position (like gps changes)? The kinematic model of the quadcopter should be online, and for tunning the desired velocity you would try to get the response close to a step response (going from 0 to 1 for example) $\endgroup$ Commented Nov 8 at 22:46

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.