Standalone px4 stable #22467
Standalone px4 stable #22467
Conversation
Signed-off-by: frederik <[email protected]>
Signed-off-by: frederik <[email protected]>
frede791
force-pushed
the
standalone_px4_stable
branch
from
3be7b2a
to
0882ce9
Compare
ThomasDebrunner
requested review from
beniaminopozzan,
dagar and
ThomasDebrunner
Dropping from 1m leads to movement in the rc_cessna. Dropping from 0.5m leads to no movement.
|
If we want to truly untangle this going forward then this is backwards. PX4 launching standalone should be the normal case, then on top of that we should be able to optionally launch gzserver (as a convenience), and optionally spawn the entity (vehicle model). Adding special environment variables to a launch is what contributed to this mess in the first place. |
|
@dagar Sure this can be done by reversing the conditions described in the changes. The question is then how you want to tell PX4 what it should launch (other than using env variables). |
Co-authored-by: Daniel Agar <[email protected]>
Signed-off-by: frederik <[email protected]>
Signed-off-by: frederik <[email protected]>
Signed-off-by: frederik <[email protected]>
|
@dagar This is for review alongside the PRs in px4-gazebo models. |
This is outdated and no longer reflects the proposed functionality. |
Signed-off-by: frederik <[email protected]>
frede791
force-pushed
the
standalone_px4_stable
branch
from
76352be
to
82d19f8
Compare
|
@beniaminopozzan Could you test the different args please? I think i have tested them all successfully but maybe there is some cases I'm forgetting about. |
Signed-off-by: frederik <[email protected]>
|
@beniaminopozzan Ok I have reverted to the old structure. So now if you run |
Signed-off-by: frederik <[email protected]>
Signed-off-by: frederik <[email protected]>
|
Reverted back to using gz submodule rather than downloading at runtime. Keeps simulation-gazebo script the old way (so there is still a |
|
@dagar Please make sure to squash-merge this PR. |
Signed-off-by: Beniamino Pozzan <[email protected]>
There was a problem hiding this comment.
Thanks @frede791
I tested:
- All standard
make px4_sitl gz_*targets, all working as expected. - All the examples in the user guide, all working as expected
|
@beniaminopozzan Thanks for the addition. |
simulation gazebo: move the gazebo models to submodule, allow for operation with external gazebo instance, independent of startup order. Allows drag an drop of models from gazebo fuel. * rolled back updates Signed-off-by: frederik <[email protected]> * fixing empy Signed-off-by: frederik <[email protected]> * Update GZBridge.cpp to lower drop position Dropping from 1m leads to movement in the rc_cessna. Dropping from 0.5m leads to no movement. * Update STANDALONE env variable. * Update STANDALONE env_variable on GZBridge * Update src/modules/simulation/gz_bridge/GZBridge.cpp Co-authored-by: Daniel Agar <[email protected]> * test removal of x500 Signed-off-by: frederik <[email protected]> * removed all models and reworked logic Signed-off-by: frederik <[email protected]> * remove model path in set_sdf_filename Signed-off-by: frederik <[email protected]> * filter resource path for world sdf Signed-off-by: frederik <[email protected]> * updated structure to keep old make px4_sitl Signed-off-by: frederik <[email protected]> * remove gz tools Signed-off-by: frederik <[email protected]> * import gz as submodule and reverse rc simulator logic Signed-off-by: frederik <[email protected]> * [gz-sim]: source GZ_SIM_RESOURCE_PATH only if PX4 starts gz server Signed-off-by: Beniamino Pozzan <[email protected]> * Typo fix --------- Signed-off-by: frederik <[email protected]> Signed-off-by: frederik <[email protected]> Signed-off-by: Beniamino Pozzan <[email protected]> Co-authored-by: Daniel Agar <[email protected]> Co-authored-by: Beniamino Pozzan <[email protected]>
Solved Problem
When launching PX4 using
make px4_sitlyou will always launch Gazebo as well. Historically, this was a hack in order to simplify the procedure of getting a simulation started. Over time this led to more and more encroachment of Gazebo models and worlds on PX4. This PR ends this. All gazebo models and worlds are outsourced to PX4/PX4-gazebo-models and PX4 will only know the airframe name and number that can then be transmitted to Gazebo using gz-transport.It proposes two primary ways of starting PX4:
This will start PX4 and Gazebo as it used to. The only difference is that now the models and worlds are placed in a submodule that is fetched from PX4-gazebo-models.
The second way, extends current functionality and can be run with:
This will start just PX4 and, if gz-server has not been started, will print a message that Gazebo cannot be found.
This warning disappears once Gazebo has been started.
In order to start Gazebo, a script called
simulation-gazebocan be called from thePX4-gazebo-modelsrepository. This script will download all models and worlds, if not detected, and place them in a folder called~/.simulation-gazebo.It is the primary proposed way of starting Gazebo, as it cleanly separates PX4 and Gazebo, requiring minimal exchange between the two.
All existing functionality regarding the various environmental variables that can be set (e.g
GZ_WORLDorPX4_GZ_MODEL_POSE) can still be used as they have been up to now.CMake targets for the worlds are now made from the submodule. There is no longer CMake magic relating to the model sdf files, but instead only in relation to the airframe numbers.
This PR would eliminate the need for PRs #22473 and #22437 to be merged.
Changelog Entry
For release notes: Ability to launch Gazebo independently of PX4.