Interest in becoming a Maintainer

[Russi1555]

Hello,

I saw the README and would be glad to help where I can.

I have been programming in Python since around 2018/2019 and have gained considerable experience over the last few years in college. For the past three years, I have worked with drones and drone simulation, using DroneKit to test various pilot-interface functionalities. Therefore, maintaining this project would be of great interest to me.

I am particularly interested in exploring the possibility of adding support for the Plan File Format to the project. If this is something the contributors are interested in, or if there is anything else I can assist with, please let me know.

[hamishwillee]

Hi @Russi1555

Thank you for getting in touch and volunteering. Being a maintainer is quite hard - currently we have @morzack who has volunteered and done some work, but has then discovered that it is very time consuming. I think he has stalled - no judgement, it is hard work, and needs to be a primary hobby or something you really need to work with.

I think adding support Plan File Format is a good idea, but there are two issues.

• The first is that without a proper maintainer team, who would review this work :-). We can work around this with sufficient test cases.
• The second is technical - the complex mission items that format define the data needed for surveys etc. However the protocol knows nothing about these - it just knows MAV_CMD items. So QGC converts the plan to a series of MAV_CMDs for upload, and presumably back to a plan for download (or maybe it just uses the raw definitions if it downloads). The point is, that conversion process is undocumented, and it may well matter to people if you don't get it right. Something to think about.

W.r.t. to what needs to be done, IMO the most important thing is getting a robust python 3 implementation of the current tool and publishing it on PyPi.

There are also a bunch of issues/PRs that need review and analysis.
My ideal is that you work on some of these with @morzack and bring yourself up to speed over a month or so, then start the work of updating to Python 3.

When you have something stable, we'd invite @peterbarker to help with a release.

Does that make sense?

[morzack]

Hello, and sorry for a lack of communication over the past while -- I unfortunately haven't had a lot of bandwidth recently to look at this.

W.r.t. to what needs to be done, IMO the most important thing is getting a robust python 3 implementation of the current tool and publishing it on PyPi.

I just want to comment here: my understanding is that this repository is actually at a point where it should be fully compatible with the newest versions of python3. I haven't exhaustively tested it, but do regularly use it in a python3 environment without issues. The main things that need updating are the documentation (it still contains python2 examples) and the pypi release (which is currently broken for python3.10+).

There are also a bunch of issues/PRs that need review and analysis.
My ideal is that you work on some of these with @morzack and bring yourself up to speed over a month or so, then start the work of updating to Python 3.

I previously made a bit of an effort to screen some of the issues and found that a very nontrivial number of them should be cleared by pushing a pypi release, provided that we can confirm that everything is in a stable state for release. Beyond that, most PRs are really just at a point where they need testing (artifacts). Tag me in any that need another pair of eyes for code review and I'll take a look, my main limitation is that I don't have any hardware to aid in testing (beyond ardupilot's SITL).

[hamishwillee]

I've asked @peterbarker if he could perhaps help cut a release candidate. Then maybe @Russi1555 you could retest and update the examples to Python 3 using that, as a more complete test of the build - @morzack as reviewer?

[stevenjowens]

Hi, I'm also interested in helping with dronekit.

I haven't used dronekit to date, though I've heard good things about it. I've been using pymavlink and there is definitely a need for something higher level, like dronekit.

At this point I'm familiarizing myself with dronekit and the dronekit codebase. If there are any documents aimed at contributors, beyond the obvious contributing and develop directories in the repo I'd appreciate a pointer. In particular, anything that goes into the architecture of the code.

[Russi1555]

Hello, sorry for the delay in replying.

Thank you for explaining the manpower and technical issues behind implementing the Plan File Format, i wasn't aware of how cryptic the conversion process currently is. Unfortunately, my current routine wont allow me to give the necessary time and attention to the project.

Although i wont be able to make contributions to the project as of now, i will continue to familiarize myself with it so i can help in the future. If the is any such documents as the ones @stevenjowens mencioned, i would also have great interest in having access.

Thank you all for replying, i hope to come back to project at a later date with the adequate availability.

[hamishwillee]

I don't know of any architecture guide sorry, but one of the joys of DroneCode-Python is that most of it can be worked out fairly easily.

@Russi1555 FWIW it isn't so much that the conversion process isn't defined, it is that pattern types have no meaning in MAVLink at all. MAVLink only understands MAV_CMDs in missions, and so the plan to create surveys from these primitives something that QGC made up.

You could probably define such a thing in MAVLink - I'm thinking a definition like the geofence polygon. The flight stacks might be interested if the tradeoffs were right - large saving in consumed size on vehicle say vs cost of implementation. Certainly no push for this.

Anyone who wants to update the examples, that would be good :-). Peter not responded to request to help with release, and that should wait on him.