Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi drone in ignition #20221

Closed
wants to merge 6 commits into from
Closed

Conversation

dsix-ls2n
Copy link
Contributor

@dsix-ls2n dsix-ls2n commented Sep 15, 2022

I wanted to be able to spawn several times a drone in ignition gazebo using the PX4 command and environment variables.
Use case:

  • Environment variables PX4_SIMULATOR=ignition, PX4_SIM_MODEL=x500
  • run the px4 binary
    If run a second, it will not work because the same model name is used for exchanges between PX4 and ignition gazebo.

Describe your solution

I added the option to postfix the model name in the simulation module and use this to include the PX4 instance number in the model name.

@dagar
Copy link
Member

dagar commented Sep 15, 2022

FYI we should have a good solution for multiple instances of the same model coming soon. gazebosim/gz-sim#1689

@dsix-ls2n
Copy link
Contributor Author

@dagar This seems to fix a problem in gazebo related with the multi-spawning. Do you have a link to the the multi-spawning branch/pr in PX4? It seems that the solution is similar to mine (instance number as a postfix to model name).
Thx

@dagar
Copy link
Member

dagar commented Sep 29, 2022

Could you review if current main (after #20319 merged) now covers everything you need? You may also need to upgrade Gazebo with the small multirotor motor plugin update (gazebosim/gz-sim#1689).

@dsix-ls2n
Copy link
Contributor Author

dsix-ls2n commented Sep 30, 2022

Hello, the current master seems to fill my need. However, I think it can be improved:

  • by putting some default values to the environment variables if not set. For example, if 'PX4_GZ_WORLD': 'default' is not filled then the startup crashes where obviously it could be taken by default if the environment variable is not set. Maybe the same could be done for the drone model?
  • when using the PX4_SIM_MODEL or PX4_GZ_MODEL_NAME env variable, then PX4_GZ_MODEL_POSE is not taken into account anymore.
  • on clean build, using only PX4_GZ_MODEL env variable is not enough on my computer. PX4_SIM_MODEL need to be set. For some reason I didn't explore, starting the simulation once with the PX4_SIM_MODEL is enough to make it work with PX4_GZ_MODEL afterward (as long as I don't clean build). I think anyway, 3 different environment variables to set the model is confusing.

@bperseghetti
Copy link
Member

by putting some default values to the environment variables if not set. For example, if 'PX4_GZ_WORLD': 'default' is not filled then the startup crashes where obviously it could be taken by default if the environment variable is not set. Maybe the same could be done for the drone model?

So this is intentional, a big part of this is about allowing both px4 and gazebo based simulation workflows. This allows for you to launch a world already in gazebo with your models spawned where you want them and then attach a px4 binary by providing the actual simulation model name and PX4_SYS_AUTOSTART type. Adding a world name to default to always would break that, we could later on add a more complicated lookup for it, but also if you were running multiple simulation instances or have one ghosted in the background you also would need the "proactive designation approach".

when using the PX4_SIM_MODEL or PX4_GZ_MODEL_NAME env variable, then PX4_GZ_MODEL_POSE is not taken into account anymore.

PX4_SIM_MODEL exist for only two reasons, it allows for launching from make where it does not interfere with the PX4_SYS_AUTOSTART and it allows for the potential reuse in other sims, it is never meant to be directly set outside of the airframe file. When using the PX4_GZ_MODEL_NAME you are designating by using the name that the model has already been created in the world and you are passing the actual already existing name to it, therefore a pose would not go through as it already has a pose from where it was already chosen to be spawned, this allows you to connect to vehicles in complex environments/situations as the "come online" think driving a quad around on a car in sim and then having it come on line when you want to launch/fly it.

on clean build, using only PX4_GZ_MODEL env variable is not enough on my computer. PX4_SIM_MODEL need to be set. For some reason I didn't explore, starting the simulation once with the PX4_SIM_MODEL is enough to make it work with PX4_GZ_MODEL afterward (as long as I don't clean build). I think anyway, 3 different environment variables to set the model is confusing.

If you are launching a new vehicle there are really only two variables that ever need set, one is the PX4_GZ_MODEL this allows you to create new models with unique sensor setups (IE x500-Depth) without having to create a new airframe file to match the name, instead you just pass the appropriate PX4_SYS_AUTOSTART type for that vehicle type which is the second item that you "need".

Also note that if you don't want to go through all that you can always just launch with:

make px4_sitl gz_x500

@dsix-ls2n actually, I would like to possibly show you the design intention and multiple use cases then see directly from that if you have suggestions from there, are you on px4 slack?

@dsix-ls2n
Copy link
Contributor Author

Thanks, it make a bit more sense to me now. All we need is documentation :)

@dsix-ls2n
Copy link
Contributor Author

Solved, just waiting for Ignition fortress plugin update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants