I use firmware version 4.4.1 and send the target address to ardupilot every 50ms in Guided mode. This is a simple ascent and descent test. After takeoff, it flies from 2 meters to 52 meters and back to 2 meters, but the actual flight of the aircraft There is a lot of time lag between altitude and target altitude. In the log screenshot, GUIP.pz is more than 3 seconds ahead of CTUN.DAlt. The aircraft’s maximum ascent speed is set to 5m/s, but it has not actually reached this speed. How should I adjust the parameters or send Only in this way can we reduce the delay as much as possible. Thank you all.
WPNAV_SPEED_DN=500, WPNAV_ACCEL_Z=150, PSC_POSZ_P, PSC_VELZ_P, etc. have been adjusted but it seems to have little effect on the delay.
Have the pid gains been tuned like explained in the documentation?
The PID has been adjusted. The hovering and flying of the aircraft are relatively stable. The aircraft is fixed with RTK. What are the parameters related to delay and PID? I will adjust it carefully. Thank you.
That is just not good enough. The vehicle must be VERY stable and responsive. Only after that can you make it go faster in a safe way.
Post a .bin log file.
1 Like
Some errors occurred during the flight, which may be related to the radical parameter PSC_ or WPNAV_ settings. If you have any suggestions in this regard, please provide them.
The delay problem is similar to the phenomenon in the post below. It may be caused by the shaping when calling AC_PosControl::input_pos_xyz. Modifying the radical jerk and acceleration parameters will improve it, but the delay will always exist. There is something inside the function call shape_pos_vel_accel. Time constraints, not sure if this is the cause
I’m looking into resolving a similiar problem, though in the XY direction. I’m not entirely sure “it’s your PIDs” is the answer. Let’s assume if people are asking questions on such advanced topics, they’ve done the initial tune and auto-tunes to the nth degree. There appear to be multiple linked parameters that have effects on the drone’s ability to get to the position commanded. I feel like I’m playing whack-a-mole to get the right mix; there has to be a better way.
You called out a few parameters @zleo, but don’t forget MOT_THRST_EXPO and PSC_JERK* and WPNAV_JERK. Also, there are some GPS/RTK related params in EKF3, such as EK3_VELD_M_NSE and EK3_ALT_M_NSE that give more weighting to the GPS, which makes sense if using RTK.
It would be nice to hear from @tridge @Leonardthall @andyp1per and other experts on the key params that effect guided mode positioning.
The very best way to avoid playing whack-a-mole is to use a Method.
That will not answer the questions you posted, but it will reduce the whack-a-mole to zero.
And once that is done you can confidently start playing with JERK and M_NSE parameters.
1 Like
Thank you for putting together that thorough setup guide. I am personally beyond that.
The delay is typically caused by low values of VEL, ACC and JERK in the position or waypoint controller - you need to tell the controller how fast you want it to get to the target. So for instance for fast missions I set
WPNAV_ACCEL,2000
WPNAV_JERK,40
in order for
WPNAV_SPEED,3000
to be of any use. See:
Similar concerns apply to PSC* values
1 Like
Thank you Andy. It’s nice seeing such high values that I wouldn’t have normally thought to try.
In guided mode, what takes priority, WPNAV* or PSC? Seems like both sections have similar params, such as JERK and ACCEL.
This is something that people often don’t understand. There are some basic kinematic limits to how something can respond to your command. To try to explain this I will use two examples.
- We provide a target position moving at 10 m/s.
- We provide a target position moving at 10 m/s and a matching velocity at 10 m/s.
In the case of 1 there is nothing in the message that tells the aircraft that the next position command will still be moving at 10 m/s so the aircraft must assume that it is a stationary target it is heading towards and set the speed under the assumption that the aircraft wants to stop at the commanded position. This means the aircraft always lags behind a moving target position.
In the case of 2 the aircraft knows the target position is moving because you have also provided a target velocity. In this case the aircraft can stay right on top of the target position. However, if you change your velocity we see a position and velocity error until you get back to a constant velocity where the errors will disappear again. So if you suddenly stop you will overshoot the target stopping point and then move back to the expected position.
We also provide the ability to provide acceleration commands to solve the problems in 2. So why not just provide position, velocity and acceleration in the command? This is because you then have to generate a kinematically consistent set of commands. This takes effort and is often not required for the application. So you get to decide how precise you want your control to be. The more precise you require the control the more effort you need to put into generating the kinematic set point.
4 Likes