mhl787156
commented
2 years ago Spawning has to be done by either ros2cli or ros2 node which means that the ros.env.d approach is not going to work if it requires building as well. Suggested methods:
- Reuse the AP-gazebo docker container with a spawning script which uses ros2cli to spawn things. Include spawning container in docker-compose file. A bit like the multi-drone spawning system
- A fenswood AP-Gazebo container containing the spawning node
- Building the spawning node within the fesnwood startup script. (Or perhaps modifying sim-base-core to have a build stack folder for runtime building - ros.build.d or something)
@rob-clarke any thoughts on which one? I'd like to keep the ros.env.d in fenswood because it is rather elegant. However it can be sort of limiting here!
Please create a utility to spawn the "target" and "hotspot" markers in the group project Fenswood simulation according to the specification described in the attached draft briefing document.
Can use the target spawning script from the FARSCOPE group project as an example. While that case used a custom mesh, I'd be happy for the targets in this case to be simple built-in primitives, e.g. cylinders or boxes. This should simplify containerization.
You can find the FARSCOPE target model in URDF form here. Note in that project, the launch file loaded the URDF into a parameter and then the spawning script read the parameter and streamed it as text into Gazebo's spawn service.
Happy for spawning to take a simpler approach than the full complexity talked about in the briefing document. You could just use cylinders to fill in a segment of the crater annulus region, and then fill one end of that with a red cylinder as a single hotspot. Keep it simple to avoid the chance of a difficult or even impossible scenario, where the yellow target was totally filled with red hotspots.