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.