On Mon, Mar 22, 2010 at 2:18 PM, Blaise Gassend wrote: > Hi Jack, > >> OK, those files committed to camera_drivers_experimental/camera1394/src. > > Thanks for writing that up, this looks great. I have created ticket > ros-pkg#3921 to remind myself to push this into a higher up package. It > will probably take me a while to get to it as I am going full speed on > wifi issues these days. The only thing that I'll probably change > slightly when I move it into a common location is to allow url_ to be > modified. That way it can be dynamically configurable. (I hadn't thought > about that when I wrote up the strawman API.) I actually did think about that. It could be useful to set a different URL before running the calibration step. It would be easy to re-read the "calibration/url" parameter in the set_camera_info service callback. I didn't implement that in the initial version, but can easily add it. >> It uses camera_calibration_parsers for reading and writing YAML files. >> Some of those methods seem to behave strangely in cases where a file >> does not exist or is empty. I have not decided what to do about that, >> yet. > > Ticketed as ros-pkg#3922 I meant that I still need to make it work with the existing release as best I can. I don't remember the exact failures I observed, so I'll update the ticket as I get the details in further testing. I was not completely clear to me exactly what the bool return value signifies. Seems like the current implementation returns false if the file name does not end in .ini, .yaml, or .yml, but returns true with camera_name == "unknown" if the file does not exist. That seemed odd. >> I'll need to keep this initial implementation where it is for the >> present, because I want camera1394 to work with the boxturtle release >> to get more beta testing. If a future version moves to >> camera_calibration_parsers, I'll update camera1394 to use it in the >> next release. > > Sounds good. You are CCed on ros-pkg#3321, so you'll know when I get to > this. > >> I'd like to make this generally useful. There are things I don't know >> about ROS coding standards and practices. Feedback and suggestions >> would be helpful. > > I had a quick look, and this looks great. There is quite a bit of > variation from person to person. We try not to get too uptight about > details of coding style. -- joq