IDE For Ardupilot development

[Nitay Megides]

Hi all,

I'm curious about the development environments of the devs in this group. 

Are you guys using some kind of IDE for development? Which one?

More specifically, I'm looking for an IDE to work with on Ardupilot for some more code insight (Find Definition / Declaration, Find all references, define values, and things like that)

Did anyone manage to create such a project on any of the C++ IDEs?

Thanks

Nitay

[Linus Casassa]

The official documentation is here: http://dev.ardupilot.com/wiki/code-editing-tools-and-ides/

I like very much QtCreator. There is a cmake version of the code but it is quite outdated: https://github.com/dgrat/ardupilot/tree/cmake_build . Just open CMakeLists.txt in QtCreator. Or you can create auto generate a .pro including all the sources files but you will not be able to compile with QtCreator, you should use the makefile.

Good luck,

Linus

--
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.

--

Linus Casassa
+56 9 97776941

[Tom Pittenger]

I use Eclipse. I know some devs here use notepad++ and it blows my mind that they use it as an IDE.

[Randy Mackay]

I also recommend Eclipse.

-Randy

[Robert Lefebvre]

I use Notepad++ as a text editor, but Eclipse as the IDE. ;)

[Andy Little]

Code::Blocks for me

regards

Andy

[Nitay Megides]

What do you guys think about adding a 'projects' folder to the ardupilot code with the project files for the different IDEs?

[Daniel Frenzel]

Actually, I still would like to see AP using cmake.

[Nitay Megides]

I also think we should continue using make for compilation.

For editing the code though - IDEs make it much easier to navigate the code. I think adding the project files for IDEs will ease the code learning process for new developers

[Daniel Frenzel]

I updated the cmake build files. 

Still, it will just work for Linux, but I think sooner or later it will also for PX4

Would be nice if someone else could add some scripts. 

Cmake is really not so bad and even the PX4 fligt stacks has some cmake files

[Randy Mackay]

 

     Re the project files, we can add them if someone wants to create a PR for it.  Maybe some others could try the project files to ensure they work before they’re committed.  The key thing to look out for though is that it the project files don’t have hard-coded file paths that will make it not work for anyone but the person who created the file.

 

     We’ve actually gone though one previous (failed) iteration of creating project files for eclipse.. I’m sure it’s possible to do but it’s slightly more difficult than it might appear.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Nitay Megides
Sent: 27-Dec-15 3:05 AM
To: drones-discuss
Cc: li...@lin.cl
Subject: Re: [drones-discuss] IDE For Ardupilot development

 

I also think we should continue using make for compilation.

[Lucas De Marchi]

Em 26/12/2015 11:44 PM, "'Randy Mackay' via drones-discuss" <drones-...@googlegroups.com> escreveu:
>
>  
>
>      Re the project files, we can add them if someone wants to create a PR for it.  Maybe some others could try the project files to ensure they work before they’re committed.  The key thing to look out for though is that it the project files don’t have hard-coded file paths that will make it not work for anyone but the person who created the file.

WAF has built-in plugins to generate the project files (and also cmake files). This means it's much easier to maintain than handwritten ones.

Lucas De Marchi

[Daniel Frenzel]

I don't like WAF, because the API was not really stable and changed with every release and the Python syntax for a build script is not very handy.

Additionally, I don't understand why WAF should be used to generate cmake build files. 

The stack WAF->CMAKE->make is ridiculous. 

[Lucas De Marchi]

On Tue, Jan 12, 2016 at 2:38 PM, Daniel Frenzel
<dgda...@googlemail.com> wrote:
> I don't like WAF, because the API was not really stable and changed with
> every release and the Python syntax for a build script is not very handy.
> Additionally, I don't understand why WAF should be used to generate cmake
> build files.

It doesn't need to, it builds just fine without converting to any
other build system. Converting to CMake might be ok if you have a dumb
IDE that supports only that.

> The stack WAF->CMAKE->make is ridiculous.

Unfortunately build systems which everybody agrees with don't exist yet.


Lucas De Marchi

[Andy Little]

.

I am currently working to get my toolchain easy to install on Windows. For Windows users WAF adds 2 extra dependencies.

Unfortunately, it seems to me that to try to simplify development , another 2 layers of complexity have now been added. Waf and Python

regards Andy  

[Daniel Frenzel]

I tried to add just simple cmake build files serveral times but the always was a strong opposition.

