Problems using Custom uORB Messages and Building PX4 SITL in WSL with MATLAB UAV Toolbox (v2024a, PX4 v1.14.3)

Hi @영준 김,

I read your comments and spent some time digging through MathWorks UAV Toolbox documentation and various PX4 community discussions. Let me address your questions in chronological order.

Regarding your first question about custom uORB messages, this is unfortunately a confirmed limitation in the current UAV Toolbox implementation. The documentation explicitly states that adding custom uORB topics will break the Connected IO simulation support. This happens because MATLAB's Connected IO uses a pre-generated message registry that maps MATLAB buses to PX4 uORB topics, and when you add custom messages at the firmware level, this mapping doesn't exist. The limitation persists in the latest versions including 2024b. However, custom uORB messages do work properly when deploying to physical Pixhawk hardware, just not with Connected IO simulation. For workarounds, you have several options: you can restructure your controller to use existing standard uORB messages like vehicle_attitude_setpoint or vehicle_rates_setpoint for testing in Connected IO, then add custom messages later when deploying to hardware. Alternatively, you could use MAVLink custom messages instead of uORB messages, which works with SITL and doesn't break Connected IO, though it requires more complex setup. A third option is to use the ROS 2 bridge that PX4 v1.14 supports, where you can define custom messages in ROS 2 and communicate through MATLAB's ROS 2 Toolbox.

For your second question about the WSL build issue, the root cause is that when you manually run make px4_sitl sihsim_quadx in WSL, you're building standard PX4 firmware without the px4_simulink_app module that MATLAB generates specifically for your Simulink model. You mentioned seeing two command windows when Connected IO works successfully, one for jMAVSim and one for the PX4 SITL process with the 10040 airframe, which is the expected behavior. Connected IO works because it automatically generates this bridge module, injects it into the PX4 source tree, builds custom firmware including this module, and establishes proper network communication between Simulink running on Windows and PX4 running in WSL. When you build manually, none of this happens. The px4_simulink_app module might show as running in the PX4 console, but it's not receiving data from Simulink because the network connectivity isn't properly configured. The official supported method is to let MATLAB handle the entire process rather than manual WSL builds. After building your Simulink model with the PX4 Host Target configuration, you should use MATLAB's launch function rather than manual make commands. If you absolutely need manual control for debugging purposes, you need to ensure several things: first, the px4_simulink_app module must be generated by building your Simulink model in MATLAB, second, you need to set the PX4_SIM_HOST_ADDR environment variable in WSL to your Windows host IP address, third, you must configure Windows firewall to allow incoming connections on TCP port 4560 and UDP ports 14540 and 14580, and fourth, your Simulink model needs proper network configuration to connect to the WSL IP address.

Based on your specific situation with PX4 v1.14.3 and MATLAB 2024a, here are my recommendations. For immediate development and testing, use Connected IO with standard uORB messages only and redesign your custom controller to fit within existing PX4 message types, which gives you rapid iteration with full MATLAB integration. Use messages like actuator_controls, vehicle_local_position_setpoint, or debug_vect to carry your custom data during the development phase. Let MATLAB manage the PX4 build and simulation process entirely through its deployment system rather than trying to manually run commands in WSL, as the toolbox is specifically designed to abstract away this complexity. When you're ready to test custom messages, skip SITL entirely and deploy directly to physical Pixhawk hardware where custom uORB messages are fully supported. For long-term development, consider transitioning to the ROS 2 bridge architecture since PX4 v1.14 has good ROS 2 support and this approach provides better flexibility for custom communication without the limitations you're encountering. The key insight is that MATLAB's UAV Toolbox provides a managed environment through Connected IO that handles all the integration complexity, and when you step outside this managed environment with custom messages or manual builds, you hit the limitations of the abstraction layer. You either work within the system's constraints for simulation or go fully manual for hardware deployment.

Your English is excellent and your problem description was very clear, which helped identify exactly what's happening.