Control question

Haijie

New Member
Hello,
I have a general questions about the trajectory control of quadcopter. Suppose we have a ground station which can send the control command to quadcopter and all accurate feeback data. For a specific trajectory, by using PID, we can get a position error [x_e, y_e, z_e]', further, we can get three desired control input in drone body frame [u_x,u_y,u_z]'. Then based on some equations, we can get the control input in world frame [T, phi,theta,psi], which are desired thrust, roll, pitch and yaw (suppose psi=0 all the time). Then we can calculate the desired torque based on [tau_x, tau_y, tau_z]. Finally, the desired rotor speed can be generated based on [T,tau_x,tau_y,tau_z].
However, the control inputs sent from the ground station are just [thrust, roll, pitch, yaw_rate]. Then for the above calculation, after we get the [T, phi, theta, psi], we need another PID controller to control the roll, pitch and yaw. Then the control inputs are [T, roll, pitch, yaw_rate]=[T, PID(phi), PID(theta), PID(psi)].
Is my understanding correct?
Thanks
 
Uh, what? I am not an engineer, so I have no idea what all you're talking about. I can boil water, make coffee, fry an egg and fly my quadcopter. That's all I care about.
 
Suppose we have a ground station which can send the control command to quadcopter and all accurate feeback data.
Why do you want a ground control station, (major Tom) step into the millennium & buy a portable transmitter.
It's a little hand held device that can do what cape canaveral did 60 years ago.
I can write basic program, but who uses DOS anymore. I only used cli commands to change a few settings on some old boards. But now you don't have to.
I don't get all that filtering & black box.
It's too deep. I just like to fly so PIDS & rates is enough. But Hey whatever floats your boat.
 
I have a general questions about the trajectory control of quadcopter.

It's an interesting concept, but not quite a simply put as you propose.
Your data parsing is fine, but you presume the availability of said data for the feedback loop on PID controlling the TX commands, and that is
actually a closed loop internal to the flight controller, unless you mean GPS data acquisition and processing via a PID loop to alter TX commands.
If you're using a home-brewed FC (Arduino comes to mind) THEN you could port that data to some peripheral processor used in conjunction with
the TX to enable duplex coms and establish the reactive and corrective control needed for such controlled flight, but the bandwidth would likely be
higher than the typical TX could readily handle. Of course all this presumes the desired level of control you indicate with your formulations, and there
are already quads out there that follow preset courses, by rather crude methods, without nearly that level of complexity.
I suppose one could even hack an FC rather than custom building one and have onboard co-processing capability (thus alleviating the duplex
communication requirement) but that's a level of engineering and programming beyond the norms of this forum. ;)
 
Last edited:
It's an interesting concept, but not quite a simply put as you propose.
Your data parsing is fine, but you presume the availability of said data for the feedback loop on PID controlling the TX commands, and that is
actually a closed loop internal to the flight controller, unless you mean GPS data acquisition and processing via a PID loop to alter TX commands.
If you're using a home-brewed FC (Arduino comes to mind) THEN you could port that data to some peripheral processor used in conjunction with
the TX to enable duplex coms and establish the reactive and corrective control needed for such controlled flight, but the bandwidth would likely be
higher than the typical TX could readily handle. Of course all this presumes the desired level of control you indicate with your formulations, and there
are already quads out there that follow preset courses, by rather crude methods, without nearly that level of complexity.
I suppose one could even hack an FC rather than custom building one and have onboard co-processing capability (thus alleviating the duplex
communication requirement) but that's a level of engineering and programming beyond the norms of this forum. ;)

What he said.......................:confused:
 
Back
Top