Feature Request

The inevitable (and valid) argument that puts the most pressure on better independent de-coupling of the versions is that operators will need to stabilize on a version for their projects beyond the core features, and for stability, cannot keep pace with development versions, and commercial operators will want to stabilize on releases based on their customer needs, etc.

This is made less of an issue mainly because 1) mission planner is not the only MAVlink protocol handler around, you can fly with other GCSs, and 2) you can retain a Mission Planner version and/or setup completely from CLI for maintenance and configuration of fixed versions and 3) all the code is available to you, so if you have to, you can fork. Eventually, even a static version of Mission Planner will not function, as a result of operating system patches, API changes, and so forth. But for all these reasons, the need is not high enough in the projects for the cost to be worth it to support more versions from one Planner.

But that is just my thinking, and completely without a single word or inside knowledge of the esteemed and honorable Mr Oborne and Mr. Short.

My impression of the longer answer - having read bits of parts of both the Mission Planner and ArduCopter code is that supporting mismatched versions between the two introduces a complexity that would make it very difficult to maintain and support, with a high potential for very strange, hard to trace bugs.

Consider that Mission Planner is not strictly a MAVlink ground control station, but is also responsible for managing ArduPlane and ArduCopter configurations. It is here that things get complex. A good example (as a general, not specific case) might be the 2.0.39 and 2.0.40 split, in which eeprom data changed, and had to be reset on the APM. If there are different features and options for different versions of the code, then Mission Planner, if it is to support different versions, must know about each and every difference, and must adapt at the time of each "connect" to these differences.

Having managed software projects like this, I know it can be done. But how much of your development resources do you tie up with independant development, parallel support, and regression testing? There is more that can be said, and arguments postulated on both sides of the issue, that certain development philosophies and designs rightly or wrongly espouse lose coupling, abstraction, and big-brain architectural design, API layers and future-planning built in, and the refactoring crowd will split easily on the issue, often using the same arguments on both sides in different ways. But once you get down to rapid development, on different processor platforms, in different languages, in which one environment is microprocessor firmware (however unlike microprocessor the Arduino feels) and the other is C# with .Net and Windows systems calls, subjected to the various API changes and complexities that come with that environment also.... well, it is just *so* much easier to bind certain versions together, and so much less efficient to try to guarantee mis-matched compatibility.

Consider a second example, I read somewhere yesterday about rumors of a MAVlink protocol change. Doesn't matter if it is or is not true, but when it happens, and when these tools adopt the change, do they both maintain separate versions, and support both versions, and negotiate versions? If so, for how many generations of code on each side?

I hope this makes sense, as an extended explanation of why I suspect there are no plans (as I understand it from the post here and linked below) to support several versions of firmware from each release of Mission Planner.

But I'm making this all up, so please forgive me if I am off target.

Replies

Moderator

Michael Pursifull September 15, 2011 at 2:40am

The inevitable (and valid) argument that puts the most pressure on better independent de-coupling of the versions is that operators will need to stabilize on a version for their projects beyond the core features, and for stability, cannot keep pace with development versions, and commercial operators will want to stabilize on releases based on their customer needs, etc.

This is made less of an issue mainly because 1) mission planner is not the only MAVlink protocol handler around, you can fly with other GCSs, and 2) you can retain a Mission Planner version and/or setup completely from CLI for maintenance and configuration of fixed versions and 3) all the code is available to you, so if you have to, you can fork. Eventually, even a static version of Mission Planner will not function, as a result of operating system patches, API changes, and so forth. But for all these reasons, the need is not high enough in the projects for the cost to be worth it to support more versions from one Planner.

But that is just my thinking, and completely without a single word or inside knowledge of the esteemed and honorable Mr Oborne and Mr. Short.
Moderator

Michael Pursifull September 15, 2011 at 2:22am

My impression of the longer answer - having read bits of parts of both the Mission Planner and ArduCopter code is that supporting mismatched versions between the two introduces a complexity that would make it very difficult to maintain and support, with a high potential for very strange, hard to trace bugs.

Consider that Mission Planner is not strictly a MAVlink ground control station, but is also responsible for managing ArduPlane and ArduCopter configurations. It is here that things get complex. A good example (as a general, not specific case) might be the 2.0.39 and 2.0.40 split, in which eeprom data changed, and had to be reset on the APM. If there are different features and options for different versions of the code, then Mission Planner, if it is to support different versions, must know about each and every difference, and must adapt at the time of each "connect" to these differences.

Having managed software projects like this, I know it can be done. But how much of your development resources do you tie up with independant development, parallel support, and regression testing? There is more that can be said, and arguments postulated on both sides of the issue, that certain development philosophies and designs rightly or wrongly espouse lose coupling, abstraction, and big-brain architectural design, API layers and future-planning built in, and the refactoring crowd will split easily on the issue, often using the same arguments on both sides in different ways. But once you get down to rapid development, on different processor platforms, in different languages, in which one environment is microprocessor firmware (however unlike microprocessor the Arduino feels) and the other is C# with .Net and Windows systems calls, subjected to the various API changes and complexities that come with that environment also.... well, it is just *so* much easier to bind certain versions together, and so much less efficient to try to guarantee mis-matched compatibility.

Consider a second example, I read somewhere yesterday about rumors of a MAVlink protocol change. Doesn't matter if it is or is not true, but when it happens, and when these tools adopt the change, do they both maintain separate versions, and support both versions, and negotiate versions? If so, for how many generations of code on each side?

I hope this makes sense, as an extended explanation of why I suspect there are no plans (as I understand it from the post here and linked below) to support several versions of firmware from each release of Mission Planner.

But I'm making this all up, so please forgive me if I am off target.
Developer

Michael Oborne September 14, 2011 at 4:43pm

the short answer is no.
have a look here why
http://www.diydrones.com/forum/topics/idea-for-softwarupdates

This reply was deleted.

Discussions

Feature Request

Replies

Activity