Precision Moving Landing development status

Hi,

I am currently investigating the development status of the precision landing module, specifically for moving landings and have come up with a few questions for the community.

There is some very interesting work currently ongoing through this PR: Static Vision-based target esitmator (Kalman Filter) #23726. I have done some initial testing with this feature and it works great for static landing pads as it has been designed for.

I have also done some testing with the experimental functionality for moving landing targets. Unfortunately this testing has not given great results and I think it is important to consider how the moving target functionality would be implemented properly one day as the current route is not very clear to me.

The current issue I see with the above PR is that the PrecLand module only provides position setpoints to the navigator module. The way this PR gets around this is by predicting the landing pads position by multiple seconds into the future (default settings). This methodology works well for landing pads moving at a known speed, and with less-noisy sensors as it is essentially tricking the navigator module by providing a “pseudo position + velocity setpoint”, leading the UAV to essentially go to the current position with a velocity vector towards the target.

However, when the target velocity/acceleration predicted by the implemented Kalman filter is also noisy, this “forward prediction” naturally step causes the positional setpoints to be extremely noisy also.

A more sensible way of achieving this would be to add the functionality to provide a position + velocity setpoint, so when descending towards the landing target, the UAV is sent to the exact position above the landing pad, whilst matching the targets predicted velocity as well. This does not feel well placed in the navigator module as there is no support for a position+velocity waypoint type, which led me to finding this PR: Move precision landing from Navigator into Flight Tasks #18973. This PR is aimed at moving the PrecLand module into its own flight task, which is a much better place to be able to set position + velocity setpoints in my opinion.

Is there any reason why PR#18973 has stopped in development? These two developments in conjunction with each other would provide a very robust moving landing pad solution, without having to forward predict the pads position in order to just use position setpoints.

1 Like

I’ve been involved in a number of discussions about precision landing and the loose consensus is that this feature should exist outside of the flight controller firmware. The general direction of development is away from the firmware and towards an integrated MCU+Linux architecture.

So I would suggest building your precision landing software using ROS2 and a custom mode. This example is a good starting point:

Thanks for that reply @dakejahl, I’m interested to know why the general direction of development is away from the firmware? If precision landing support is not developed within the firmware, it means that PX4 is less compatible with precision landing “sensor-only” products does it not? I am working with a sensor that does not have enough compute to run a ROS2 node, and therefore I cannot implement the precision landing software as you have described above! I would have to implement a separate companion computer which is undesirable.

I think seeing as a lot of work has already been done in this area as linked above, it would make sense to me to have a good base-implementation within the firmware, and if other people want to do more complex precision landing software then they should take the route you have suggested above.

What are your feelings on this suggestion?

I’m interested to know why the general direction of development is away from the firmware?

As hardware systems evolve many now include a companion computer by default. It’s a better separation of concerns – the TLDR is that a flight controller should focus on being a flight controller only and higher level control tasks should be delegated to the companion.

But anyway after re-reading your post I do agree with you. Ideally we could feed PX4 a target position/velocity (or have an onboard driver perform this) and the flight task would perform the control. Move precision landing from Navigator into Flight Tasks by potaito · Pull Request #18973 · PX4/PX4-Autopilot · GitHub stalled because navigator is a total CF and it ended up being much harder to decouple than anticipated.

Do you want to try and ressurect this? I’d be happy to help test, we could use my existing offboard precision landing code to instead feed target pos/vel information over uorb. We could also attach the aruco tag to a moving target in the world