How is MAV_FRAME_LOCAL_NED interpreted, how to use it in precision landing?

I am currently attempting MAVLink assisted precision landing with an aruco marker according to https://docs.px4.io/main/en/advanced_features/precland.html#offboard-positioning. I’m programming in Python using MavSDK. However, it’s unclear to me how to provide the LANDING_TARGET message.

This page says at the bottom that PX4 only supports MAV_FRAME_LOCAL_NED as MAV_FRAME. so, the landing messages have to contain the distance of the marker to the home position in metres?
This sounds very strange to me. In this case, I would only need to measure the distance of the marker and the start position once. In fact, I don’t even need a marker. Not to mention, everything would be down to gps accuracy.

So, what am I misunderstanding here? I didn’t find any example or documentation that made MavSDKs usage of coordinate systems clear to me.

Also, the article on Offboard landing says that only x, y and z are used. So you can’t make the drone achieve a correct yaw position by providing quaternions to the v2 message?

I haven’t used the precision landing before, so unfortunately I can’t help you with most of your questions. But about the landing being in meter, the unit is meter, but since it is a float you can have decimals to have a very high accuracy in the position you send.

The local co-ordinate system is NED which is a North-East-Down co-ordinate system fixed to the earth at the “local home position”. This is the position that the vehicle uses as its reference - so if you got LOCAL_POSITION_NED it would be relative to this position.

My “guess” is that the LANDING_TARGET is provided by whatever knows the position of the target in the local co-ordinate system of the vehicle.

So for example say you had a companion computer set up with a vision system capable of seeing the marker. The companion computer knows the current vehicle position in the local frame from LOCAL_POSITION_NED and can calculate the relative position of the marker to determine its position in the local frame. This would then be put in the LANDING_TARGET and sent to the flight stack.

@dakejahl Is that about right?

@blank-supportgis you’re not crazy, the “Landing Target Protocol” specification is not very good. The requirement for local frame coordinate system is stupid and unnecessary. I’ve worked around this by using the “sitl irlock hack codepath”. The only values that are used are angle_x and angle_y

and then from your linux side you just need to publish the landing_target message as such

	float x = msg->poses[0].position.x;
	float y = msg->poses[0].position.y;
	float z = msg->poses[0].position.z;

	// Convert to unit vector
	float r = sqrtf(x*x + y*y + z*z);
	x = x / r;
	y = y / r;
	z = z / r;

	// https://github.com/PX4/PX4-SITL_gazebo/blob/master/src/gazebo_irlock_plugin.cpp
	float tan_theta_x = x / z;
	float tan_theta_y = y / z;
	mavlink_message_t message;
	mavlink_landing_target_t landing_target = {};

	// X-axis / Y-axis angular offset of the target from the center of the image
	landing_target.angle_x = angle_x;
	landing_target.angle_y = angle_y;

	mavlink_msg_landing_target_encode(AUTOPILOT_SYS_ID, YOUR_COMPONENT_ID, &message, &landing_target);

You’ll need to enable the landing_target_estimator module in PX4. You can test in sim using
make px4_sitl gazebo_iris_irlock

Hope this helps.

@dakejahl So you’re sending the angles between drone and marker and PX4 accepts them? that’s good to know. So the article on offboard landing is wrong in mentioning only x, y and z?
Unfortunately, I’ve got another problem. MAVSDK doesn’t support LANDING_TARGET messages (see my question here). I haven’t yet found an alternative for PX4 in Python that supports it. There are only DroneKit, which is made for ArduPilot, and ROS which is too much work for only one command.

The article is not wrong, but as you’ve identified using the LOCAL_NED frame is inconvenient for a number of reasons. I’d like to amend the Landing Target Protocol eventually to officially support raw sensor measurements from an external source, I just haven’t had the time to do the work upstream.

Take a look at the code, there are only two code paths. The first one is as the article suggests: you need to provide x/y/z/position_valid and use MAV_FRAME_LOCAL_NED. The other path is achieved by simply publishing angle_x and angle_y and enabling the landing_target_estimator module

Regarding mavlink in python, you can use pymavlink. Take a look here for an example using pymavlink