image_to_gazebo enhancement rqst: support pgm images

[PaulBouchier]

This excellent tool is supposed to be used when you've made a map of your physical world and want to translate it into a simulated world. Maps in the physical world generate as pgm files when saved. This tool should therefore read that type of file.

The workaround at present is to open the pgm file in gimp and export it as png.

[grassjelly]

thanks for raising this issue @PaulBouchier . The library already supports SLAM generated map through the yaml file here:
https://github.com/linorobot/linorobot2/blob/jazzy/linorobot2_gazebo/linorobot2_gazebo/map_to_gazebo.py . Just not documented and available in the front-end. I'm still thinking of a best way to expose that. Initially, I was thinking of having it generated from colcon build, although I thought having it explicitly invoked would be more ideal.

[PaulBouchier]

I tried it out and it's definitely not ready for primetime. 😢 It converted all the files in my maps directory. I suggest we leave this issue open until you figure out how to make it ready for prime-time, and we put a note in the documentation telling users they need to run gimp (which they'll probably run anyway to clean up a map) and export as .png in order to generate a simulation model.

IMHO the one-file-at-a-time is the most valuable feature, because you're typically working with one world at a time if you've made a slam map.

I think explicit invocation is the way to go - fewer surprising outcomes - colcon build shouldn't touch maps - they're like handcrafted jewelry once you've cleaned them up. The current app that reads png, tiff etc is a great user experience - simple and clear.

[grassjelly]

I am thinking of adding a 'Load Map YAML' in the current UI as it's the most intuitive way even for beginners.

[PaulBouchier]

I like that a lot! You already have the yaml that has the pixel resolution - it's redundant and a pain to get a tape measure to measure two points on the map and see how far apart they are in meters and then click on the map just so you can get a slightly less accurate meters/pixel than you already have in the yaml.

[grassjelly]

hey @PaulBouchier . The PR is up, could you help to test and generate a Gazebo world from a map yaml file. #216

[PaulBouchier]

Hey @grassjelly - thanks for the update. I like the implementation, and it seems to work great. It picks up the directory names correctly. I've sent the cabin.png, .yaml & .pgm files from a map I generated for my cabin on the sailboat by email (they won't attach to this issue).

It did pick up the resolution correctly from the yaml file (0.01m). Starting simulation with world_name set appropriately worked fine.

One additional comments:

1. Why does it install into the build directory? That's very unintuitive. You tell the user in the documentation to colcon build (which has to be done to get it from build to install) so that should pick it up from the worlds and models directories in src if it were placed there. It's kind of comforting when you've added image or map files to see them in the untracked files and it's confusing that the generated world files don't show as untracked. Plus, if you do rosclean your worlds get blown away. It would be better to add them to the src tree, then the user can check them in along with the maps (or not) as appropriate, and colcon build would pick them up.

[PaulBouchier]

Documentation updates are needed. I will do them in the PR for gh-pages enhancements, since I have rework to do on that PR anyway.

[grassjelly]

Hey @PaulBouchier , what do you mean by "why does it install into the build directory?". Mine's saved in the src directory tho,

[PaulBouchier]

I noticed that image files in linorobot_gazebo/linorobot_gazebo/images don't show up because you have a .gitignore file that ignores all images. I think that's improper. An image file that is the source of a world model is a part of the source code for the user's robot and world model. When they check in changes to their robot, or world, those should be flagged as something to be added to their working branch.

At a higher level, this is the same issue as above, where the world and model files are installed into the build directory - it's a workflow issue. You have a different view of a workflow that should be used to customize linorobot2 for your robot than I do. This is something I plan to write about in the new docs, "how to extend linorobot2 and linorobot2_hardware for your robot".

Your mental model seems to be that customizations broadly should be done and not checked in. If you replace your source directory for any reason you need to redo your customizations. That's feasible, but manual and basic and error-prone, and discourages keeping your source tree current.

My mental model is that changes to software or firmware should be done on a branch that's specific to your robot, and you should rebase your branch on top of the latest main branch after updating the main branch. Robots tend to be very long-lasting things compared to versions of linorobot2 software and firmware - they tend to last years. I think there needs to be a way to preserve your customizations, whether it be to robot software (models, urdf, navigation parameters) or to firmware (e.g. the PlatformIO config file), or specific hardware widget firmware. @hippo5329 supports this explicitely in linorobot2_hardware with "guard-bands" - markers in the config file after which users should place their customizations, and before which are the maintainers' configurations. He notes in his wiki that this makes it easier to merge the user's changes into updated firmware. I think this is the mental model that makes most long-term sense. It does require some familiarity with git, but I think some appropriate explanations in an "Extensions" section should explain this.

Given my mental model of how to do extensions for a user's robot, I think world files, be they source images or sdf and model files generated by your most excellent tool, should be considered "user extensions", to be preserved on a branch just like parameter changes in 2wd_properties.urdf.xacro or parameter changes in pico2_config.h.

Users are not forced to do their work on a branch as I've described - they can extend using manual processes as per your mental model, and if the source files for their world model (image, map, generated .sdf and model files) are in the source tree they will show up with git status, and alert the user that they need to preserve these things. Less sophiticated users get warned about modified files, and more sophisticated users can save their changes on a branch.

Thoughts?

[PaulBouchier]

Hey @PaulBouchier , what do you mean by "why does it install into the build directory?". Mine's saved in the src directory tho,

Please see my writeup about how to do extensions

[PaulBouchier]

Here's what the output prints:
Processing...
Exporting to file: /home/bouchier/linorobot2/linorobot2_grassjelly/linorobot2_ws/build/linorobot2_gazebo/models/cabin/meshes/cabin.stl

Note it's exporting to the build directory

[grassjelly]

hey @PaulBouchier the images dir is more of a placeholder for now and might change later on.

Regarding the custom linorobot2 settings, I'm thinking of a way to decouple robot specific configurations from the package itself. I've had this problem even on the ROS 1 version as I had different hardware setups and frankly speaking, I didn't like the idea of having the robot configuration in the package.

What I have in mind is something similar to what I did with https://github.com/chvmp/champ where robots have an independent configuration package (generated by a set-up assistant similar to MoveIt) which will contain YAML, launch files that are constantly changed and very specific to the robot. This architecture also allows sharing of configuration within the community as a reference or just for reproducibility's sake.

Here's a collection of robots in that project:

https://github.com/chvmp/robots/tree/master/configs

Let me know what you think

[PaulBouchier]

Oh wow - that's very meta. Seems like a good idea at a high level, but I'm unsure of some details that might derail it. E.g. what about some new firmware files needed for e.g. sonar range-finder or voltage monitor, which would require changes to includes and possibly build config files. Or what about the user in HBRC who built Truckbot in linorobot1 - an Ackermann-steered vehicle, and he would have needed new urdf files.