mavlink generate on win7?

[Tom Pittenger]

Has anyone else tried generating mavlink recently on Windows? I'm getting this message when running generate.sh:


------------------------

$ ./libraries/GCS_MAVLink/generate.sh
Removing old includes
Generating C code
Traceback (most recent call last):
File "c:/Users/tpittenger/Documents/GitHub/mavlink/pymavlink/generator/mavgen.py", line 11, in <module>
from . import mavparse
ValueError: Attempted relative import in non-package

----------------------

It deletes the /include/0.9 and /1.0 folders and seems to regenerate them but not with the contents of my newly added item in common.xml

I'm running c:/Users/tpittenger/Documents/GitHub/arduplane ./libraries/GCS_MAVLink/generate.sh

and the pymavlink/generator is in my path. Am I missing something?

-TomP

[Daniel Frenzel]

Comparing GCS_MAVLink with other parts of the library indicates that it is in a bad state.

I mean, regarding both the software and the implementation. 

I just hope that it is better tested than it looks like, because this aircraft can be lethal.   

[Daniel Frenzel]

*software design

[Bill Bonney]

The mavlink library is auto generated from xml definition see http://github.com/mavlink

Feel feel to post constructive and specific criticism to the parts of the code you would like to see changed, or even make the changes and submit a pull request.

Thanks.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Pittenger]

Hi Bill,

I'm trying to generate a new command on my personal branch and I get the error when trying to generate the new mavlink files. I don't want to submit pull requests if I'm just fooling around. I can't even compile the current MAVLink files from master. I'm either using generate.sh wrong or there's a problem. I'm doing this from the px4 console.

I'll repeat my question:

"Has anyone else tried generating mavlink recently on Windows?"

-TomP

[Bill Bonney]

Sorry Tom, my comment was for @Daniel. Since I’d like to know specifically the issues he’s raising. I’m in no doubt things can be improved, but just saying ‘it’s in a bad state' is pretty useless. 

I have recently built mavlink libs using xubuntu with no problems using the instructions as posted on the github site.

my command I used was 

cd ~/mavlink

python -m pymavlink.tools.mavgen ./message_definitions/v1.0/ardupilotmega.xml --lang Java --wire-protocol 1.0 -o ~/out/MAVLink/

Sorry I cannot help with the windows version. 

Bill.

[Daniel Frenzel]

No like, that I wasn't trying to get in patches regarding 

- virtual function usage

- noting/removing compile errors

- template classes with fixed types/operators

- ..

[Daniel Frenzel]

Some issues which have been reported by me was e.g.:

https://github.com/diydrones/ardupilot/blob/master/libraries/AP_Limits/AP_Limit_GPSLock.h

Where is "GPS.h"? 

The excuse might be that this class isn't used anywhere else and the mistake is hidden by the current build system.

Why I should write patches, which anyway get never accepted? 

Something constructive at the end: 

https://github.com/diydrones/ardupilot/blob/master/libraries/GCS_MAVLink/GCS.h

It would be smart to make defined but not implemented functions virtual and include the generation from the xml files into the build process. 

Putting a partially implemented class into the library and implement some functions in the firmware is the opposite of what's suggested in most software projects. 

[Daniel Frenzel]

Reported two month ago and still not building

Not constrictive enough?

https://github.com/diydrones/ardupilot/issues/1899

Maybe I should add that you would notice such build mistakes, if the build system would be changed.

Another consequence is that the amount of untested code scales usually with the amount of dead code. 

[Tom Pittenger]

I've seen build systems use a "make all" type arg to build everything including all generated code such as MAVLink. Perhaps the make clean command could wipe the mavlink include folder(s) and the normal build functions would check for an empty or missing include folder and auto-run generate the mavlink using the usual method. That way no one really needs to know about how to compile mavlink, they can just clean and build and it magically happens.

[Tom Pittenger]

In an effort to hijack this thread further, I'd like to comment on the "constructive" stuff.