My original aim was to supply a GUI where you select the target (Linux/PX4, the board type, and the model type).

This worked for Linux very well and allowed the inclusion into an IDE. Additionally, the library was able to get linked separately, 

and it would allow third party applications being linked easily. 

I don't share the idea that the whole project is so much against the possibility to link the library independently just to make the life for others harder.

The old build system was protected for decades so much, just because no one here liked cmake syntax. 

The fact, that it was utterly broken was not that important. Now WAF is simply be preferred because no one needs to "learn a new syntax". 

At the end a simple build process becomes a installation torture and you may need a certain python version installed.

Can someone at least support a chart how the build-chain with WAF will now look? 

Will there be field test´support?

Will it be possible to link the library independently from the vehicle directories? 

Will there be support for modular tool chains?

Will there be a gui for users to select the target? 

Will there be a doxygen docu generated as well if desired?

[Andy Little]

If API changes with every release.. That is not exactly a great attribute of a build system LOL

On Tuesday, January 12, 2016 at 4:38:47 PM UTC, Daniel Frenzel wrote:

I don't like WAF, because the API was not really stable and changed with every release [...]

regards

Andy 

[Lucas De Marchi]

Waf is not a dependency... it only needs python. And this was already
becoming required since mavlink headers use python to be generated and
they will be generated on the fly. The old build system is still there
and will only be completely replaced when the new one has everything
needed (and instructions updated). So, there are no 2 layers of
complexity added... in fact we removed the need to have make for
example.

If it's stopping you from continuing your work, you can just add it to
the old build system (like you would be required to) and defer the
changes to waf so we do it when the build is complete.

Lucas De Marchi

[Lucas De Marchi]

On Wed, Jan 13, 2016 at 11:53 AM, Andy Little <airt...@gmail.com> wrote:
> If API changes with every release.. That is not exactly a great attribute of
> a build system LOL

this is just FUD... Don't be fooled by what others say.

Lucas De Marchi

[Lucas De Marchi]

On Wed, Jan 13, 2016 at 11:05 AM, Daniel Frenzel
<dgda...@googlemail.com> wrote:
> I tried to add just simple cmake build files serveral times but the always
> was a strong opposition.
> My original aim was to supply a GUI where you select the target (Linux/PX4,
> the board type, and the model type).
> This worked for Linux very well and allowed the inclusion into an IDE.
> Additionally, the library was able to get linked separately,
> and it would allow third party applications being linked easily.
> I don't share the idea that the whole project is so much against the
> possibility to link the library independently just to make the life for
> others harder.
> The old build system was protected for decades so much, just because no one
> here liked cmake syntax.
> The fact, that it was utterly broken was not that important.

Again... no one stepped up back in the time to do the complete job of
replacing the old build system. I was not even in the project when it
was added/removed.

> simply be preferred because no one needs to "learn a new syntax".
> At the end a simple build process becomes a installation torture and you may
> need a certain python version installed.
> Can someone at least support a chart how the build-chain with WAF will now
> look?
>
> Will there be field test´support?

You are missing the fact that is already there and with waf we added
support for unit tests (using gtest) and benchmarks (using
gbenchmark). The last one we build and bundle it ourselves since this
is the supported model from upstream. For gtest we have support to
link to a system library and will add support to bundle it as well
(ubuntu on version 15.04 stopped to ship the library as a system
library and we need the unit tests to work on PX4 which doens't have
dynamic library). See for example this recent PR:
https://github.com/diydrones/ardupilot/pull/3497

And with reliable numbers in the commit message:
https://github.com/ricardotk/ardupilot/commit/d4db3ab2a10a9abf6c926a21d961b6f7b7a9d116
https://github.com/ricardotk/ardupilot/commit/eca3a4ae906f8d031a5d56add34b8a3ab2f4e801
https://github.com/ricardotk/ardupilot/commit/d07a942553dc56ed358819f2e056decce9766904

And this is my wip adding some tests to a new utility library:
https://github.com/lucasdemarchi/ardupilot/commit/2c7ade311218ea4f689cf58285c0045b6bdf2d54
... with unit tests already

> Will it be possible to link the library independently from the vehicle
> directories?

yes, see above.

> Will there be support for modular tool chains?

not following here... there's support for any toolchain you want and
it's crosscompiled by simply given the toolchain triplet (like you to
crosscompile the kernel or other packages in linux)

> Will there be a gui for users to select the target?

