4.1.5: Precision Landing: Very jerky motion after target detection

Hi everyone,

we are using precision landing with an computer running ROS on the ground (video is streamed to the ground, apriltags get detected, we send landing_target messages via Mavros). The copter is running 4.1.5. Generally the setup works.

Following problem happens: When the tag gets detected, the copter will move towards it with it’s maximum lean angle, which results in a very jerky (and scary) motion. Is there any way to improve on it?

Is the actual camera position relevant to the algorithm? It is actually positioned to the front of the Quad, but we want it to land with the camer centered on the tag.

Our PLND settings:

PLND_ACC_P_NSE	2.5
PLND_BUS		-1
PLND_CAM_POS_X	0
PLND_CAM_POS_Y	0
PLND_CAM_POS_Z	0
PLND_ENABLED	1
PLND_EST_TYPE	1
PLND_LAG		0.25
PLND_LAND_OFS_X	0
PLND_LAND_OFS_Y	0
PLND_TYPE		1
PLND_YAW_ALIGN	0

Example Log:

Thanks and kind regards
Raphael

your own code needs to limit the amplitude of it’s outputs. That way the system will not do scary stuff. right now the problem is that your ROS code commands ArduPilot to do scary stuff, and that is the reason it does.

We are sending LANDING_TARGET messages, which is just an information about where the tag is in relation to the quad. Do you mean we should artificially limit the angle of the target in relation to the drone?

yes, that is what I am saying.

Since Arducopter V.3.5 or 3.6, the behaviour of precision landing changed somehow, and this leads to jerky movements with heavy bankings. Especially on large and heavy copters, the behavior is riskfull. During the landing, the copter jerks like in no other (normal) flight situation. This is a known problem (you can find several postings here).
But it seems that no solution for this problem (i.e. limiting the accelerations or banking angles for PL only) has been found till now.

Seems weird to me to artificially limit a sensor (which to me LANDING_TARGET messages are) to prevent this sort of reaction, but if it is the only solution we will do it that way.

Hello,

This is not a sensor, it’s a controller feeding information directly to the EKF so we expect having some form of signal conformity.

You can change the way signal is handled by selecting the EST_TYPE 0:RawSensor, 1:KalmanFilter . From my experience, RAW was easier to tune as the estimator small Kalman Filter has a tendency to induce lag and get the drone overshooting.

I havent looked at log but make sure you have minimal lag (less than 100 msec) and maximum fps (20 -30) for this to work correctly

Thanks for all the tips, after reducing the WPNAV_ACCEL parameter to WPNAV_SPEED/3 and updating to 4.2.0 beta it is much better behaved

1 Like

no it isn’t a ROS issue, it is the PRECLAND code that behave that way on start, on start the further you are from the target, the fastest the correction will be, and do an impressive manoever.