Tuning on a real drone
HenryHuYu opened this issue · 18 comments
Hi, Thanks for the great work. We are now tuning controller on a real drone. (To be more specific is a dji airframe F450). I have some questions and it is so great if you can help.
- Previously we tuned it well in Airsim. But for a real drone things become different. As to my understanding,
g_ * normalized_thrust + thrust_offset = throttle
where such throttle is the hovering one. That means we already have a equation
9.8 * normalized_thrust + thrust_offset = throttle(can be read from px4 log)
and normalized_thrust is something related to battery, frame, motor , esc and mass. And it act like "how much thrust we need to input if we ask for a unit acc(1m/s * s) . So we fit a linear function between thrust and raw_acc from px4 log. Thus we got the 2 parameter normlized thrust and offset.
we got something like:
norm = 0.0346, offset = 0.0581
my question is that is this a right way ? When I run simulation that you provide, the normlized thrust is 0.05 for Iris in Gazebo, but it seems that 9.8 * 0.05 + 0.1 is not the hover state for Iris AirFrame. While I modified the normlized thrust from 0.05 to 0.65, Iris can perfectly track a vertical polynomial trajectory while it cannot track a circle anymore. - We set a polynomial trajectery that have 2 step:
- track a 5 order (c1*t^5 + c2 * t^4....) vertical trajectory(p(0) = 0, v(0) = 0, a (0) = 0, p(2) = 1.5, v(2) = 0, a(2) = 0)
- then we track a same trajectory in X axis.
the Log is as following, Could you please give me some hint on this? Tuned for a long time and cannot find a way out.
Z_X_Traj.zip
Really appreciate your work and hope it can finally work on our drone !
For the log, the parameter is
max_acc_fb = 6.5
Kp_z = 12, Kv_z = 4.1
Kp_x = 9.6 Kv_x = 1.6
Kp_y = 9.6 Kv_y = 1.6
att_tau = 0.1
normalized thrust = 0.0346; thrust_offset = 0.0546
- The iris motor thrust constant has recently changed, but I was unable to tune this package against the latest firmware. You can look at the change in PX4/PX4-SITL_gazebo-classic#584
Therefore, we need to retune the geometric_controller against the changed constants. I would greatly appreciate if you can have a look.
and normalized_thrust is something related to battery, frame, motor , esc and mass. And it act like "how much thrust we need to input if we ask for a unit acc(1m/s * s) . So we fit a linear function between thrust and raw_acc from px4 log. Thus we got the 2 parameter normlized thrust and offset.
This is true and is part of the problem. It is not linear in real life, and it also depends on which ESCs you are using. Normally it will be quadratic, but it is usually okay to assume it is linear around the hover thrust since the operating ranges of the throttle stick is around hover unless you are flying aggressively.
- Could you upload the logs in flight review? This will allow me to view the logs without sitting down on a laptop.
Thanks for your reply. uh it is my bad. the link is https://review.px4.io/plot_app?log=01d5591e-0b4d-43d9-a6ea-e1b31bb41d78
The basic pipeline is that we use a dummy publisher pub to setpoint/local_position/pose to enter the offboard mode. After the UAV enter offboard mode and armed (by subscribe to mavros_msgs/State) we stop the dummy timer, and start the sampling timer to publish sampled flat target in a trajectory publisher, after 2 trajectory ends for some time, we call land srv in mavros.
@HenryHuYu Okay, so you are not using this package? I am a bit confused with the dummy publisher you are mentioning
@HenryHuYu Okay, so you are not using this package?
I am using this package. During the tracking vertical and X axis trajectory part. I was using dummy publisher because in order to enter offboard, we need to publish some setpoint.
The pipeline is:
- dummy publisher (enter offboard and armed)
- mavros controller tracking a vertical trajectory. (The sampling last for 2 seconds and after 2 seconds, trajectory Publisher keep publishing final target
(P(0,0,1.5), vel(0,0,0), acc(0,0,0))for like 5 seconds. - The trajectory publisher start to sample flat target in X axis while keep Z axis unchanged. (The sampling last for 2 seconds and after 2 seconds, trajectory Publisher keep publishing final target
(P(1.5, 0, 1.5), vel(0,0,0), acc(0,0,0))for some seconds
Maybe dummy publisher is not a smart way to enter offboard mode. As I have seen that you mentioned it should be better to publish valid setpoint instead of this dummy one. But logically it currently work, but the tracking trajectory part does not work well.
@HenryHuYu There is already a state machine inside geometric_controller so a dummy publisher is not necessary
@HenryHuYu There is already a state machine inside
geometric_controllerso a dummy publisher is not necessary
Yes, I ve noticed that. Btw, Could you see the log url? I ve already link it above.
@HenryHuYu What is your baudrate on the serial connection between the companion computer? It looks like the oscillation is being commanded, and it is tracking it correctly.
@HenryHuYu What is your baudrate on the serial connection between the companion computer? It looks like the oscillation is being commanded, and it is tracking it correctly.
if I remember correctly, it is 921600
to my understanding , it seems to be Kv_x is too big since it vibrates before it gets to the target position. But kv_x is already set to be 1.8. Kinda confused here. also I noticed that Z is over 1.5m
as the polynomial trajectory set. Is it because Kp_z is too big?
I also upload a video for you. If you have time to have a look. https://www.youtube.com/watch?v=FEhl2XZoCtQ
@HenryHuYu Thanks for the video -
I notices that you are flying indoors - how does your state estimation look? Could it be a time delay on the information that you are using regarding linear velocities/ postion that is causing the oscillations?
@HenryHuYu Thanks for the video -
I notices that you are flying indoors - how does your state estimation look? Could it be a time delay on the information that you are using regarding linear velocities/ postion that is causing the oscillations?
We are using a Intel T265 for state estimation and send to mavros/vision_pose/pose, basically is https://github.com/Auterion/VIO we use a Jetson Xavier Nx as Companion computer and connect it to pixhawk 4 with TEMEM 2.
We tried to tune today as well. We thought it was att_tau is too big and the UAV cannot react to Rerr fastly. And indeed when we tune it from 0.1 to 0.08, things get a little bit better but the oscillation is still obvious. We think it is small enough and stop making it smaller.
We have a log file, a video from rviz and a video for real drone. Really appreciate it if you can help check on it .
Log file https://review.px4.io/plot_app?log=657f07e1-1220-4d36-bc38-9a03161a321a
Rviz video https://www.youtube.com/watch?v=CnSlN9Q4iJ8&feature=youtu.be
Real Drone video https://www.youtube.com/watch?v=dIgNPO5hHfE&feature=youtu.be
I consider your idea about state estimation delay, but I think if it is caused by delay, it should get more far away than the final target position(1.5m). But as you can see in the following picture, (the final target is 1.5m), before it reach 1.5m, it start to get back. And then the Kp_x takes affect and starts to oscillate.
Hi, emm tried again and still didn’t work out. But we find that when the trajectory sample point is something like aref = -1.5. It means that the UAV should speed down at this point and the drone speeds down so fast. thus the difference between real position and sampled position(which is error in position Pe) become large really fast. We Set Kp_x to be 10. But since F450 is a pretty normal airframe. We assume it is not too different from Iris In gazebo. So we mainly tune it around the parameter you offered. Do u think it is possible that Kp_X is too small for this? And it can be something like 20?
Closing as stale, please reopen if this is still an issue @HenryHuYu