not much my area, but it could be added

> Will there be a doxygen docu generated as well if desired?

If there are no doxygen comments in the code, there isn't much to
generate. And the last time we talked about this the decision was to
add documentation for new functions/methods, but doxygen format was
not required. The only thing that could revert this decision is if
someone step up to be a "doxygen maintainer", adding documentation and
ensuring it's right over the time.

Lucas De Marchi

[Daniel Frenzel]

Thanks for explanation Lucas. 

Nevertheless, 

> Waf is not a dependency... it only needs python. And this was already 

becoming required since mavlink headers use python to be generated and 
they will be generated on the fly.

Could be solved with cmake alone

> You are missing the fact that is already there and with waf we added 

support for unit tests (using gtest)

Could be solved with cmake alone

[Daniel Frenzel]

At least there is a progression in sight (in comparison to the old system).

Nevertheless, these guys seem to use cmake as well https://github.com/PX4/Firmware 

Wouldn't be integration not also more easy?

[Pierre Kancir]

Hi Daniel,

I agree with you and I would have prefer Cmake because of direct integration with IDE and ROS (and I use it more...) 

I got the same discution than you with Lucas. 

Here are the arguments he gives me : 

• Fact number one: we need something more maintainable than the current build system
• CMake does the job as well, but has some really annoying points: dealing with it additional DSL is a pain, particularly because of the way you create variables. One typo in the variable name and you will keep wondering why the build system isn't behaving as expected.
• Since waf is embedded in the repository, there's no additional dependencies to build the project. The only thing you need is python (and you already needed it for other things). Old versions of CMake are pretty terrible to work with; newer ones are better, but it also means additional packages to install. For me it's not a big thing due to the Linux distro I use, but for others (think RHEL, Debian, MacOS, Windows) it may be difficult to keep up with the requirements
• We are going to have integration with makefiles. This is something in the TODO list. There's nothing special in CMake in this regard and as for IDEs we can integrate it just fine with waf by using the makefiles. For example, waf even generates a clang database that can be used by clang-tools and some IDEs for code completion, refactoring, etc.
• It's not "another custom build system" - waf is a build system used in other projects as well, maybe just not the ones you are more familiar with. It's true that CMake is more used than waf, but we don't think that's a strong argument. We are also trying to keep custom things to a minimum and searching on other projects that use waf how they are solving things we need to solve.
• We really need something maintainers are willing to maintain... @tridge was very against CMake due to its deficiencies so we would need to have a "CMake champ" to keep maintaining the build system. If you look in git log you will see there has already been one attempt to convert it to CMake. However people stop contributing, switch projects, etc and we remain with a half-baked build system.

I think the most important point is the last one ! The project need someone to build and maintain the build system. There is a small team now so why not waf. ( I was crossing finger that they accept your cmake work ...)

By the way, I test it and it works. It is easier to debug than cmake for a begginner like me . And we could totally build a gui for configuration : it is just python variable ! 

[Chuk Rhodes]

A little more on topic, I tried a build configuration in Eclipse for waf, and that wasn't difficult. It shouldn't be much different for other IDEs.

Though as the only top level builds, it seems easier to just make custom build targets, no need to switch build configurations.

For windows it was slightly different than the readme, Build Command = python ${ProjDirPath}/modules/waf/waf-light
It runs, but gives up early :
14:22:05 **** Build of configuration waf for project ardupilot ****
python C:/px4/ardupilot/modules/waf/waf-light configure --board=pxf
Setting top to                           : C:\px4\ardupilot
Setting out to                           : C:\px4\ardupilot\build
Setting board to                         : pxf
Using toolchain prefix                   : arm-linux-gnueabihf
Checking for 'msvc' (C++ compiler)       : not found
Checking for 'g++' (C++ compiler)        : not found
Checking for 'clang++' (C++ compiler)    : not found
could not configure a C++ compiler!

Seems like it should be looking for prefix arm-none-eabi on Windows?

[Andy Little]

On Wednesday, January 13, 2016 at 6:00:38 PM UTC, Lucas De Marchi wrote:

On Wed, Jan 13, 2016 at 7:12 AM, Andy Little <airt...@gmail.com> wrote:
> .
> I am currently working to get my toolchain easy to install on Windows. For
> Windows users WAF adds 2 extra dependencies.
> Unfortunately, it seems to me that to try to simplify development , another
> 2 layers of complexity have now been added. Waf and Python

