@lord.didger did you solve your problem? I am running into the same issue. I followed the instructions posted for the px4_simple_app module (and renamed it) but I can not include it into the EXAMPLES section of the CMakeLists.txt fle. I get the same error as you posted.
Well, okay, thanks anyway Maybe someone else has a solution?
I have moved the module vtol_att_control out of the tree and into a new Component Folder next to the Firmware. It looks as follows:
Firmware
…
Components
src
CMakeLists.txt
modules
vtol_att_control
CMakeLists.txt
… (all the original files from vtol_att_control)
I removed vtol_att_control from px4/sitl/default.cmake because I think the module is now already defined as external module. I checked the part about external modules in the main CMakeLists.txt of the Firmware and it seems to find and add my external files correctly.
The issue is now, that files like the FixedwingAttitudeControl.cpp can not find #include <vtol_att_control/vtol_type.h> anymore.
Hi @JulianOes,
I copied over the whole vtol_att_control folder with all files.
I experimented with the main CMakeLists.txt from the Firmware folder, but I am still not finding this reference. Here is the part of the CMakeLists.txt which I modified a bit:
So basically I removed the module folder between (I didn’t check if it works with it too, but I ran in a lot of problems having it). The CMakeLists.txt in the Components folder looks like this:
@JulianOes I have a couple follow up questions to make the our-of-tree module work in VSCode:
I would like to exclude the original vtol_att_control (inside Firmware) from the search path when looking for references, so only the files which are out-of-tree are listed in the results. I added in the .vscode/c_cpp_properties.json file following lines (like here mentioned link)
These settings do not exclude any files from the search. But If I add these locations to the appropriate file exclude and search exclude section in the vscode setting options, I can exclude the files from search (Ctrl+Shift+F) but still not from the reference search. Is there a way to solve this?
How can I include the EXTERNAL_MODULES_LOCATION= variable during compilation into VSCode? I coudn’t find a working option. For now I use build it through the terminal the first time before using VSCode to build.
I tried to start gazbo tiltrotor in the debug console (SITL (gazebo standard_vtol)) but it gets stuck after building. I adjusted the folder structure in .vscode/launch.json and .vscode/tasks.json . Does the gazebo debug start depend on some other files which I need to change? Debug with the SITL (shell) works with the adjusted folder structure.
How to run the unit tests from an external module?
Although the external module structure worked for me as documented, it was inconvenient with no clear benefits. I could imagine some scenarios, but I was only adding a PX4-architecture-speecific module, not shared anywhere else. As such, my fork has my additional modules in same repo as the rest of PX4.
You might be making some slight misstep for external modules scheme, but perhaps you can just not have the problem at all and add your modules to your forked repo.
As for the purpose of the feature, I don’t honestly know. I was compelled to try it because someone else thought it would be somehow useful. I found no benefit and only overhead by doing something special and off the normal workflow.
Since then, my module sits in our fork under src/modules, just like any other module. There are even some benefits to this approach. I could not figure out how to add new uorb topics in some out-of-tree manner, for example. It is easy to do in-tree.
I just thought I’d share about my wasted effort in case it would help you avoid such. YMMV and you may have a better use case, than I did.
I misspoke about outside messages. I should have said publish to same topic type with different name. Inside tree it is a simple as adding an “alias” in the msg file.
I still have the external module repo and will report back if I can make it work in v1.12 workspace.
@guglielmodev, I suddenly recalled that perhaps - is unacceptable by some actor in this toolchain (CMake?). ISTR having that problem and just got lucky, somehow. Try using external_modules instead of external-modules.