Hi Mind Cloud is here!
We wanted to share the extra work we’ve done to earn additional points in the competition. We refactored the Mars Yard model to make it lighter and more usable, created a custom ArUco tag model with textures, and downloaded some free 3D models to use as landmarks. We added several of these objects into the Mars Yard world. You can try it yourself by following the README instructions here:
We used ROS 2 Jazzy together with Gazebo Sim Harmonic for the simulation. However, we did run into a few issues with the husarion_ugv_ros package mainly that the camera point clouds are sometimes rotated sideways, and in some cases, the control launch file didn’t work consistently for some of team members.
This was our first attempt at building something like this, so if you face any problems or have feedback, please let us know. We’ll try to fix it as soon as possible.
Thanks!
12 Likes
Hi, awesome job! We are also in the process of building a simulation environment but we are trying a different approach from yours as we are trying to integrate everything with the official Husarion repositories.
Here is our repository: GitHub - Sapienza-Technology-Team-Remote/erc2025_remote_sim
Currently landmarks and tags are missing and we are trying to solve some issues with the zed urdf provided by Husarion: we fixed the sideways pointcloud and the collision of the camera that slowdown the simulation; but we need to find a way to integrate these changes without requiring manual modifications by the user to the urdf files.
Regarding the processing of the Marsyard model we found pretty hard to reduce the number of faces maintaining a good topology and a clean texture: my processing workflow was documented here: STT ERC2025 Remote simulation - Google Docs
At the end we found a way to obtain an arbitrary number of faces (we settled on 100k) with a good topology and texture mapping.
P.S. I am interested in hearing what your workflow for processing the marsyard model has been if you want 
3 Likes
Hi, thanks a lot for the reply — that’s awesome work! I really appreciate the detailed documentation of your workflow; it’s super helpful and aligns with many of the challenges I ran into as well.
I’ve also built a package that looks very similar to yours. Like you, I wanted to avoid making changes to the core files of the husarion_ugv_ros repo, especially since it’s still under development. So for now, I’m only applying small, non-invasive modifications without touching the launch files or main codebase. I haven’t yet found a clean workaround for this — maybe we could open an issue and propose a standardized way to apply simulation-specific changes without requiring users to manually modify upstream files.
As for the Marsyard model, my pipeline was a bit simpler — more of a “make it work” approach than a fully clean retopology. Here’s what I did:
My Pipeline:
- Simplification:
I had to simplify the original 3M-face mesh right away, as Blender would crash otherwise. I settled around 300K faces to preserve textures. When I went lower, black spots began appearing in the baked textures. But I agree — for performance, aiming for 100K or less would be ideal.
- UV & Texture Baking:
I created a new 4K texture using Smart UV Project. Blender automatically gave more UV space to the Marsyard surface, which helped. I then baked the texture from the original model onto the simplified one using Cycles.
- Mesh Cleanup:
After baking, I removed duplicate vertices, deleted isolated islands, and filled holes. Nothing fancy, but it cleaned things up enough for simulation.
- Heightmap:
I also experimented with a heightmap, hoping to use it for collisions in Gazebo’s SDF. Unfortunately, I couldn’t get it working reliably and found no tools to debug the collision issue. Still, the heightmap might be useful for regenerating the yard as a plane in Blender. I’m not sure if we can bake a texture on top of that, but it’s a direction worth exploring.
Here’s the heightmap I generated:
Heightmap link
Unlike your structured workflow with Shrinkwrap and Quad Remesh, I didn’t attempt major topology fixes — mostly because I’m not experienced in that area. But after reading your doc, I’m considering giving it another shot. Your approach makes a lot of sense and might yield better performance in simulation.
Looking forward to seeing how your environment evolves, and I may also share the GitHub repo for our work soon. I’ll let you know if we come up with any improvements or new ideas on the Marsyard pipeline.
Thanks again for sharing!
2 Likes
Thank you for the answer and the detailed workflow!
I agree that it could be useful to open an issue or pull request on Husarion repositories about modifying these files.
In particular the most important things to change for me is the collision mesh of the ZED camera, by disabling it I increased the performances from 20% of Real Time Factor to 70%.
A simple box is more than sufficient for collision checking, so I think it should be the default.
The sideway pointcloud also should be fixed but the issue can be avoided by generating the pointcloud from rgb and depth using some external package (for example depth_image_proc)
1 Like
Folks, thank you - this is exactly the kind of cooperation we wanted to achieve while preparing the Rulebook.
As per the technical details - I won’t be interfering (however I’ve forwarded this topic to the proper team so they can have a look) - but I’d say - as a general rule feel free to open issues and pull requests on our repositories. Some housekeeping notes though:
- please tag the PR/issue (stating in the description will be enough) as a “ERC Remote Competition” topic
- please somehow link the PR/issues/etc here (we will be using this Forum for scoring exernal activities too)
- have in mind that ERC-related issues will have a different SLA than our regular customers (i.e. long term goals may be prioritized lower - past the ERC finals, but bugfixes may get prioritized higher due to the known deadlines)
Thanks again
2 Likes