Waf is not a dependency... 

WTF ! I clone vanilla Ardupilot master and look in modules/waf/ is empty

Hey maybe you call it module if you enjoy wasting time on splitting hairs

So how you gonna build using waf if you dont have waf ?...

 Use make ... WTF !

$ make px4-v1

/bin/sh: line 0: cd: /c/cpp/aptemp/ardupilot/modules/PX4NuttX/nuttx/: No such fi

le or directory

// BUILDROOT=/c/cpp/aptemp/ardupilot/Build.ArduPlane HAL_BOARD=HAL_BOARD_PX4 HAL

_BOARD_SUBTYPE= TOOLCHAIN=NATIVE EXTRAFLAGS=-DGIT_VERSION="d989cf29" -DNUTTX_GIT

_VERSION="" -DPX4_GIT_VERSION="d989cf29" -DUAVCAN=1

Checking modules

module/PX4Firmware/.git missing - need module init

+ git submodule init

Submodule 'modules/PX4Firmware' (git://github.com/diydrones/PX4Firmware.git) reg

istered for path 'modules/PX4Firmware'

Submodule 'modules/PX4NuttX' (git://github.com/diydrones/PX4NuttX.git) registere

d for path 'modules/PX4NuttX'

Submodule 'modules/gbenchmark' (git://github.com/google/benchmark.git) registere

d for path 'modules/gbenchmark'

Submodule 'modules/uavcan' (git://github.com/diydrones/uavcan.git) registered fo

r path 'modules/uavcan'

Submodule 'modules/waf' (git://github.com/diydrones/waf.git) registered for path

 'modules/waf'

+ git submodule update

Cloning into 'modules/PX4Firmware'...

 

[Chuk Rhodes]

WTF ! I clone vanilla Ardupilot master and look in modules/waf/ is empty

$ git submodule init && git submodule update

also check the README_waf.txt for the alias to waf.
 

[Andy Little]

OK.

For my OSD project on Windows and For my Ardupilot fork, I need only MSYS/MINGW tools to build on Windows

I tried downloading the zip to get the dependencies but again waf isnt there,  I'm sure that e PX4 was one dependency not 4,  6 months ago?

So to build official ArduPlane px4 now I dont think I can't easily build now from the zip file without Git installed , Python installed?  Though my preferred OS is Linux, Am trying to get this easy to use in Windows. I ruled out Python being a good choice due to all the version issues for user. Git also is tricky on Windows since it is a fork of MSYS without some essentials.  so its another hassle for user to get all this working

hmm... I think my priority is now just to make some software I enjoy and get that buildable in Windows .Getting a port working was fun but This is all getting a little industrial for me :) Seems to have changed quite a bit in last 6 Months from hacking Arduino :o

regards

Andy

[Randy Mackay]

Andy,

 

     So for your board, it’s most like a px4 board?  I’m building on windows for pixhawk without much trouble these days and didn’t make any changes since all the waf build stuff went in.

 

     I’ve never been able to build for linux boards on my windows PC.  So if your board is more like a linux board then I imagine it will be a challenge.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Andy Little
Sent: 15-Jan-16 9:06 AM
To: drones-discuss
Cc: li...@lin.cl
Subject: Re: [drones-discuss] IDE For Ardupilot development

 

OK.

--

[Andy Little]

Hi Randy,

 I would hope the board  is closest to the old Arduino APM in spirit. And therefore a good fit to Windows users and not just power Linux users It may not be there yet, but that is what I would like to achieve. A  Simple stable  FC API ( Like Arduino. but using standard C++ build practises). A Simple stable build environment. A redesigned Build system, but ideally still using just GNU Make.  I decided also now to avoid Python and make this a good example of micocontroller programming in C++ ( There is plenty of Python around on Raspberry Pi, MicroPython etc etc if that is what people want.. )

regards

Andy

[Daniel Frenzel]

When there was still AVR support I tried to commit a few patch which would allow compilation with mingw.

Now th situation is different. Nevertheless, for many parts of the library the changes for compilation should be small. 

[Andy Little]

Hi Daniel,

Do you have a branch or patch or docs? Its all useful info :)

regards

Andy

[Daniel Frenzel]

Not anymore. AVR support does not exist anymore and the changes were derived from my first adaptations to make cmake compile with MinGW under windows.

This was the closed pull request: https://github.com/diydrones/ardupilot/pull/2099

No code anymore. deleted branch :D