I encountered error during compilation:
fatal error: include/mavlink/v2.0/ardupilotmega/version.h: No such file or directory
I used to solve this problem by copying Build.ArduCopter from somewhere else.
But now that this happens again, I wonder if there is a more decent solution?
think about these advice: "when I tried to “pip install lxml” it gave me error
Failed building wheel for lxml Running setup.py clean for lxml Failed to build lxml Installing collected packages: lxml Running setup.py install for lxml … error … error: command ‘i686-linux-gnu-gcc’ failed with exit status 1
But when I tried to build ardupilot using make px4-v2 it worked.
When I tried to build ardupilot in windows using px4-toolchain eclipse, it gave me the same error
c:/Users/Salahuddin/ardupilot/libraries/GCS_MAVLink/GCS_MAVLink.h:27:56: fatal error: include /mavlink/v2.0/ardupilotmega/version.h: No such file or directory"
consult more at :https://www.bluerobotics.com/forums/topic/problems-installing-mavros-in-ros-package/
Honestly I was digging into pymavlink/generator directory and ran the mavgen.py script, which reported error.
It led me to install python package ‘future’ and ‘lxml’, and I did so.
But I guess afterwards I didn’t try compile again and came to ask for help LOL…
The generator works fine now. I’m just curious that over one year ago I had encountered this problem, and I guess ‘future’ and ‘lxml’ were not introduced by then. So what could be the cause?
The use of lxml is quite new because we try to get python3 support and the old parser was quite oudated. So Future and lxml were added.
If you are on windows, use the lastest toolchain provide by APM, it already includes lxml .
On linux, following the wiki should work on all debian based distribution.
Thanks @khancyr and @rmackay9 for your kind reply. I work on linux and I‘ve solved the problem.
I’m just curious:
Has that ‘library’ folder in Build.ArduCopter also been generated by the submodule pymavlink since the very beginning?
No pymavlink only generate mavlink message and common tool to use it.
The library folder correspond to ardupilot library folder. So in build it it where all library compiled filed a placed by Waf .
The fact that it failed with fatal error: include/mavlink/v2.0/ardupilotmega/version.h: No such file or directory is related to some missing file.
If you read the compilation output you could see at what line it failed. As pointed Geogre, it should be at ardupilot/libraries/GCS_MAVLink/GCS_MAVLink.h:27:56 .
This is the library in charge of using mavlink in ardupilot and at line 27 you can see that it need #include “include/mavlink/v2.0/ardupilotmega/version.h” that is a file generated by pymavlink. So if pymavlink failed to generate his files, ardupilot will failed to build too.
Yes I just meant to ask about the generated mavlink related header files. And I understand the error.
Maybe I should have referred to the include/mavlink/v2.0 folder rather than libraries?
But GCS_Mavlink/include is all I have in Build.ArduCopter/libraries.
I think you are talking about the product from waf, and I’m talking about the product from make?
I don’t usually use Make but if I remember correctly what is in that folder is the result of running the generator.
I ran into this problem a couple times when trying to create some new messages in ardupilotmega.xml. Most of the confusion came from the folder names v0.9, v1.0 and I kept thinking what/where is v2.0.
As far as I’m aware the mavlink protocol (and pymavlink) only allows up to a 255 byte payload per packet. I think some of the message definitions may be larger for ardupilot so they added a wrapper around pymavlink to be able extend the protocol for larger messages. In doing that, the output from pymavgen is moved and changed to the v2.0 folder created during the build. However, if pymavgen fails to execute properly (say to an xml syntax error) then pymavgen exits with no output and the toolchain script continues to search for the header in v2.0 which doesn’t exist.
Just a warning to anyone changing message definitions, open your message definitions with explorer just to check they have correct syntax. Don’t rely on the toolchain to tell you there’s problems with your message definitions. Otherwise you’ll end up like me being confused about a non-existent folder and alternative mavlink protocol all over a silly typo. Lesson learnt for me!
Edit: Actually, it might not be the message length, but support for 64 bit data types as to the reason the output is changed and moved.
What board, build system and version are you using?
Waf should do the right thing and stop the build since some months ago. Make started to do the right thing very recently. It was doing the wrong thing because of a problem in the mavgen tool on Windows, which would sometimes crash the Python interpreter… Ignoring the error was a bad workaround. And now the workaround is to ignore the error only if it comes from a signal, which should happen when the interpreter crashes.
I get this error:
*** No rule to make target ‘px4fmu-v2_APM’. Stop.
Use make px4-v2 maybe ?
When you got an error it is better to explain what command you used, on what system and a little more than the last line you got ! Otherwise it will be difficult to help you ! Think like your are going to the doctor !
I used make px4-v2 on windows on the px4console
in the end I get a 40 kb .px4 file and a 900 kb .elf file, none of them upload on a pixhawk board…
Im compiling Arduplane 3.7.1
maybe it’ll work with the new .waf way of compiling?
I can’t get it and have tried many times from the link to the latest toolchain: http://firmware.ardupilot.org/Tools/PX4-tools/pixhawk_toolchain_installer_latest.exe.
Is there something wrong?
I can download it without any issue. Are you able to open http://firmware.ardupilot.org/Tools/PX4-tools?
However, if pymavgen fails to execute properly (say to an xml syntax error)
then pymavgen exits with no output and the toolchain script continues to
search for the header in v2.0 which doesn’t exist.
Can you confirm you were using the “make” build system (as opposed to
A patch has gone in recently which should cause make to fall over when
mavlink header generation fails. Are you compiling latest master?