Hello there!
I don’t know which topic to put this under, so I am adding it here. Although this might be a somewhat niche problem, I thought I will write about it anyways in case other people will experience this problem to and need a way to fix it.
The Issue
My situation was the following:
I am working on a SITL Simulation of a quadcopter using Matlab and PX4. At some point in the process, I have to send a uORB message from one Simulink instance (lets call it ‘Controller’) to another instance (lets call it ‘Plant’). The issue was quite unique in the sense that, running this specific setup is standard (like the Monitor and Tune PX4 Host Target Flight Controller with Simulink-Based Plant Model example from Matlab), but on one of the computers I use to work on this problem I had the unique problem of this communication not being sent from the controller instance, to the plant instance.
Investigation
On any other computer I tried, this setup would just work. The interesting thing is then, it is not a Matlab issue as far as I can see, however I’ve also comminated this to the aswel just in case. The specific issue boiled down to the following. In WSL (Windows Subsystem for Linux) I ran the the following command through the terminal while running the simulation:
sudo tcpdump -ni any 'udp and (port 14580 or port 14540)'
which allowed me to see the communication that occurred on the simulation ports (see Simulation (PX4) for more information on this), here the interesting line is:
lo In IP 127.0.0.1.14580 > 127.0.0.1.14540
which is wrong. It should connect to some IP adress that the PX4 instance that automatically pops up when running "Monitor and Tune" in Matlab:
The lines:
INFO [init] PX4_SIM_HOSTNAME: 172.xx.xxx.xINFO [simulator_mavlink] using TCP on remote host 172.xx.xxx.x port 4560
Tells you the IP that it should be connected to, it should look like:
eth0 Out IP 172.yy.yyy.yy.14580 > 172.xx.xxx.x.14540
(I am not an expert in IPs and protocols, so I hope it is clear that 172.xx.xxx.x is the same as above, and the one with y’s is a different one, I am unsure if they can be the same, in my case they weren’t).
The solution
Essentially what happens is that, some where in some configuration or setup script or something went wrong. The issue is that in the following directories (I am posting with nano so you can get to code that needs change):
~/PX4-Autopilot$ nano ~/PX4-Autopilot/build/px4_sitl_default/etc/init.d-posix/px4-rc.mavlink
and
~/PX4-Autopilot$ nano ~/PX4-Autopilot/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink
there is a line (same line for both)
mavlink start -x -u $udp_offboard_port_local -r 4000000 -f -m onboard -o $udp_offboard_port_remote
which is missing -t 172.xx.xxx.x for both. So the solution was to go into both directories and change that line to: mavlink start -x -u $udp_offboard_port_local -r 4000000 -f -m onboard -o $udp_offboard_port_remote -t 172.xx.xxx.x
this fixed the issue and now it works every time.
Epilogue
I will admit I am not the most technical knowledgeable on this subject, so answering why this works, or why it happend, or anything that, I am unfortunately not a big help with.
I mainly write this here since I could imagine people would run into a similar problem, either people using Matlab or something completely different to run simulations with PX4, and having a possible solution to a really annoying and confusing problem is always nice. Ideally, someone way more knowledgeable on the issue could maybe figure out why this happend, and how to solve it. Maybe it is a MavLink issue, maybe it is a script issue, maybe I am just simply unlucky.
I hope this was of some sort of help to the community, or someone else. :))