hello!
I've read the source control code in firmware carefully out of curiosity. When I clicked the position.c I found an roll pid is behind the Vx and the pitch pid is behind the Vy.I think It should be the roll pid that is behind the Vy(so that we can change the Vy and y position through roll maneuver) and a pitch pid is behind the Vy.
I tried to Reappear the control rules in simulink as the same as the firmware's ,but I'm failed.Then I swapped two modules mentioned above,and succeeded.So I want to understand the principle about the pid design in firmware.
Thank you!!
about control rule
Re: about control rule
Hi!
Could you explain your problem a little bit more clearly? What do you mean with Vx and Vy and that the pitch and roll are behind that...
By the way, here is the current defined coordinate system and rotations of the crazyflie, and note that the rotation around the y-axis is actually reversed. But, the roll does affect the acceleration in the y axis, and the pitch affects the acceleration in the x-axis... so at least what I understood from your problem definition, it is actually doing what you say should happen.
There was also somebody that was talking about some unconventionality in the controller and state in this github issue actually for your interest.
Could you explain your problem a little bit more clearly? What do you mean with Vx and Vy and that the pitch and roll are behind that...
By the way, here is the current defined coordinate system and rotations of the crazyflie, and note that the rotation around the y-axis is actually reversed. But, the roll does affect the acceleration in the y axis, and the pitch affects the acceleration in the x-axis... so at least what I understood from your problem definition, it is actually doing what you say should happen.
There was also somebody that was talking about some unconventionality in the controller and state in this github issue actually for your interest.
Re: about control rule
sorry...Maybe I didn't explain it clearly.
Specifically, please look at the following figure, focusing on the connection of attitude PID after speed PID, which puzzles me.
How can it run normally in this case(means a pitch pid is behind the Vx pid)?
Thank you
Specifically, please look at the following figure, focusing on the connection of attitude PID after speed PID, which puzzles me.
How can it run normally in this case(means a pitch pid is behind the Vx pid)?
Thank you
Re: about control rule
Thanks for the picture!
Actually the 'normal' pid control scheme does not seem logical to me. Even though we have a slightly different coordinate system than usual aerospace convention, the x-axis is always forward and the y axis is always to the side of the aircraft.
The roll is the rotation around the x axis (so rolling from side to side), which causes a linear movement in the Y-axis due to the quadcopter dynamics, and the pitch is a rotation around the y-axis (nose pointing down or up), which causes a linear movement in the x-axis.
This is a blogpost that might be interesting btw: https://www.bitcraze.io/2018/11/demysti ... -dynamics/
Actually the 'normal' pid control scheme does not seem logical to me. Even though we have a slightly different coordinate system than usual aerospace convention, the x-axis is always forward and the y axis is always to the side of the aircraft.
The roll is the rotation around the x axis (so rolling from side to side), which causes a linear movement in the Y-axis due to the quadcopter dynamics, and the pitch is a rotation around the y-axis (nose pointing down or up), which causes a linear movement in the x-axis.
This is a blogpost that might be interesting btw: https://www.bitcraze.io/2018/11/demysti ... -dynamics/
Re: about control rule
Oh wait I'm so sorry! You are absolutely right! I didn't see that the rolll and pitch were flipped in your picture.
Yes the normal should be correct. and indeed in the code it shows that it's depended on the x velocity but according to the state definition the state velocity in the global coordinate: https://www.bitcraze.io/documentation/r ... teestimate, not in the body fixed frame system, so somewhere it gets rotated the right way some how, or else it can't fly.
Thanks for notifying us. We need to take a whole long look to fix the overall control framework of the crazyflie... it's long overdue and it's even confusing to me apparently
Yes the normal should be correct. and indeed in the code it shows that it's depended on the x velocity but according to the state definition the state velocity in the global coordinate: https://www.bitcraze.io/documentation/r ... teestimate, not in the body fixed frame system, so somewhere it gets rotated the right way some how, or else it can't fly.
Thanks for notifying us. We need to take a whole long look to fix the overall control framework of the crazyflie... it's long overdue and it's even confusing to me apparently
Re: about control rule
So currently we are in the works of this PR: https://github.com/bitcraze/crazyflie-firmware/pull/885 . This will cause the PID controller to act and be tuned from the body fixed coordinated system instead of the global one. So that should make the structure way more logical also according to your drawing.
And yes, looking at the current code, these lines are very obscure and paint a wrong picture. RawPitch and rawRoll are actually not the 'real' crazyflie's roll and pitch but the global coordinate system (and technically it the naming should have been switch in order to be logical) but get rotated to the body fixed coordinate back the right way here.
Anyway, check out the PR commits and comment on that if that makes more sense to you!
And yes, looking at the current code, these lines are very obscure and paint a wrong picture. RawPitch and rawRoll are actually not the 'real' crazyflie's roll and pitch but the global coordinate system (and technically it the naming should have been switch in order to be logical) but get rotated to the body fixed coordinate back the right way here.
Anyway, check out the PR commits and comment on that if that makes more sense to you!