DroneKit-Python Rescue Project

Topic:DroneKit-Python Rescue Project

Proposal type: Software

Description:

The purpose of this project is to put a relatively small amount of effort to update and release DroneKit to ensure that it remains useful for developers to use on their companion computer interfacing with ArduPilot.

Tasks included:

  • fix documentation links to DroneKit from ardupilot.org (volunteer)
  • review important looking issues and PRs and close or merge them
  • update some features to catch-up with ArduPilot’s capabilities:
    • ensure MISSION_ITEM_INT, COMMAND_LONG_INT are used when possible
    • add terrain alt support to go-to command
    • verify that position, velocity, attitude control works with Copter, Rover, Plane in Guided mode
    • consume EKF status report’s GPS glitch field
    • support multiple rangefinders including different directions
    • multiple vehicle support?
  • do a release after updates including producing a blog on ardupilot.org

How does this fit in with other competitors:

  • pymavlink: a lower level tool much more tightly tied to the mavlink protocol. Dronekit is built on top of pymavlink.
  • Lua scripting: onboard meaning it has limited access to CPU resources and external sensors. Companion computers with dronekit are for situations where CPU and access to external sensors (i.e. cameras) are required.
  • DroneAPI/MAVSDK: another competitor which another team is putting effort into. Integrating would be a much larger longer term effort. These projects have been moving in fits and starts.

Planned amount $8K (USD):

Estimated time for completion: 2 months

11 Likes

It is unclear who would do this work, and also unclear who would manage the funds to ensure that payment is appropriately distributed only when either work is completed or contract for work is scoped-out and signed.

Separately, I’d like to point to OpenSolo’s continued releases as an example here and say that due to it having just a couple/three passionate software devs, it was able to take on and manage the releases of a much,much larger bundle of code, “for free”… and by that I mean by devs volunteering their time, for the betterment of the project.

I’d therefore like to suggest that it may be better NOT to fund this project, because we will then get to find out who is truly passionate enough about it to step up and volunteer, and if no-one is, then that’s a pretty good reason to let it die.

Thanks for the feedback. To clarify, I intended for Peter Barker to be the recipient of the funding and the Funding team would take care of making sure that it was paid. I’d handle the basic project management but I wouldn’t charge AP for that.

I think some projects work fine with no funding but others need it. I think we can expect that without funding dronekit-python will continue as it has been which I think means it will fall further and further behind the main ArduPilot code’s abilities (see here for recent commits: github/dronekit-python).

I think a fair question to ask is whether we should bother trying to maintain DroneKit-python or whether we should just push people to pymavlink which is slightly more active (see commit history here) but also harder to use.

1 Like

This is really interesting. We like dronekit-python and use it a lot but it is lacking in some features/functionality.

Might be able to help with Development and Funding for specific modules.
RTK integration would be a great one to have. Also multiple vehicle support, although we have a workaround for this in place.

Please keep me in the loop. Let me know how i can help!

Nick

