Px4-autopilot: `make posix_sitl_default gazebo_none_ide` is not a valid build target.

Created on 19 Jan 2017  Â·  18Comments  Â·  Source: PX4/PX4-Autopilot

It seems that make posix_sitl_default gazebo_none_ide, as mentioned on https://dev.px4.io/simulation-gazebo.html, is not a valid build target.

Exact error on trying to run make posix_sitl_default gazebo_none_ide on the master branch:

ninja: error: unknown target 'gazebo_none_ide', did you mean 'gazebo_plane_ide'?

bug documentation wontfix

Most helpful comment

I'm not sure what happened to none, but I actually strongly dislike this system. These shouldn't be firmware build targets, it's all the same firmware build. This should be a helper script that lives outside of the build system.

It's one of those things that was kind of convenient initially, but ended up making something simple actually quite complicated and mysterious. Now we need even more magic helper targets to do things that should be easy like running px4 under gdb. Is that gdb_gazebo_iris, gazebo_iris_gdb, or maybe gazebo_iris__gdb? What a time saver over launching gdb manually (gdb --args ./px4) in a way I can google to figure out.

If we're going to do anything here I propose we break this apart into the orthogonal pieces that it actually is. If we did it that way it would be trivial to do things like running gazebo on the side, and starting px4 separately in your ide, or under gdb, or valgrind, or under the debugger in your IDE. All without additional magic.

The separate pieces are...

  1. building px4

    • it's always the same posix_sitl_default PX4 firmware build no matter which estimator or model you want to use. Just build posix_sitl.
  2. building the simulator (sitl_gazebo or jmavsim)

    • these are separate projects that don't share anything with the firmware build, and run as separate processes. They shouldn't be part of the PX4 cmake build at all.
  3. running px4

    • all you actually need to do here is select the model (which selects a startup script) and it could even default to the iris. If we hadn't gone out of our way to make it so complicated this would already work properly when you click run or debug in an ide. This is literally just running the binary (./px4) with optional arguments.
  4. running the simulator

    • in gazebo you need to specify the world, with jmavsim you don't have a choice.
  5. bringing it altogether

    • now all you actually need to do is start px4 with a simulator and make sure the model is the same on both sides. This could be a very simple script and it should make it obvious how you can do each step manually.
% ./run_sitl.sh --model=iris --simulator=gazebo

    Running PX4:  ./build/posix_sitl_default/px4 
    Running Gazebo:  gzserver Tools/sitl_gazebo/worlds/iris.world

______  __   __    ___ 
| ___ \ \ \ / /   /   |
| |_/ /  \ V /   / /| |
|  __/   /   \  / /_| |
| |     / /^\ \ \___  |
\_|     \/   \/     |_/

px4 starting.

pxh> 


Thoughts?

All 18 comments

Would be cool to get this fixed when you can.

@dagar
Just FYI, make posix list_vmd_make_targets gives me these options:

gazebo___ide
gazebo_iris_ide
gazebo_iris_opt_flow_ide
gazebo_iris_rplidar_ide
gazebo_standard_vtol_ide
gazebo_plane_ide
gazebo_solo_ide
gazebo_tailsitter_ide
gazebo_typhoon_h480_ide
gazebo_rover_ide
gazebo_hippocampus_ide

There are no "none" cases listed, so I guess that is handled specially?

Anyway, I'll be updating some docs in this area shortly, so please keep me posted on your fix here. I'm also adding https://github.com/PX4/Devguide/pull/386 which now mentions debugger as a topic.

I'm not sure what happened to none, but I actually strongly dislike this system. These shouldn't be firmware build targets, it's all the same firmware build. This should be a helper script that lives outside of the build system.

It's one of those things that was kind of convenient initially, but ended up making something simple actually quite complicated and mysterious. Now we need even more magic helper targets to do things that should be easy like running px4 under gdb. Is that gdb_gazebo_iris, gazebo_iris_gdb, or maybe gazebo_iris__gdb? What a time saver over launching gdb manually (gdb --args ./px4) in a way I can google to figure out.

If we're going to do anything here I propose we break this apart into the orthogonal pieces that it actually is. If we did it that way it would be trivial to do things like running gazebo on the side, and starting px4 separately in your ide, or under gdb, or valgrind, or under the debugger in your IDE. All without additional magic.

