HKPolyU-UAV / qr_mpc

20 stars 3 forks source link

The param for mpc #3

Closed suezere closed 4 months ago

suezere commented 10 months ago

Hi, I ran your code and I noticed that there is a large tracking error when the speed is faster, what should I do to reduce the error? I also found that the value of the matrix q related to u is very large, I think the value of q should be smaller than p, but when I change q to smaller the drone can't be controlled well, why is that?

suezere commented 10 months ago

In the experiment, the hover thrust varies with the charge of the battery, how can this be solved?

Xclaax commented 10 months ago

Hi, I'd like to ask if you're having problems with missing .h files during catkin_make?

RockyJBL commented 10 months ago

To improve the tracking performance, you can try to increase the position weights in Q matrix. However, larger position weight may lead to aggressive or unstable performances when the trajectory is discontionuous (i.e. step response). Another possible reason is that maybe the velocity reference incorrect. You may refer to the python scripts in traj folder for generating reference pathes. The weights for control inputs are relatively large is because that we need to compensate their relatively small scales. Since the thrust is 0~1 and pitch/roll commands are in rad, while the pos&vel tracking errors are in m and m/s. For the hover thrust question, current framework can only treate it as external disturbance, and will result in a tracking offset. This problem can be solved by using a disturbance observer and compensate the loss of thrust force. Or, to measure the thrust model of your system to map the thrust&voltage to lift force and use the model inversion in controller to find proper thrust command.

suezere commented 10 months ago

Thank you for your answer, I have run the python scripts lemniscate.py in gazebo simulation. But I found that his tracking effect is not very good, especially when the speed is fast, how should this be adjusted? Is it necessary to reduce the frequency? If in the model I use the actual thrust instead of the normalized thrust, the weights for control inputs can be relatively small? And I'd like to ask which is more accurate in real experiments using a quaternion-based model or a model like yours. In the trajectory generation part, is it possible to use minimum snap to track the simulation results more accurately?