In open-source, reporting stuff is only half of it. Developers typically work on what they want to, or have to, work on and usually not not things other people tell them to work on. If this is something that you think should get fixed, and you have the know-how to do it, then the truly constructive thing is to fix it yourself and submit a pull-request so the ArduPilot Gods can easily apply the fix. Now, if the ArduPilot Gods are too busy to merge in pull-requests then that's a different problem.

-TomP

[Daniel Frenzel]

Okay it gets off topic. Just an example, look at this tiny class https://github.com/diydrones/ardupilot/blob/master/libraries/Filter/LowPassFilter.h. 

Once I submitted a patch for a proper template implementation, to make it a little bit more nice. 

The result was likely: "Well, but always using floats in a template class is okay, and I give a fuck that some people may want to use a vector from AP_Math if calling T LowPassFilter<T>::apply(T sample)".

Another mistake I still remember is that somewhere (very likely) a wrong rounding function is used in your project which may result in problems, and so on and so on. 

So after some month I removed the commit. 

Instead, I used my fork for things which are useful for me. 

I cannot maintain a build system and changes on every part of the library, which may get changed or deleted anyway sooner or later. 

I understand that it may sound a bit rude, but can you honestly say GCS_MAVLink doesn't need a reconsideration?

Is it really nice for you how it is implemented at the moment? I would say: No.

My last suggestion about the (at least for me) questionable implementation thing was ignored, like my suggestion to circumvent.

Unfortunately for me, I either have the option to just skip this part from cmake build process, AP_Limits or GCS_Console (because it's not independently compiling because of the missing implementation, bugs, headers, ...) or to provide a patch. 

At the moment I see no reason to invest a lot of time into a clean solution, which wouldn't be accepted like my small patch for the filter module, or other bugs. 

It would be a waste of time for me and the one who ignores that patch. 

Another example: The linux code threw a segmentation fault, if there is no NAVIO+ board connected to the raspberry. 

I wasn't testing recently, but chances are high it's still like this. What I mainly, see is that this project is growing relatively fast and more and more boards are "supported".

However, with increasing complexity I think field tests would become more and more important. 

In general one could nowadays also use asserts and stuff.

 

I mean these copters ARE dangerous and expensive and no one can neglect this.

Is there no any feeling of pushing the standards a little higher? I mean step by step. But honestly, I just see people crying when you say things like they are. 

Just take a look at these classes yourself and tell me how awesome they are...

Best, Daniel

[Bill Bonney]

>I understand that it may sound a bit rude, but can you honestly say GCS_MAVLink doesn't need a reconsideration?

For the record, i said "I’m in no doubt things can be improved, but just saying ‘it’s in a bad state' is pretty useless. "

Now I understand what the issue here is, and I think it's a good time to discuss who has actual permission to merger PR into the code. Since at the moment it's a bottle neck, and with 84 pull request outstanding, it really needs addressing.

The other problem is removing the Arduino craziness in the build system form the project, as that is now just a PITA, and adds no benefit to the future of the project. If anything it's holding it back from best practices in software development.

Let's start a new thread here to discuss further. https://groups.google.com/forum/#!topic/drones-discuss/Hdo9sGv5X10 PRs not going into ArdPilot has become a big problem

Bill

[Tom Pittenger]

Thank you Bill for the new thread, and thank you Daniel for speaking up about it. It's a topic that is in dire need of attention.

Meanwhile... about that auto-MAVLink generation after a "make clean". Any thoughts anyone?

--

[Daniel Frenzel]

As the MAVLink project uses cmake and I am currently working on a cmake based build system, 

I would suggest to write a cmake build script for this task and add it here: https://github.com/dgrat/ardupilot

The current sh script is not portable and I am concerned about the safety to delete directories within a library folder with unix commands.

On the other hand, I already played with the thought include such an autogen cmake script into my fork and to delete the entire GCS_MAVLink together with AP_Limits, .. 

from my fork, if no change in the main fork will happen. 

Depends on the likelyhood to get a cmake build system ever included into the project.

[Daniel Frenzel]

Okay the cmake build script at the github site is buggy :D
In the mean time I reorganized GCS_MAVLink: https://github.com/dgrat/ardupilot/blob/master/libraries/GCS_MAVLink/GCS.h
I think I will also make a brief fork of the protocol and fix the build script :D