The separate pieces are...

  1. building px4

    • it's always the same posix_sitl_default PX4 firmware build no matter which estimator or model you want to use. Just build posix_sitl.
  2. building the simulator (sitl_gazebo or jmavsim)

    • these are separate projects that don't share anything with the firmware build, and run as separate processes. They shouldn't be part of the PX4 cmake build at all.
  3. running px4

    • all you actually need to do here is select the model (which selects a startup script) and it could even default to the iris. If we hadn't gone out of our way to make it so complicated this would already work properly when you click run or debug in an ide. This is literally just running the binary (./px4) with optional arguments.
  4. running the simulator

    • in gazebo you need to specify the world, with jmavsim you don't have a choice.
  5. bringing it altogether

    • now all you actually need to do is start px4 with a simulator and make sure the model is the same on both sides. This could be a very simple script and it should make it obvious how you can do each step manually.
% ./run_sitl.sh --model=iris --simulator=gazebo

    Running PX4:  ./build/posix_sitl_default/px4 
    Running Gazebo:  gzserver Tools/sitl_gazebo/worlds/iris.world

______  __   __    ___ 
| ___ \ \ \ / /   /   |
| |_/ /  \ V /   / /| |
|  __/   /   \  / /_| |
| |     / /^\ \ \___  |
\_|     \/   \/     |_/

px4 starting.

pxh> 


Thoughts?

Yeah it a bit out of hand. Separate targets and a helper script sounds good
to me.

On Dec 12, 2017 8:08 PM, "Daniel Agar" notifications@github.com wrote:

I'm not sure what happened to none, but I actually strongly dislike this
system. These shouldn't be firmware build targets, it's all the same
firmware build. This should be a helper script that lives outside of the
build system.

It's one of those things that was kind of convenient initially, but ended
up making something simple actually quite complicated and mysterious. Now
we need even more magic helper targets to do things like launch px4 in gdb.
Is that gdb_gazebo_iris, gazebo_iris_gdb, or maybe gazebo_iris__gdb? What a
time saver over launching gdb manually (gdb --args ./px4).

If we're going to do anything here I propose we break this apart into the
orthogonal pieces that it already is. If we did it that way it would be
trivial to do things like running gazebo on the side, and starting px4
separately in your ide, or under gdb, or valgrind, or under the debugger in
your IDE. All without additional magic.

The separate pieces are...

1.

building px4

  • it's always the same posix_sitl_default PX4 firmware build no matter
    which estimator or model you want to use. Just build posix_sitl.
    2.

building the simulator (sitl_gazebo or jmavsim)

  • these are separate projects that don't share anything with the
    firmware build, and run as separate processes. They shouldn't be part of
    the PX4 cmake build at all.
    3.

running px4

  • all you actually need to do here is select the model (which selects
    a startup script) and it could even default to the iris. If we hadn't gone
    out of our way to make it so complicated this would already work properly
    when you click run or debug in an ide. This is literally just running the
    binary (./px4) with optional arguments.
    4.

running the simulator

  • in gazebo you need to specify the world, with jmavsim you don't have
    a choice.
    5.

bringing it altogether

  • now all you actually need to do is start px4 with a simulator and
    make sure the model is the same on both sides. This could be a very simple
    script and it should make it obvious how you can do each step manually.

% ./run_sitl.sh --model=iris --simulator=gazebo

Running PX4:  ./build/posix_sitl_default/px4
Running Gazebo:  gzserver Tools/sitl_gazebo/worlds/iris.world

______ __ __ ___ | ___ \ \ \ / / / || |_/ / \ V / / /| || __/ / \ / /_| || | / /^\ \ ___ |_| \/ \/ |_/

px4 starting.

pxh>

Thoughts?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PX4/Firmware/issues/6389#issuecomment-351247999, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAc6rN2oVbRaPfKrBHausgAFOHolI9hXks5s_yOcgaJpZM4Ln_NU
.

This is definitely complicated - I only just found out about the additional GDB stuff, and those special cases like none and the triple underscores. Also the doc I created is simulator dependent, so it may be that I'm missing all sorts of things about working with nuttx or other hardware targets.

Re GDB, how would you launch this under your new scheme -say for sitl, gazebo, typhoon? How would we do launching with GDB enabled vs attaching GDB after?

