Why deprecated?

[kripper]

1. Can you please explain why this project is deprecated?
   Any suggested alternative?
   I see it is still used by Maverick.

2. which visual simulator are you using? Gazebo?
   I wrote a simple MAVLink Aruco gstreamer Python based simulator in case you are interested.

3. there is a bug in the logger queue: Entries are cleared before being processed, so the "init completed" message is ignored when the initial log entries are more than 10 (happens when gstreamer outputs some initialization warnings). You probably already noticed it, because you tried to solve it with a mutex (commented code).

I'm the current maintainer of RosettaDrone and we are looking forward to contribute to a robust visual precision landing opensource project.

[kripper]

Ok, I saw your comments in other issue, but would still like to know the current updated status.

BTW, tonight I was thinking in modifying your code to:

• keep a cache of last drone positions indexed by timestamp
• calculate the timestamp when the processed image was captured (delays)
• use this info to calculate the corrected position of the markers (relative to where the drone was at the time the image was captured)
• extrapolate the future position of the markers (consider the target could be moving)
• move the drone considering the future position of the marker

[kripper]

Should we better work with Ardupilot's prec landing code?
For our use case, it would be ideal to work with code that is independent from other stuff we don't need.
As an alternative, we could write some kind of facade to take the precision landing code only.
What about your Maverick project? Maybe you could also be interested in something like this, ie. a wrapper or facade to reference upstream's ardupilot prec landing code so we can contribute directly upstream.

[kripper]

Should we better work with Ardupilot's prec landing code?

I checked Ardupilot's code and didn't find any visual landing algorithms. Just found irlock support and a basic Python example script for aruco detection.

It seems like this repo (vision landing) is the right place to contribute.

Or is there any ardupilot fork with work in progress?

[kripper]

I'm switching to Apriltag.

Please let's merge projects:
chobitsfan/apriltag_plnd#1

[fnoop]

Hi, I am still alive but haven't been involved with drones for a while :)
In a nutshell:

• Ardupilot precland is the autopilot side of the code - it deals with taking in sensor output (or output from a companion computer in this case), translating the fiducial marker 2d camera marker angles into 3d position from the drone pose.
• This project (vision_landing) deals with taking vision input, processing the input, finding the markers, outputting the angles in a manner expected by Ardupilot over mavlink.
• So they are two halves of the same problem - they both need to exist to solve the problem of precision landing.
• The project as you've seen is a mishmash of python and c++. The reason for this was actually that it was originally a tech experiment/demo to interface c++ with the arudpilot python dronekit - this was something that a number of people at the time were looking for, in order to interface opencv and other projects to dronekit.
• In retrospect it was a mistake in terms of the particular goal of vision_landing. Python alone would probably suffice just fine, and would have been significantly simpler, and probably fast enough.
• chobitsfan approach is quite a different approach, more similar to px4 approach.
• There are significant challenges outside of just sending a position - timings, latencies, filtering, higher level processing, user interface, support lots of different devices and image capture methods, etc etc
• There was a particular PR to solve a vital issue that never got implemented and I had been trying to get this resolved for so long that I basically gave up and moved on with life at that point..

I have very little time currently but I'll try and go through the various issues and forum threads and add comment/add notes here for you to follow. The warning at this top of this project is a little dramatic but it was to stop random people crashing/chopping fingers off. It certainly has worked very well for numerous people.

[kripper]

Hi @fnoop,

• There was a particular PR to solve a vital issue that never got implemented and I had been trying to get this resolved for so long that I basically gave up and moved on with life at that point..

Which PR or issue was that?

Ok, we have a similar warning on RosetaDrone so people don't cry and blame us.

I'm already familiar with all the vision landing code base.

I just integrated AprilTag into track_targets and I'm testing it now.
I will also modify track_targets to 1) handle multiple detected markers at the same time and 2) compute a common landing target relative to all markers.

I decided to work on vision landing instead of starting a new project from scratch and also contacted @chobitsfan because I want to bring both communities and individual efforts together into one single evolving project.

Do you think you will continue playing with drones in the short term?
If you will be away for some time I would be happy to keep the vision landing project alive and release a new version with improvements, close issues and try to attract more people like I have been doing on RosettaDrone.

[fnoop]

This forum thread tracked my efforts at the time:
https://discuss.ardupilot.org/t/ac-precland-improvements-and-updates/31614

This is the outstanding PR:
ArduPilot/ardupilot#9020
It's very important, because you will always have varying latencies in embedded lower power computers when processing the incoming images. Without reliable latency correction, there will always be dangerous results (nickname psycho wasp for the dangerous moves that result).

I'd love to get back into my drones, I have all my kit in the garage. It's been a few years since I've flown anything will take me a couple of weeks to get stuff rebuilt and tested. It would also be great to update it and would welcome any input and efforts :)

[kripper]

Merge is ready. I'm doing tests before releasing.

I also started addressing the latency drift you described.
In our case, we will also have to implement the motion control on our own:
RosettaDrone/rosettadrone#132

Please comment there.

[kripper]

Here is the result:
https://github.com/kripper/vision-landing-2/