No such file or directory <uORB/topics/sensor_combined.h>

I am compiling an app that will use PX4 headers. This is a two-part question. Feel free to answer one or both.

My app is a test app. it is structured as a combination of the ATLFlight HelloWorld (GitHub - ATLFlight/HelloWorld: Sample program to show how to run code on Hexagon DSP. Refer to the documentation in ATLFlight/ATLFlightDocs for information on how to install the required prerequisites.) and the PX4 HelloSky apps. I am including the PX4 header directories so that I may use uORB. I am then building this app in a way that modifies the ATLFlight HelloWorld cmake/makefiles. Upon building (see ATLFlight HelloWorld app for more details on the build process), I am met with the error:

fatal error: uORB/topics/sensor_combined.h: No such file or directory #include <uORB/topics/sensor_combined.h>

This file is not in the PX4 Firmware source tree, so I trust that this is not a completely weird error.

The first question is: does building this app using PX4 headers assume that the px4 app is running and that this app will run on top of it? I.e. will it not work if I merely use the PX4 headers and don’t build with some extra stuff specified by building a PX4 app as a PX4 module?

The second question is: how can I include the file <uORB/topics/sensor_combined.h>? I see that the sensor_combined.msg file is in the msg directory. Is this similar to ROS, where messages are auto-generated into source code at some point in the build process?

The dude

Sensors_combined is a uORB topic. The uORB topic headers are generated automatically from the message definitions in /msg. Hence they are not in the source file tree.

The topic header files (and topic source files) are generated during the make process, before linking, and are placed in a folder in the build directory. If you build the software with make, according to the docs, the error you are seeing should not happen.

Perhaps you modified the make files in such away that the message gen is not happening?

I am not using the make files in the PX4 Firmware directory. I am using a modification of makefiles from the ATLFlight HelloWorld app. Thus, you are correct, the message gen is not happening.

I will try using the docs, but currently information is only available to add a module for the NuttX implementation of PX4.

My first question still stands: does building this app using PX4 headers assume that the px4 app is running and that this ‘module’ will run on top of it?

I believe the answer to your first question is yes. The uORB messaging system handles IPC in the PX4 software stack, so if you include PX4 headers it seems likely that those topic headers will be included somewhere. Hence I don’t think your code will build without using the px4 build process. Do you need any PX4 headers? If not, why not just remove them?

There are PX4 build configs for eagle boards (Snapdragon dev kits?) which I believe are built for the hexagon dsp chip. Perhaps you can add this ATFL app to the config_module_list in one of those build configs in this directory, and then run make from the PX4 firmware root directory. That would at least generate all the topic headers.

Sorry I can’t be of much more help, since I’m only working with Pixhawk hardware.

I am trying currently to place in my module on top of px4 for posix_eagle_default and posix_eagle_legacy_default. Thank you for your help my dude.

Any idea where the compilation errors:

error: 'MAV_PROTOCOL_CAPABILITY_MAVLINK2' was not declared in this scope
error: 'MAVLINK_MSG_ID_HIL_ACTUATOR_CONTROLS' was not declared in this scope

This while trying to compile with make posix_eagle_default, although this is the case when trying to compile with make posix_eagle_legacy_default and make px4fmu-v2_default as well.

I see that the macro MAV_PROTOCOL_CAPABILITY_MAVLINK2 is defined in the mavlink/message_definitions/v2.0/common.xml. It seems as though it is not being generated into a .c macro, though.

If you think that this is instead better suited for a different question thread, then let me know.

The mavlink messages are not autogenerated, rather they need to be manually generated before building the code. Basically every time the message definition xmls are changed you need to regenerate the sources manually.

You should clone the mavlink repository one level above your firmware directory, then use the script to create C headers and sources from common.xml, selecting firmware/mavlink/include/mavlink/(version) as the output directory of

Welcome to PX4 :slight_smile:


Actually, if I recall there should be C sources and headers in firmware/mavlink/include/(version) already. That folder is a git submodule of the mavlink c library. If the sources are not there, you may need to do a git submodule update --init --recursive in the firmware root directory. Also manually generating should work.

This is correct, there are mavlink c sources in the mavlink/include/mavlink/<version> directory. However, they aren’t being used properly. For example, in the file src/modules/mavlink/mavlink_messages.cpp, the compiler isn’t able to find MAVLINK_MSG_ID_HIL_ACTUATOR_CONTROLS or MAV_PROTOCOL_CAPABILITY_MAVLINK2, which are defined in
<mavlink_c_source_dir>/common/mavlink_msg_hil_actuator_controls and <mavlink_c_source_dir>/common/common.h respectively.

I’m not sure why these files aren’t being included. In the cmake/common/px4_base.cmake file, the mavlink/include/mavlink directory is included. Similarly, in the cmake/posix/px4_impl_posix.cmake file, the same directory is included. I have tried amending these added_include_dirs, as they are called, to mavlink/include/mavlink/v2.0 or mavlink/include/mavlink/v2.0/common to no avail.

I will continue searching for an answer in the meantime, but you have been very helpful thusfar.

did you figure this out? I’m having the same problem