Spawn robot and world separately

[caguero]

This patch decouples the world and robots to be spawned. This way, it'll be easier to launch different combinations of worlds/robots in the future.

How to test it?

See #760

[M1chaelM]

I think it's useful to be able to do this, but if I understand correctly the main purpose is to support robot/world configurations that are not used in VRX--is that right? I think for VRX, we always want the WAMV to be the robot and it should be spawned in the same place, so requiring an additional command is a little bit inconvenient.

If you agree, maybe we could discuss creating a separate package for more flexible configurations outside the VRX competition. (Part of the problem may be the naming ambiguity between the VRX competition and the VRX environment, which makes it a little hard to tell what vrx_gz is supposed to support.)

[caguero]

I think it's useful to be able to do this, but if I understand correctly the main purpose is to support robot/world configurations that are not used in VRX--is that right? I think for VRX, we always want the WAMV to be the robot and it should be spawned in the same place, so requiring an additional command is a little bit inconvenient.

If you agree, maybe we could discuss creating a separate package for more flexible configurations outside the VRX competition. (Part of the problem may be the naming ambiguity between the VRX competition and the VRX environment, which makes it a little hard to tell what vrx_gz is supposed to support.)

You're right about the use of the WAM-V for now, but if we potentially switch locations (imagine sandisland vs sydneyregatta, or other venues in the future), the starting pose might change. Alternatively, we could expose the initial pose as an argument and that might work but I thought that decouple world and robot gives as a more flexible solution for other future use cases. Imagine for example if you want to spawn multiple WAM-Vs or different robots.

[M1chaelM]

I like the idea of making it easier to spawn the robot and the world separately if needed, but I think the competition launcher should do both at the same time, since we always want this when running the competition environment. It seems like we could achieve this with a separate launch file for non-competition use. Maybe vrx.launch.py or vrx_environment.launch.py? @caguero What do you think?

[alexg-k]

I think it's useful to be able to do this, but if I understand correctly the main purpose is to support robot/world configurations that are not used in VRX--is that right? I think for VRX, we always want the WAMV to be the robot and it should be spawned in the same place, so requiring an additional command is a little bit inconvenient.

If you agree, maybe we could discuss creating a separate package for more flexible configurations outside the VRX competition. (Part of the problem may be the naming ambiguity between the VRX competition and the VRX environment, which makes it a little hard to tell what vrx_gz is supposed to support.)

This simulator has the potential to grow beyond the VRX competition (if it not already is). It would be indeed nice to decouple vehicle and world. This also useful for multi-robot applications. Maybe we can afterwards add another launch file on top intended just for the competition?

[j-herman]

@caguero I'm in the process of reviewing this so I can use the new launch process for the RoboBoat tutorials, and had a thought on how we might address @M1chaelM's comment above. Seems like if we keep the competition.launch file as-is, and add a launch file with a different name (maybe vrx_environment.launch, or something?), we can maintain both options. I tested it out and the changes to spawn.launch don't seem to cause any problems for running the original competition script. This also lets us maintain the existing tutorials. I'll put my changes in as a pull request to this branch so you can take a look, if this is of interest.

[caguero]

@caguero I'm in the process of reviewing this so I can use the new launch process for the RoboBoat tutorials, and had a thought on how we might address @M1chaelM's comment above. Seems like if we keep the competition.launch file as-is, and add a launch file with a different name (maybe vrx_environment.launch, or something?), we can maintain both options. I tested it out and the changes to spawn.launch don't seem to cause any problems for running the original competition script. This also lets us maintain the existing tutorials. I'll put my changes in as a pull request to this branch so you can take a look, if this is of interest.

Thanks @j-herman ! Approving your changes mostly :)