I don’t think we should arbitrarily decide who. My understanding is that this is a proposal to make the funds available - which I support. We then need to apply good governance practices to determine where they are spent. The simplest way to do that is via the Jobs page (https://discuss.ardupilot.org/c/general/wanted-jobs). That way it is transparent, and we reduce the potential for perceptions of self-dealing or cronyism.
I also see this as somewhat of an interim effort: DroneKit, whilst currently suffering from a lack of maintenance, is quite comprehensive and in use, so a refresh is the right thing to do, to support the community/users. But @DavidBuzz is basically right - without dedicated Dev’s providing ongoing maintenance, we’ll end up back in the same situation we find ourselves in now, which basically means DroneKit-Python would become a sponsored project. Longer term, I think MAVSDK will provide an attractive alternative (with options beyond Python), and we’d do well to put effort into pushing for it to become compatible with ArduPilot. That would also go some way to addressing an obvious next question… what to do about DroneKit-Android and Tower.

1 Like

@Matt_C I know it frustrates some members of the dev team that I push for a two-pass approach, but I think it’s a robust way to manage expectations and meet governance requirements. For significant spends, such as this proposal, I think there are basically two parts to the process: approving a “budget” (how much can I plan to spend on this), which is what I see this request as being; and then the value for money piece, which takes into consideration

I largely agree with your other points, and think I mirrored them to a degree in my earlier post, tempered by a concern that there are a large number of DroneKit deployments, and DroneKit as a project was basically completely sponsored by 3DR until 2016, so didn’t have a culture of community contribution.
@rmackay9 is right: in the short term, a DroneKit refresh will support more users, faster, than MAVSDK, as even with compatibility the MAVSDK is very immature and nowhere near feature complete. pyMavlink is very capable, but is less abstracted so has a higher barrier to entry.
Ultimately, as you and Buzz highlight, the best solution is for someone from the Dev Team, a Partner, or community member to step up and drive SDK maintenance (be that DroneKit, MAVROS, MAVSDK or any other). Otherwise the cycle will repeat.

1 Like

All valid points, and it’s great that you are contributing to the decision process - I think it is good to have my views challenged. I guess I see value in having an up-to-date SDK, which is why I’m still supporting this. This definitely isn’t the optimal approach, but unless someone steps up very soon, it’s an approach I’m willing to support.
This particular request is subject to a full vote by the Dev Team, so it will be interesting to see the outcome.

The main issue is that there is demand for dronekit support from some partners, academics and community but nobody want to do the support… Unfortunately, that is a hard task to invest time on open source … You can see it even on ArduPilot, we are a few deal with multiple matters on the project, for free. I don’t blame other for lack of investment, everybody do as much as it can ! Beeing passionate isn’t enough,
With-Great-Power-Comes-Great-Responsibility-Meme

So paying for dronekit is the last way to bring support on dronekit.

PS: I am not in favor of it as I think that dronekit is dead. But I still think that we should but some effort on bring it doc and server up for those that still us it.

1 Like

There is always only a few that will benefit from funded proposal …
You can look at other proposal :
heli autorotation will concern only heli guys,
tracker maintainer will concern only those that use tracker
sensor/board X will only concern those that buy this thing
contribution of the month, only those who contribute
etc…

But we listen your concern but also listen to other on community that push us to get back dronekit.
I will ask other about opinion on launching a community survey on this matter, it may change opinion … but also bring a big mess …

I mean as few want dronekit as tracker update. Just look at questions on discuss and gitter.

The community speak on those channels, what is the issue ?
The “few” you know (see DroneKit-Python Rescue Project) speak nothing to me, but posts on discuss and gitter (or issue list) are.

Discuss and gitter (and mumble) are the officials way to communicate with the project, we cannot guess what user are speaking about on field if we aren’t there … If we don’t have report how can we know ?

We would love to see dronekit updated/rescued. We could, as a company, fund a little bit of it.

regards,

Corrado

2 Likes

I’ve seen a number of end-users here suggesting that they could help fund or partially fund this ‘rescue project’, so given that, i’d like to suggest that a kickstarter/go-fund-me/indiegogo campaign is actually a good idea here, not just for the extra $ it could bring in, but more importantly, it will potentially help bring together those invested end-user/s who want to see this done under a single umbrella, and let the developer group get a better measure on just how big this potential user group really is, and if there’s enough user demand to justify the entire effort/s. if the campaign flops, then that’s ok too, it’s a successful measure of the lack of demand.
thoughts?

1 Like

I’m all for rescuing something that is a useful asset to the community, partners, users, and future development. Going down the road of “well only X number of people use it today so why bother” is not a good road to go down IMO. If we took a talley of how many people will use a feature to decide what gets done, ArduPilot would suck. Is it useful today? Yes. Can this make it more useful tomorrow? Yes. If we fix it, will people notice? Yes. If the answer was no no no, then of course it’s not a good use of time and money. But I don’t think DroneKit fits the “no, no, no” category. So it is absolutely worth the consideration IMO.

My much bigger concern is what happens after it is rescued? Bringing something back to life wins a battle but the war ain’t over. It has to be maintained on an ongoing basis like everything else. If there isn’t also commitment to maintain it, then no vendor, partner, or developer is going to commit to using it, making it an exercise in futility.

So, not that I have any official say in the matter. But my suggestion would to make sure there is some commitment to keep it alive after resuscitating it before throwing money at it.

The correlation to OpenSolo is a good one, but probably not the same perspective as Buzz. We rescued it and made it relevant again, which was great. And yes, we indeed did it for free. However, just because it was free, it was not without cost. It was a tremendous amount of personal time spent by several people over the course of a year.

And I will tell you I personally spent WAY more of my personal time on it than I should have. It came at significant cost to other things in life. So I would actually strongly disagree that just because Open Solo happened for free, than DroneKit should too. I would not want or expect someone to do that. And then also expect them to continue maintaining it.

Sometimes, things just need to cost money.

1 Like

I have a question and it might be a dumb one. Is there an “official” or at least “best practice” way to program companion computers? Like rmackay9 says, there are some competitors but Dronekit is a fairly OK system and, from my understanding, assumed to be more or less the default for companions.

Apart from the fact that Dronekit needs maintenance, python2 is out by 2020. How much of a problem will that be?

Personally, I am rather fond of Dronekit and would contribute to a funding campaign for maintenance.

1 Like

Hi there, I’ve spend last couple days experimenting with DroneKit and exploring other options.

What I have found is that DroneCode seem to be actively developing MAVSDK so will end up with a more complete API to the autopilot but the Ardupilot ROVER is significantly more advanced that what DroneCode (PX4) offers. Maybe I am missing something, is there a replacement to DroneKit I have missed?

It seems the nothing else really exists to replace DroneKit if it does start to fall behind too much.

Has this been resolved has this topic been resolved by the devs? If there was a fundraising, I would contribute a small amount.

Kind regards,
Ben

G’day @BenRB,
just a quick reply to let you know I’ve reached in to get a proper answer for you.
I suspect we’ll end up supporting both, with a DroneKit refresh first whilst we continue to debate the merits (and politics) of mavsdk.

Hi James, thanks for this response. I look forward to hearing the outcome. I’ll continue poking away with DroneKit.

The whole stack is very powerful.

EDIT: moved away from dronekit and happy with pymavlink. I am sure dronekit will still be a good fit for others though.

We had a vote on whether to fund this proposal or not and the result was Yes:56%, No:44%. Technically this is enough to proceed but there apparently wasn’t a lot of enthusiasm so I’m not planning on progressing with this effort.