Revision history [back]

I think it would be a great feature even though Gazebo is meant for that task. Sometimes Gazebo is just too cumbersome to invoke when some simple graphical primitives in Rviz could do the job just fine.

One hacky solution is to run a screen grab node http://wiki.ros.org/screengrab_ros and position the rviz window just so, though it would be very brittle and hard to automate with launch files.

Another route that will be very crude is to draw images using OpenCV and then it is easy to publish them, some minimal 3D can be done using projectPoints.

I think it would be a great feature even though Gazebo is meant for that task. Sometimes Gazebo is just too cumbersome to invoke when some simple graphical primitives in Rviz could do the job just fine.

It looks like the rviz default plugin camera_display.cpp is the best starting point for modification for grab a rendered view and publish it. The panel display ought to be replaced by render-to-texture, and ogre writeContentsToFile() could be used instead of the less easily done copying of pixel data from the frame buffer and then putting it inside a cv::Mat container (which then could be converted to an Image with cv_bridge), or putting the pixel the data inside a sensor_msgs::Image directly.

Old suggestions:

One hacky solution is to run a screen grab node http://wiki.ros.org/screengrab_ros and position the rviz window just so, though it would be very brittle and hard to automate with launch files.

Another route that will be very crude is to draw images using OpenCV and then it is easy to publish them, some minimal 3D can be done using projectPoints.

I think it would be a great feature even though Gazebo is meant for that task. Sometimes Gazebo is just too cumbersome to invoke when some simple graphical primitives in Rviz could do the job just fine.

It looks like the rviz default plugin camera_display.cpp camera_display https://github.com/ros-visualization/rviz/blob/indigo-devel/src/rviz/default_plugin/camera_display.cpp is the best starting point for modification for grab a rendered view and publish it. The panel display ought to be replaced by render-to-texture, and ogre writeContentsToFile() could be used instead of the less easily done copying of pixel data from the frame buffer and then putting it inside a cv::Mat container (which then could be converted to an Image with cv_bridge), or putting the pixel the data inside a sensor_msgs::Image directly.

Old suggestions:

One hacky solution is to run a screen grab node http://wiki.ros.org/screengrab_ros and position the rviz window just so, though it would be very brittle and hard to automate with launch files.

Another route that will be very crude is to draw images using OpenCV and then it is easy to publish them, some minimal 3D can be done using projectPoints.

I think it would be a great feature even though Gazebo is meant for that task. Sometimes Gazebo is just too cumbersome to invoke when some simple graphical primitives in Rviz could do the job just fine.

It looks like the rviz default plugin camera_display https://github.com/ros-visualization/rviz/blob/indigo-devel/src/rviz/default_plugin/camera_display.cpp is the best starting point for modification for grab a rendered view and publish it. The panel display ought to be replaced by render-to-texture, and ogre writeContentsToFile() could be used instead of the less easily done copying of pixel data from the frame buffer and then putting it inside a cv::Mat container (which then could be converted to an Image with cv_bridge), or putting the pixel the data inside a sensor_msgs::Image directly.

It looks like someone may have done this with https://github.com/uml-robotics/rviz_camera_stream, but the code isn't up to date enough to build from catkin.

Old suggestions:

One hacky solution is to run a screen grab node http://wiki.ros.org/screengrab_ros and position the rviz window just so, though it would be very brittle and hard to automate with launch files.

Another route that will be very crude is to draw images using OpenCV and then it is easy to publish them, some minimal 3D can be done using projectPoints.

I think it would be https://github.com/lucasw/rviz_camera_stream is in a great feature even though Gazebo is meant for that task. Sometimes Gazebo is just too cumbersome to invoke when some simple graphical primitives crude state but can presently publish an image rendered in Rviz could do the job just fine. rviz (it builds in jade at least, but likely works in hydro and indigo).

It looks like Because it was based on the rviz default camera plugin camera_display https://github.com/ros-visualization/rviz/blob/indigo-devel/src/rviz/default_plugin/camera_display.cpp (from camera_display.cpp) it is the best starting point for modification for grab a rendered view and publish it. The panel display ought to be replaced by render-to-texture, and ogre writeContentsToFile() could be used instead of the less easily done copying of pixel data from the frame buffer and then putting it inside a cv::Mat container (which then could be converted to an Image with cv_bridge), or putting the pixel the data inside a sensor_msgs::Image directly.somewhat odd:

It looks like someone may have done this with https://github.com/uml-robotics/rviz_camera_stream, but the code isn't up to date enough to build from catkin.Eventually those oddities will be cleaned up.

Old suggestions:

One hacky solution is to run a screen grab node http://wiki.ros.org/screengrab_ros and position the rviz window just so, though it would be very brittle and hard to automate with launch files.

https://github.com/lucasw/rviz_camera_stream is in a crude state but can presently publish an image rendered in rviz (it builds in jade at least, but likely works in hydro and indigo). indigo, and following the fork back leads to a pre-catkin version).

Because it was based on the rviz camera plugin (from camera_display.cpp) it is somewhat odd:

• it needs an input image and it composites the input image with the rviz rendering (sending a black image and setting the Image Rendering to background will make it blank).
• it needs an input camera_info to get camera intrinsics.
• the output image resolution is the same as the widget window- so resizing the widget resizes the output image.
• the output image topic is hardcoded

Eventually those oddities will be cleaned up.

Old suggestions:

One hacky solution is to run a screen grab node http://wiki.ros.org/screengrab_ros and position the rviz window just so, though it would be very brittle and hard to automate with launch files.

https://github.com/lucasw/rviz_camera_stream is in a crude state but can presently publish rviz_camera_stream publishes an image rendered in rviz (it rviz. It builds in jade at least, but likely works in hydro and indigo, and following the fork back leads to a pre-catkin version). version.

Because it was based on the rviz camera plugin (from camera_display.cpp) it is somewhat odd:

• it needs an input image and it composites the input image with the rviz rendering (sending a black image and setting the Image Rendering to background will make it blank).
• it It needs an input camera_info to get camera intrinsics.
intrinsics and resolution. The distortion coefficients are ignored, but a image_proc like node that implements http://code.opencv.org/issues/1387 could address that downstream. (Do gazebo cameras support distortion yet?)
• the output image resolution is the same as the widget window- so resizing the widget resizes the output image.
• the

  The input camera_info topic and output image topic is hardcoded

Eventually those oddities will be cleaned up.are set in the rviz plugin gui.

Old suggestions:suggestion:

One hacky solution is to run a screen grab node http://wiki.ros.org/screengrab_ros and position the rviz window just so, though it would be very brittle and hard to automate with launch files.

rviz_camera_stream publishes an image rendered in rviz. It builds in jade at least, but likely works in hydro and indigo, and following the fork back leads to a pre-catkin version.

It needs an input camera_info to get camera intrinsics and resolution. The distortion coefficients are ignored, but a image_proc like node that implements http://code.opencv.org/issues/1387 could address that downstream. (Do gazebo cameras support distortion yet?)yet? http://gazebosim.org/tutorials?tut=camera_distortion says version 5.0 does)

The input camera_info topic and output image topic are set in the rviz plugin gui.

Old suggestion:

One hacky solution is to run a screen grab node http://wiki.ros.org/screengrab_ros and position the rviz window just so, though it would be very brittle and hard to automate with launch files.