Board index FlightGear Development Aircraft

Autonomous F-14b demo

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Autonomous F-14b demo

Postby curt » Sun Sep 25, 2011 2:47 am

I posted this first on the FlightGear developers mailing list and got some helpful feedback, so now I thought I'd post over here and see if I could find a few more people who might be interested in testing this out. This demo requires downloading a small zip file that extracts over the top of the existing f-14b, but is mostly additive (it creates a new aircarft f-14b-uav rather than modifying the existing f-14b)

Folks who might be interested in this are (a) people who are interested in uav/uas/drones, (b) people who are interested in carrier ops, (c) people looking for a new or interesting challenge to try in FlightGear, or (d) people who are too lazy to fly themselves and prefer to have the computer do everything. I might be option (d) myself. :-)

http://www.flightgear.org/uas-demo/

So just to summarize. This demo creates a fully autonomous version of the F-14b. It can auto-launch, setup a well defined approach and auto land on a moving carrier in windy, gusty conditions, it can fly circle holds over a point (which you click on visually), it can fly a route (which you program in the autopilot route manager dialog box.) And it also has a simulated gyro stabilized camera for doing simulated surveillance or simulated search and rescue.

Some of the first guinea pigs had problems with the f-14b autopilot spinning in. I'm still not sure why since I don't see that here and at least one or two other people have had good success. So I've reworked the roll control quite a bit and I'm hopeful that this will fix things for most people.

If you do give this a try, I'd love feedback or corrections on my web page instructions. I know there are places that it's weak. I'd like to eventually post this on DIYdrones and a few other places, so I'm hoping that I can make this pretty newbie friendly.

Thanks!
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: Autonomous F-14b demo

Postby pygmyskunk » Mon Nov 07, 2011 8:09 pm

Ah found the post.

I have not tried to actually USE the F-14 demo, I was looking through the files and found the nasal code of the UAV and the only thing I have to say about it is why is it formatted in such an unreadable way? I want to take this code and use it for my own work on UAVs and while I do have a basic nasal AP, still can't figure out how to land plus I have been using a lot of external programs to control my aircraft so it is hardly newbie friendly.

In other words I am trying to get my X47 to have two levels of playability so to speak. One based on Nasal and easily accessible within FG, the other relying on external programs, sockets and networking for the more advanced use. Since your work with FG uav is pioneering it could be helpful if that one nasal script wasn't compacted and readable by human eyes, thus able to be modified and added to other aircraft if desired.

Also I read somewhere recently that you have automated AAR?? Or some basic form of it at least. That is something I am trying to work on myself, as the goal for the X47 is just like the real world plane is to be able to do AAR and possibly stay in flight indefinably. In fact the Navy recently made an announcement about this very subject so that was a bit creepy but you get the idea.
pygmyskunk
 
Posts: 25
Joined: Tue Feb 15, 2011 3:47 pm

Re: Autonomous F-14b demo

Postby curt » Mon Nov 07, 2011 8:23 pm

I did some of the work in that demo under contract and unfortunately don't have permission to release the full un-obfuscated code. There's no magic in that nasal code, just bucketfuls of sweat, a few tears, and literally 100's of hours of test flying. :-)
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: Autonomous F-14b demo

Postby Hooray » Mon Nov 07, 2011 9:39 pm

curt wrote in Mon Nov 07, 2011 8:23 pm:I did some of the work in that demo under contract and unfortunately don't have permission to release the full un-obfuscated code. There's no magic in that nasal code, just bucketfuls of sweat, a few tears, and literally 100's of hours of test flying. :-)



I am sorry to say this, especially to you Curt, but if the Nasal source code was deliberately obfuscated due to contract work and due to trying to circumvent FlightGear's licensing restrictions, you might want to reconsider distributing your work altogether, because you are basically violating the requirements of the GPL.

If you don't believe me, just see the GPL v1/v2/v3 FAQs: http://www.gnu.org/licenses/old-license ... anSoftware

Nasal source code must be considered "source code", it being "obfuscated" is no longer the "preferred, human readable form".

Or just see any other related discussion about GPL and scripting languages:
http://programmers.stackexchange.com/qu ... n-readable
http://stackoverflow.com/questions/1086 ... on-and-gpl
http://stackoverflow.com/questions/1552 ... bfuscation
http://community.elgg.org/pg/forum/topi ... alled-gpl/
http://nealrichter.posterous.com/the-gp ... -languages
http://answers.yahoo.com/question/index ... 515AASP4mf
http://aicoder.blogspot.com/2009/08/gpl ... uages.html

http://c2.com/cgi/wiki?WhatIsSourceCode
Can I release software based on GPL with obfuscated source code?

No. (To be pedantic, yes, you can release whatever software you want, but if it's based on GPL, and the people you release it to ask for the source code, you must give non-obfuscated source code or be in violation of the license).

The GPL defines source code as follows: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." This would preclude distribution of obfuscated code. The GPL also requires that distributed source code be machine-readable, presumably to prevent people from offering source code only in hardcopy form or in some other hard-to-use format (stone tablets, for example).

Consistent with that definition, however, would be the view that manually obfuscated SourceCode is the SourceCode, whereas perhaps automatically obfuscated SourceCode would not be! A legal minefield if you ask me...

I see no difference between manual obfuscation and automatic obfuscation in the GPL definition (or the definition on this page). However, IANAL


The thing to keep in mind here is that due to FlightGear being GPL, its the viral nature of the modules you are relying on - such as by using any of the standard Nasal modules in $FG_ROOT/Nasal. Just making use of another Nasal module, is the tightest possible form of "linking" in scripting space.

Now, given that the majority of Nasal source code in $FG_ROOT/Nasal was created by a single FlightGear core developer, i.e. Melchior Franz, you would have to ask him for an explicit exception - on the other hand, he has repeatedly stated that he considers all of his contributions to fall under the terms of the GPL and he seems to be one of the most outspoken proponents of the GPL, too: http://www.mail-archive.com/flightgear- ... 31880.html

All that said, it should actually be pretty straightforward to clean up any Nasal code automatically if you really wanted to.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11345
Joined: Tue Mar 25, 2008 8:40 am

Re: Autonomous F-14b demo

Postby curt » Mon Nov 07, 2011 9:52 pm

FWIW, the only thing I am distributing is a standalone nasal module with some different -set.xml files to include the new nasal module. My work is not based on any previous gpl code, it's entirely developed in house by me. I'm not redistributing anyone else's gpl work with it. I suppose this is like anything and we could have a long long long discussion about various nuances and interpretations of the gpl, and 10 different people will have 10 different opinions. But be assured that what is obfuscated is not gpl and is not based on anything that was gpl -- it's entirely my own code, written from scratch by me. Further this code is not released under the terms of the gpl and I'm not calling it gpl'd.

It's true that a motivated person with a lot of time on their hands could unwind most of it and get it back to a more understandable state. But I promise you, it would be a lot faster and more productive for such a motivated person to just figure out the stuff on your own because I promise there is no magic in there, just some sweat -- and if you put in as much time as I put in, you will probably come up with something twice as good as me. :-)
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: Autonomous F-14b demo

Postby Hooray » Mon Nov 07, 2011 11:00 pm

curt wrote in Mon Nov 07, 2011 9:52 pm:My work is not based on any previous gpl code, it's entirely developed in house by me. I'm not redistributing anyone else's gpl work with it.


I understand what you are trying to say, however this is like someone saying his code doesn't fall under the GPL because he's written all of it himself, but as you clearly know, this simply isn't true - the point of the GPL is to prevent "tight coupling" to a certain degree where significant features are used without "sharing", but also to ensure that contributed source code is made available in its preferred human-readable and reusable form, it doesn't matter whether this is about C++ source code leveraging the FlightGear/SimGear APIs, or if this is about Nasal modules leveraging pre-existing Nasal modules made available by fellow contributors, in the belief that they're covered by the GPL, as is not only implicitly assumed by most, if not even all, FlightGear contributors, but as is also explicitly specified at the top of many source files, including Nasal modules in $FG_ROOT/Nasal.

curt wrote in Mon Nov 07, 2011 9:52 pm:I suppose this is like anything and we could have a long long long discussion about various nuances and interpretations of the gpl, and 10 different people will have 10 different opinions.


Nope, this is isn't my impression at all, neither is it my intention to have such a discussion.
In fact, the GPL is quite clear about it. Anybody who fails to interpret it accordingly, is opening a whole new can of worms.

Seriously, I don't intend to act like a smart ass here, and I do apologize in advance if I am appearing like a pain in the ass.

However, the thing is that you are causing a precedent here. That's unfortunate but still true.

This is even more so very unfortunate because you are not just "any" random FlightGear contributor, but rather you serve as a "role model" for many long-term FlightGear contributors, not the least of which because you are also the de facto "project coordinator" or at the very least the "project lead".

So it is your position that is giving this precedent a lot of weight, too.

What I am trying to say is that you should consider discussing this issue with fellow core developers, simply because this isn't just a matter of "interpretation" (as you suggest), but rather a pretty clearly defined legal issue.

If you, as the project lead, illustrate how to circumvent the GPL by coming up with an obfuscated Nasal module that still leverages Nasal source code that definitely falls under the GPL, you are possibly doing more harm to the project in the long run than you may have anticipated.

One possible way to address this issue one and for all, would be coming up with an exception clause for the base package, so that Nasal source code files can be granted with, and distributed under, a more permissive license explicitly.

This would make it possible to come up with non-GPL modules if needed.

Given your position in the project, that should be much easier for you to discuss and implement than for anybody else.

Seriously, the project lead of a GPL'ed open source project distributing obfuscated source code trying to circumvent legal restrictions of his own project is simply begging for trouble.

Really, this isn't about your addon or the obfuscated code at all, it is about the repercussions it may possibly have if this issue isn't discussed properly, simply because other users may do similar things, too.

Just imagine for a moment that Thorsten's local weather addon or flug's bombable addon were provided in an obfuscated form.
What would you think about that? Or what if Melchior or AndersG had made their significant Nasal contributions only in some obfuscated form?

I am pretty sure that we would have seen quite a lengthy discussion (read: flame war) on the developer's mailing list long ago, had this been the case.

On the other hand, it certainly is the utmost respect of fellow FlightGear users and contributors for you and your contributions to FlightGear that stops them from raising this issue openly.

Again, sorry for being a pain in the ass - it's nothing personal at all, it's just about the repercussions this may have at some point.

Otherwise, it wouldn't be all that unlikely that scams and rip offs (like the "FlightSim Pro" guys) could quite easily point at your own contributions to make their case in order to easily circumvent the GPL in the future.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11345
Joined: Tue Mar 25, 2008 8:40 am

Re: Autonomous F-14b demo

Postby curt » Mon Nov 07, 2011 11:24 pm

This reply isn't intended to thoroughly address every point, but let me ask a few question and make some observations.

If I have some C code and compile it with the gnu compiler (even just once as a test) does that force me to put all my code under the gpl? The answer is no, and I believe the answer has always been no, but Gnu did put out an addendum to clarify the point so that people could use the gnu tool chain in commercial settings.

The perl script interpreter is distributed under the terms of the gpl. Does this force every perl script ever written to be gpl? Larry Wall writes: "For those of you that choose to use the GNU General Public License, my interpretation of the GNU General Public License is that no Perl script falls under the terms of the GPL unless you explicitly put said script under the terms of the GPL yourself." Reference: http://dev.perl.org/licenses/

The precedent in FlightGear has always been that what is licensed as gpl remains gpl, and derivative works of gpl code/data remain gpl. But we've also said that in the context of scenery data and models, that running the data through our scenery processing tool set doesn't add to, remove, or change the license terms of the original data. This is not the exact same situation as nasal code, but that is one precedent within the flightgear project that I can point to that was established 15 years ago.

So when looking for examples and in the links you originally posted -- it's important to distinguish between a script being a derivative work of something that is gpl (in that case you can't obfuscate it to get around the gpl license) versus the script being an independent original work (in which case the author should be able to pick whatever license they deem appropriate for their work.)

Making a linkage based argument is interesting, but it appears that most people do draw a separation between the code that implements the script engine, and the actual scripts themselves. I have never thought otherwise, although perhaps this particular specific discussion has never come up before.

So just to summarize, I have always viewed the relationship between flightgear and the nasal interpreter versus nasal scripts in the same way that Larry Wall has viewed the relationship between the perl interpreter and people's perl scripts. The interpreter doesn't force it's license on the scripts and the script authors have the freedom to choose the license terms that work best for their situation. And again, for derivative works (i.e. modifying an existing gpl nasal script, the gpl license must be honored and maintained and not obfuscated.) But for original works, I continue to believe the author has discretion over how to license his/her own work.

Best regards,

Curt.
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: Autonomous F-14b demo

Postby Hooray » Mon Nov 07, 2011 11:55 pm

I think there's a misunderstanding here, I actually share most of your points and even agree with your final conclusions.

The issue really isn't the license of the Nasal C code, or of the FlightGear C++ source code. That one is quite clear: they provide "standard interfaces" to interact with the software, no matter if it's library code or extension functions. This code is specifically meant to be used by scripts that do NOT fall under the license of the underlying source code.

The real issue here is the license of the script code that is leveraged by other script code. Generally, most/all "resources" in the base package are understood by most long-term contributors to fall under the terms of the GNU GPL, even if they should happen to lack a corresponding explicit license statement at the top of the source file.

it's important to distinguish between a script being a derivative work of something that is gpl (in that case you can't obfuscate it to get around the gpl license) versus the script being an independent original work (in which case the author should be able to pick whatever license they deem appropriate for their work.)


Yes, correct - as long as he doesn't make use of any pre-existing source code by relying on it (i.e. in the form of including/requiring a separate module), which in the case of FlightGear is implicit, due to all in $FG_ROOT/Nasal/*.nas files being loaded automatically by default.
Furthermore, new Nasal modules do of course "depend on" pre-existing GPL modules once they start using features/code/library routines made available by them.

In scripting space, this is the tightest possible form of linking and "using" source code. In other words, if any proprietary or obfuscated source code makes use of GPL'ed scripting modules, then such a module would also fall under the terms of the GPL, barring a corresponding exception.


Making a linkage based argument is interesting, but it appears that most people do draw a separation between the code that implements the script engine, and the actual scripts themselves. I have never thought otherwise, although perhaps this particular specific discussion has never come up before.

Actually, it has come up before - as you'll see if you refer to the links that I posted previously. In addition, other major open source projects that depend on scripting have had the same issue and discussions, too. Mozilla/Firefox but also gcc come to mind.

The "linkage argument" is entirely based on the tenor of the FSF GNU GPL itself, the whole issue boils down to prevent tight coupling/linking where GPL code is leveraged (no matter how "original" the work may be otherwise) without also granting all of the privileges of the GPL back to the users/receivers of the work.

But for original works, I continue to believe the author has discretion over how to license his/her own work.

Again, in the case of FlightGear/Nasal, the real issue is if the original work uses any preexisting Nasal modules that are generally understood to fall implicitly under the terms of the GNU GPL. That's really the only thing that matters. For the FlightGear project, as a legal entity, this is an important strength.

To quote one of the links that I posted previously:
http://aicoder.blogspot.com/2009/08/gpl ... uages.html
What does the scripting language really do under the hood? It's different in each language. Some may physically include the file and parse-interpret it as one block of code, others may parse-interpret separately and resolve references between them much like a dynamic linker. Do the details matter? Unknown, yet one could reasonably assume the author of a piece of script code under the LGPL must have intended others to make script-include style uses OK. If in doubt check with the author and save that email.

What about the GPL? More clear.. no mixing of any kind can be done. One could argue that interpreted script is not linked in the way that compiled languages are... yet conservatively this is a "thin reed" to stand on.

What does this mean about the myriad of GPL javascript out there intermingling with non-GPL and proprietary javascript within browsers visiting script heavy websites everywhere? It's a dog's breakfast of legal issues.


Also, see here: http://jacobian.org/writing/gpl-questions/
http://www.linuxjournal.com/article/6366
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11345
Joined: Tue Mar 25, 2008 8:40 am

Re: Autonomous F-14b demo

Postby pygmyskunk » Tue Nov 08, 2011 4:04 am

Yikes. This is totally not how I expected this thread to go ....
pygmyskunk
 
Posts: 25
Joined: Tue Feb 15, 2011 3:47 pm

Re: Autonomous F-14b demo

Postby curt » Tue Nov 08, 2011 4:02 pm

Some fair issues to consider. I'll pull the demo until I can have a chance to review the situation more thoroughly ...
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: Autonomous F-14b demo

Postby Tuxklok » Tue Nov 08, 2011 4:26 pm

Personally I don't see how trying to make the core nasal api viral as such would be beneficial to the project in any fashion. Unless your doing the most basic of content, such as a basic scenery model with very simple or no animation, it is virtually impossible to not use some of the nasal api. If the core nasal modules were to be considered viral in such a way that using their api in any fashion meant you also have to license your content under gpl, then you have effectively cut out any chance of users being able to decide on a license of their own for their content. That is not really a good thing if you ask me, would be better to make the core nasal modules as GPL with runtime exception, link exception, use exception, whatever it would be called.

Just my opinion...it's not up to me of course.

cheers
The Austria Scenery Project - more info
fg-scenery-tools - gitorious | videos
fgcomgui - Open source, cross platform, gui front end for fgcom. more info

More random musings and doings can be found on my personal site. (work in progress)
User avatar
Tuxklok
 
Posts: 1326
Joined: Tue Apr 21, 2009 6:04 pm
Location: Orlando, FL
Callsign: Tuxklok / N1292P
OS: GNU/Linux


Return to Aircraft

Who is online

Users browsing this forum: Google [Bot] and 6 guests