Understanding the Controller Structure

Firmware/software/electronics/mechanics
Post Reply
tnecniv
Beginner
Posts: 5
Joined: Fri Jun 07, 2019 3:18 pm

Understanding the Controller Structure

Post by tnecniv » Tue Jul 02, 2019 5:09 pm

Hi all!

I mentioned in a previous post that I'm playing around with the Crazyflie 2.1 for use in an educational setting. For one of the assignments, we want the students to implement an LQR controller to stabilize the quadrotor about the hover state. Since we want to limit the class to primarily be in Python, I determined that the best way to go about this assignment would be for the students to design the LQR controller in simulation using Python and then upload their gains to the Crazyflie for use in an onboard LQR controller that I write in C. Specifically, I am working with a linearization of the model in Mellinger's paper about the hover state and using the Flow Deck for positioning.

I've been digging around the source code and playing with a few things and I have a couple of questions:
  1. It seems that, for both the PID and Mellinger controller, there are a bunch of different modes the user can set that impact the structure of the feedback loop (e.g. the values in the stab_mode_t enum). A cursory search didn't provide me with very much documentation. Is there a reference for these modes, and which should I worry about implementing for my purposes?
  2. To confirm, the first three fields of the control_t struct, which are named roll, pitch, and yaw, are the moments about the three axes and the same as the inputs u_2, u_3, u_4 in the Mellinger paper, not commanded angles or something like that?
  3. Lookinging at state_t, it says that the attitude is given in a legacy CF2 body coordinate system. Is this coordinate system documented anywhere?
Thanks for the help!

As a side note, I've found that with the default gains, the CF2.1 hovers very nicely using the PID controller, but the default Mellinger gains have a lot of drift. Is this typical?



tnecniv
Beginner
Posts: 5
Joined: Fri Jun 07, 2019 3:18 pm

Re: Understanding the Controller Structure

Post by tnecniv » Mon Jul 22, 2019 2:12 pm

I wanted to give this a bump and an update on what I've learned since my original post.

With regards to (1), most of these seem like kinds of failure modes, and I've decided to ignore them in my implementation for now since they seem to not be triggered when I switch to my controller in my tests.

Concerning (2), the thrust field is detailed in this post. However, I still have not been able to figure out the mapping from the body moments (i.e. the inputs in the Mellinger paper) to the roll, pitch, and yaw fields of the control_t struct. This is my main sticking point at the moment and I would appreciate any help I can get here.

For (3), I just followed what is in this source for the Mellinger controller and inverted the pitch variable.

kristoffer
Bitcraze
Posts: 108
Joined: Tue Jun 30, 2015 7:47 am

Re: Understanding the Controller Structure

Post by kristoffer » Tue Jul 23, 2019 10:56 am

Hi!

I'm not an expert on the controllers but I'll give it a go

1. The modeAbs and modeVelocity signals if a setpoint value contains a coordinate or velocity so that the controller knows if it should do position or velocity control. Since your controller mainly is for educational purposes you probably do not have to support both modes.

2. I have not read the Mellinger paper my self so I'm not sure. I will try to find out.

3. I don't know about any documentation but I think the short version is that angles are in degrees and that pitch is inverted.

tnecniv
Beginner
Posts: 5
Joined: Fri Jun 07, 2019 3:18 pm

Re: Understanding the Controller Structure

Post by tnecniv » Tue Jul 23, 2019 6:34 pm

Thanks for the reply kristoffer!

I think I got a bit of a handle on 2 now, but I haven't tested it on the quad yet.

What seems to be happening is in power_distribution_stock.c, equation (2) in the Mellinger paper is being inverted on lines 79-82. However, the coefficients on u_1, ... u_4 from the inversion are assumed to have already been multiplied into the control signal. Theoretically, this puts the units of all the fields of control_t in RPMs ^ 2.

However, as mentioned in the thread I linked in my previous post, the value of the thrust field (and thus the other fields) really corresponds to a PWM duty cycle, not RPMs ^ 2. To remedy this, I used the data from here to find a mapping from RPMs ^ 2 to PWM. Specifically, I fit the function f(x) = c_1 x^2 + c_2 x and found c_1 = -6.1849e-14, c_2 = 1.3357e-04 (as an aside, normally something on the order of 1e-14 could be considered numerical error, but the values of RPMs ^ 2 are quite large so the first term is still non-negligible). Using this mapping, I can put all the control_t fields in PWM units.

Let me know if this makes sense / lines up with what you find. I'll report back if it works on my end! I'm also willing to share my code if you think it would be helpful for debugging purposes.

Unrelated: Is there any reason the thrust field in control_t is a float while the others are int16?

EDIT: Also, if anyone knows good values for the k_f and k_m coefficients in the Mellinger paper, I'd appreciate knowing what you found. I've looked at a few different sources and they seem to be reporting very different orders of magnitude.

kristoffer
Bitcraze
Posts: 108
Joined: Tue Jun 30, 2015 7:47 am

Re: Understanding the Controller Structure

Post by kristoffer » Thu Jul 25, 2019 8:26 am

Sounds reasonable to me
Unrelated: Is there any reason the thrust field in control_t is a float while the others are int16?
Not sure. When something is a bit weird it is usually due to historical reasons

Post Reply