I have a launch file set up to let me quickly start streaming video from my camera (on another machine) and start (locally) image_view and dynamic_reconfigure/reconfigure_gui at the same time. It works great and I really like the whole roslaunch idea. Now normally if I start image_view manually and click on the window it will save frames to the current directory. But it seems like if it's started in a launch file, the image isn't saved anywhere. I looked in a bunch of places such as /tmp, in my ROS_PACKAGE_PATH, etc. rxconsole shows a message indicating that a jpeg is actually being produced and there is no error message. Anyway I recall something on the list recently about this and found the below message, but it seems to be more about the larger issues. So my question is, is there any quick way to specify a specific directory (that I have write access to) to image_view when it is started via a launch file? Thanks, Pat P.S. The search functionality on the list archive still seems to be broken... ---------- Forwarded message ---------- From: Blaise Gassend To: ros-users@code.ros.org Date: Fri, 19 Mar 2010 10:46:05 -0700 Subject: Re: [ros-users] Digital Camera 1394 in ROS? > A recent discussion on ros-users had convinced me that roslaunch is > essentially hostile to the whole idea of writing files from nodes. It > goes out of its way to change the current working directory to > something useless rather than allow nodes to conveniently write test > output to the current directory. Discouraging writing files to the current directory (whatever it happens to be) is very different from discouraging writing files at all. We store hardware logs files in well known locations. We have .urdfs in a well known location. We access devices at well known locations. We could totally store device configuration at a well known location. /etc/ros/camera_calibration/left_stereo.yaml would be a candidate. > Apparently, the thinking is that files should generally only be read > from or written to package directories. Reading from packages makes > sense in many cases, but I really dislike the idea of storing > per-device calibration data in a package directory. Packages are > source code. They should be sharable read-only. In many cases package directories are going to be read-only, so I wouldn't consider writing to package directories to be something encouraged. > My idea was to use the parameter server for this. Persistent > calibration then becomes a matter of using "rosparam dump" and > "rosparam load" to save and restore the data. This is useful for much > more than just cameras. Many servo devices require calibration. It > could also be helpful for parameters tuned via machine learning. > > This approach works cleanly and transparently in a distributed system > environment. > > Nothing in CameraInfo is too high-bandwidth for the parameter server > to become a bottleneck. The camera driver would simply read its > parameters as usual. If the CameraInfo is not available it publishes a > default setting. (Rviz and other tools should handle that correctly -- > it's not an error, just a new, uncalibrated device.) When calibration > runs, it calls SetCameraInfo. The current instance of the driver > stores the data, also writing them back to the parameter server. > > I like this approach better than the file manager you suggested. But, > perhaps there are issues I have not considered. Further suggestions > and comments are welcome. The thing I don't like about the parameter server approach is that you have to manually do the rosparam dump after you have calibrated the camera. Your launch file will then probably be loading those dumped parameters from a well-known location. So you still have the file, but now you additionally need to be taking some extra steps when you do your calibration (which in some cases is a good thing). Perhaps the right answer is for the CameraInfoManager class to be able to handle files, parameters and flash, using a url to determine which one it wants. In the case of flash, it does a callback to the driver, which takes whatever steps are needed to store to flash. file:///etc/ros/camera_info/left_forearm.yaml parameter:///~camera_info flash:///1 This way even for cameras that have flash, the user has the option of picking a different source. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ ros-users mailing list ros-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ros-users