The two things that I do like about the current system are the ability to list all config targets (essentially list the init files) and the ability to build and launch the default in one command - make posix jmavsim

I guess I'm also a little concerned about the between-state when people are updating all their scripts to do the right thing, and people know about the old system.

Upshot. Yes, awesome idea. Would be good if we can also easily list our models and main usage cases for the helper script as part of it's help.

Closing as stale.

@bkueng Can you tell me what the right way is to start Gazebo and SITL separately? The suggested approach does not work (as per this issue):

make posix_sitl_default gazebo_none_ide

It's make posix_sitl_default gazebo_iris_ide (or any model you want).

In your IDE select px4_ target you want to debug (e.g. px4_iris)

That seems to be gone as well. You can use make posix_sitl_default none_iris.

Thanks @bkueng

Unfortunately that is a confusing answer in the context of the rest of the text.

  1. The section starts "To start Gazebo and PX4 separately:" but won't make posix_sitl_default gazebo_iris_ide start both gazebo and sitl?
  2. For

    In your IDE select px4_ target you want to debug (e.g. px4_iris)"

    That seems to be gone as well. You can use make posix_sitl_default none_iris.

    Are you saying that the option px4_iris is gone? How do I attach to this from the ide then?

Previously the model was "start gazebo configured to use sitl but without a model specified" then use the ide to start a specific version of sitl. When a debug session finishes SITL is stopped and when you start again SITL is started fresh, but gazebo lives on. Now I can't see how the model works.

I think you might be saying

  • make posix_sitl_default gazebo_iris_ide starts gazebo configured for use with ID and particular model
  • you can then use make posix_sitl_default none_iris in another terminal to start and stop SITL. You can turn it on and off when you need to.
  • But do I need to do anything special to attach to this in an ide?

he section starts "To start Gazebo and PX4 separately:" but won't make posix_sitl_default gazebo_iris_ide start both gazebo and sitl?

It does not execute px4.

Are you saying that the option px4_iris is gone? How do I attach to this from the ide then?

It seems to be gone, yes. @dagar would know the details.

make posix_sitl_default gazebo_iris_ide starts gazebo configured for use with ID and particular model

you can then use make posix_sitl_default none_iris in another terminal to start and stop SITL.

Yes. But you probably want to run the PX4 binary directly from the IDE (e.g. because it automatically attaches a debugger), which is more cumbersome:

cd build/posix_sitl_default/tmp/rootfs # (working directory)
export PX4_SIM_MODEL=iris
../../bin/px4 ../../../../ROMFS/px4fmu_common -s etc/init.d-posix/rcS

Which is essentially what the previous px4_iris did.

It's just a mechanism for launching the simulator with a given model right?

@dagar

It's just a mechanism for launching the simulator with a given model right?

Yes, that can be invoked as a target from the IDE. This can still be done, but now you would have attach to the running process somehow, which is a lot less easy to explain.

FYI, sounds like our debugging story is generally a bit wobbly: https://github.com/PX4/Devguide/issues/625

@hamishwillee
is there something wrong in my debug config?
What's the target jmavsim___ide? No trace of it in devguide.

@DanieleVeri I don't know. I'm involved in documentation work for PX4 though, so trying to get answers to this and similar questions so that we can update the documentation. This issue is unrelated to your question on GDB debugging - I just linked to show that we need a more clear story on debugging, and this is part of that.

What's the target jmavsim___ide? No trace of it in devguide.

This is somewhat covered in the simulation. Basically you can use triple underscore to indicate the default in "viewer_model_debugger". So essentially the missing default is "iris", and this means set up jmavsim for use with iris model and ide.

There might be more that can learned about jmavsim debugging from ./Tools/jmavsim_run.sh (as mentioned in the jmavsim doc

@dagar So can you tell me if there is a SITL build target for use in the IDE still (as per https://github.com/PX4/Firmware/issues/6389#issuecomment-428377970) or whether there should be one. Essentially, what do we expect people to do so I can update the docs.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Closing as stale.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JacobCrabill picture JacobCrabill  Â·  4Comments

felix-west picture felix-west  Â·  4Comments

alexcherpi picture alexcherpi  Â·  4Comments

julianoes picture julianoes  Â·  3Comments

mwiatt picture mwiatt  Â·  5Comments