Over in QGroundControl we are going to start on some significant UI rework specifically associated with the PX4FMU stack. At this point the APM specific support (non Mavlink generic) in QGroundControl is very outdated and is questionable at best as to the whether it works or not. I’m also assuming that APM Planner is not interested in merging forks back together between the two codebases. They have diverged quite a bit.
At this point the maintenance to keep all the incorrect APM code working in QGC just isn’t worth the effort any longer. It also just adds confusion to users, fooling people into thinking that you can do things with QGroundControl + APM stack that really don’t work.
Given all of the above, we are going to at first disconnect the APM specific UI from QGroundControl. And then at some time later, we will remove the code as well. Wanted to give a heads up to make sure this won’t cause any issues with APM Planner.
You will still be able to talk straight mavlink to the APM stack with QGC as you have always been able to do.
Incorect would imply that the features you speak of don’t work. Which is clearly not the case, as APM Planner works with the APM as intended. We don’t support the PX4 stack or any other autopilot that uses MAVLink. Which is due to the issue that every implementation of a autopilot using MAVLink uses its own interpretation. There is no conformance tests to the spec, and only scant incomplete specs at best. With such a small number of people involved its to be expected. (We just don’t have time for that)
I have worked on IrDA and Bluetooth implemenations in the past and with 100s of people involved, it still is a conformance PITA.
Without true oversite and funding MAVLink as a application network protocol will not really be something other than an enabler, it has too many shortcomings for long term UAV goals. I look forward to something new, Maybe MavLink2, but without a real detailed specification and behaviour laid out it will just be yet another non-standard standard.
I really don’t think there is such a thing as ‘straight mavlink’. You just need to read the mails from frustrated ARDrone Flight Recorder people using QGC to see that.
Please don’t take this the wrong way, its just an honest opnion of the shortcomings of the challenges of creating a ‘standard’ app protocol. Its more than just compact data strutures and complex union types, but behaviours and clear seqeunces, with clean fallbacks and data loss recovery over unreliable links. Its not easy, and i’m only a guy whose has worked in the trenches. Simply, we just don’t have enough people with enough dedicated time to create the best ‘universal’ spec. en.m.wikipedia.org/wiki/Andrew_S._Tanenbaum said in his computer networks book, if you can’t find a standard that fits, create a new one. Open Pilot has
PS:And its not so only a protocol, its a whole ‘autopilot config’ thing, now making that ‘generic’ feels like some major headache
I think your missing my point. I’m not trying to argue for merging forks, nor am I trying to argue that there is some better spec that could make this all work. I’m just trying to give you a heads up that if you are still pulling across anything from QGroundControl to APM Planner that things are about to change out from under it such that this may no longer be possible. Or certainly at least in some areas. I have no idea if this is already not possible or even done any longer. I figured since APM Planner started from QGroundControl it was a good thing to say something about it before just doing it in case it would be a problem for some reason.
and PS: we are not unhappy you need to do you own thing, and thanks for asking. We forked QGC to solve a problem. Thanks Lorenz et al… As i said, just too hard to keep this stuff in sync. Unless we raise a small army that lives on beans alone
I’m not trying to argue for merging the forks together. I’m just giving a heads up as to what is going on in the QGroundControl side. Just in case you still pull across from there. If so, this could be a problem, or at least get harder. I don’t know if you do that any more. I figure since APM Planner started from QGroundControl that it was a good thing to raise a hand first, before changing things.
In any case, you are correct in your assumption about the merge, and the heads up is appreciated. If anything, we have been cherry picking commits from QGC and going over them to make them work with AP2’s different code, but we’ve gotten fairly far away from QGC in terms of structure so I don’t believe we’ve pulled anything in from QGC in quite a while.
@Don: I don’t mean my previous comments to come across as negative to the work on QGC, more a view on how developing and using a protocol is challenging and difficult. My past experiences in that area requires documents that are 100s of pages long (e.g bluetooth.org/en-us/specification )
QGC/AP2 support multiple autopilots in the architecture, but without more contributors testing all those variants is a near impossible task. The result is the code diverges. And the ‘standards’ becomes implementation specific. There is no such thing as ‘straight mavlink’, QGC has a slight different flavour.
There is still code in common, feel free to take those common fixes. And keep up the good work.
