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

Spawn robot and world separately #594

Merged
merged 14 commits into from
Dec 22, 2023
Merged

Spawn robot and world separately #594

merged 14 commits into from
Dec 22, 2023

Conversation

caguero
Copy link
Contributor

@caguero caguero commented Feb 16, 2023

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
Copy link
Collaborator

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
Copy link
Contributor Author

caguero commented Feb 21, 2023

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
Copy link
Collaborator

M1chaelM commented May 3, 2023

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
Copy link

alexg-k commented May 17, 2023

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?

Signed-off-by: Carlos Agüero <[email protected]>
@caguero caguero requested a review from crvogt December 17, 2023 10:53
@caguero caguero added this to the 2.4.0 milestone Dec 17, 2023
@j-herman
Copy link
Collaborator

@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
Copy link
Contributor Author

caguero commented Dec 22, 2023

@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 :)

@caguero caguero merged commit c1edb91 into main Dec 22, 2023
1 check passed
@caguero caguero deleted the caguero/spawn_robot branch December 22, 2023 20:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants