Unable to run VSC SITL debugging

[asimopunov]

To Reproduce
make px4_sitl gazebo_tailsitter
click on green play button

Error

Additional context
Forked firmware from be9f125 upstream
"mavsdk_tests: raise timeout for czspawn"
Commit on Apr 3, 2020

Forked sitl_gazebo from a928906 upstream
"Fix race condition in gimbal controller"
Commit on Apr 3, 2020

Ubuntu 18.04

[dagar]

Thanks for reporting, I'll take a look.

[ThomasRigi]

@dagar

I'm experiencing the same / similar issue. For me it's the standard_vtol that I'd need but isn't working. Current master, Ubuntu 18.04.

I got 59 problems:

...

and this popup:

If I click on debug anyway, the PX4 shell starts (mostly like normal)

but hangs on waiting for the simulator:

Here's the gazebo terminal:

When I stop the debug session and try to launch another one, I get this:

and gazebo seems to get killed straight away:

(How can I kill the PX4 daemon manually? So far I had to resort to a reboot of my laptop, but this is not very efficient...)

I hope this can help you to find the underlying problem. Additionally, I can tell you that commit d32a80d still works to launch VSC debugger (but doesn't contain the bug I'm hunting...)

[notoriou5]

Having the exact same issue as @ThomasRigi .
Very nicely explained, nothing to add

[notoriou5]

Any progress on this topic so far? It still happens to me in the v1.11.0-beta2 Version. Any clues where to look for the reason behind this issue?
Thanks
EDIT: also the current master!

[ThomasRigi]

I uninstalled VSC completely (including settings and extensions), updated the toolchain and reinstalled VSC with the workspace recommandations, but it still doesn't work.

[notoriou5]

@ThomasRigi I found a workaround which works for me, maybe it does in your case as well. After you started the debugger through VSCode and it gets stuck waiting for connection, start in a separate terminal a gazebo sim (make px4_sitl gazebo_iris). After pressing the play button in the VSCode debugger it works as normal (as far as i tested at least). Hope it helps

[ThomasRigi]

@notoriou5 Thank you for sharing the workaround! It also works with the HEADLESS=1 option to have the simulator up faster :)

It's still not as convenient and there still are all the jagged red lines complaining about stuff being undefined etc but it helps greatly with debugging 👍

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[dagar]

Could you give #15745 a try?

[ThomasRigi]

So with #15745 running locally, the first time I start the debugger and select the type it hangs on

But then the drone type selector pops up again and when reselecting the model it starts working. :)

Also, all the broken "undefined identifiers" and other warnings/errors and red underlines have disappeared and I can again easily navigate through the code :D Looking forward to have this merged into master 👍

With the Dev Container I get the following error(s), but I don't really care as I now have it running locally:
`> Executing task: make px4_sitl_default sitl_gazebo <

[0/9] git submodule Tools/sitl_gazebo
[5/9] Performing configure step for 'sitl_gazebo'
CMake Error: The current CMakeCache.txt directory /workspaces/Firmware/build/px4_sitl_default/build_gazebo/CMakeCache.txt is different than the directory /home/thomas/git_folders/Firmware/build/px4_sitl_default/build_gazebo where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
CMake Error: The source "/workspaces/Firmware/Tools/sitl_gazebo/CMakeLists.txt" does not match the source "/home/thomas/git_folders/Firmware/Tools/sitl_gazebo/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
FAILED: external/Stamp/sitl_gazebo/sitl_gazebo-configure
cd /workspaces/Firmware/build/px4_sitl_default/build_gazebo && /usr/bin/cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DSEND_ODOMETRY_DATA=ON -GNinja /workspaces/Firmware/Tools/sitl_gazebo && /usr/bin/cmake -E touch /workspaces/Firmware/build/px4_sitl_default/external/Stamp/sitl_gazebo/sitl_gazebo-configure
ninja: build stopped: subcommand failed.
Makefile:217: recipe for target 'px4_sitl_default' failed
make: *** [px4_sitl_default] Error 1
The terminal process "/bin/bash '-c', 'make px4_sitl_default sitl_gazebo'" terminated with exit code: 2.`

I wouldn't be surprised if I missed an initialisation step, it was the first time I used the remote container feature of VSC.

[dagar]

@ThomasRigi can you try it with a clean build? One awkward thing at the moment is that if the PX4 compile fails it still builds and launches gazebo first before giving you an error. Maybe at first make sure px4 builds by itself (clicking Build in vscode), then make sure you don't have any zombie px4* or gzserver processes, then try the gazebo debug target. My normal workflow is only going through the debug launch, but we need to track down where it's failing for you.

[ThomasRigi]

Ok, now it works reliably. Hitting the build button in VSC before launching the debugger does the job. Previously I had some build files from having run the simulator over a terminal outside of VSC and (after closing the other simulation) I clicked directly on debug in VSC.

I wouldn't have thought it makes a difference whether I compile the code outside or inside VSC, but apparently it does. Anyway, now I know how it works, so all good for me :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.