Godot game engine as ROS node

edit

godot_ros_pcviz is a good starting point- it can be easily modified to subscribe to something other than a point cloud or publish out of the _process callback.

https://github.com/lucasw/godot_ros_p... has my changes forked from https://github.com/ymd-stella/godot_r... - possibly the original author will merge my PRs and their repo could be the primary place to go.

Don't use the docker build method instructions in the readme, just clone the repo into your catkin workspace with the right branch and do a git submodule update --init --recursive then build normally with catkin, then import the project from devel/lib/godot_ros_pcviz/project.godot into godot.

The camera has no controlers, so if you publish a point cloud in you'll just see it from the one angle (I'll likely add a camera controller similar to the one in the godot 3D window next).

Old answer:

Every good 3D engine deserves a ros node, it is a lot of effort but it is usually easy to start small and add features gradually. I'd like to try it out if you get it working.

If Godot isn't available as a Ubuntu deb install it will likely cut down the potential number of users.

A simple node that can instantiate objects within the godot program via a ros service call is a good starting point. If the objects are physically simulated then add tf output: query the engine for the current position of the object then update a tf frame (with the frame id specified in the spawning service call).

For visualization supporting all or most of the features of the Marker type is very useful, so a Marker can be published in ros and appears in the godot rendering approximately like it does in rviz (but with whatever extra graphical flair godot adds).

From there it's nice to be able to have the engine render to texture and then publish the texture as a ros image. Field-of-view and position of the camera ought to be able to be controlled via CameraInfo and tf frames inputs, and any number of cameras can be supported.

urdf-to-godot translation would be good to have later.

The scripting language would eventually need the ability to subscribe and publish on topics for at least the basic std_msgs types. This sounds harder than any of the above, but perhaps for can be done in a crude/hard-coded/hacky way initially and made more generic and capable later.