Re: FW: [win_ros] rosbag for windows (#54)

[Daniel Stonier]

Hi Predrag,

On 15 November 2012 11:11, Predrag Djurdjevic <p_e_...@hotmail.com> wrote:

Hi Daniel,


How are things going on your end, haven't heard much news from you and/or win_ros groups lately, so I thought I'd ping you, and I had couple of questions for you if you have some time.

We put a freeze on what we were doing on fuerte to let the software guys start learning. I also had to urgently dive into some other projects - Kobuki/Turtelbot2 and a multimaster project.

 

- Last time we left of at the point where most of the non-core packages, like nodelets which PCL, OpenCV etc. depend on, were still in the process of being converted to catkin and you anticipated ~3+ months, which is just around the corner. I know these are not necessarily the packages you track, but is your assessment still that the pace of these is still on target? By that I mean just the CMakeLists, not the C/C++ code itself, as I'm sure there will be a lot required for me to adapt it to make it work transparently on windows.

It's shaping up well. It is much more logical and we might even be able to put an msi installer backend on their packaging scripts. Beta should become release in a week or two.

 

- Related to above, can nodelets be put on the win_ros roadmap, meaning is this a matter of adopting changes from Linux repositories or there would be further adaptations specific to win_ros on top?

Once beta is frozen and released, I'll start looking at updating win-ros - there's bound to be catkin cmake/python porting issues on windows since the catkin updates were quite sweeping Once that's done we can start looking at porting stacks again.

Nodelets floated to the top for me as well. Also - the blocker we had with a non-catkinized pluginlib is mostly gone. They only had about 50 packges catkinized for fuerte (pluginlib and nodelets weren't included). They've now got 260+ core stacks catkinized (including pluginlib/nodelet) so there's alot more to work with now.

- There is the new groovy distribution now available, is this still experimental or actually already recommended for general consumption?

I'm currently testing the groovy beta to get up to speed and have started releasing linux packages using it. Beta should become release in a couple of weeks. 

 

- What is the delta from fuerte to groovy as far as affect to win_ros?

Catkin had quite alot of changes, so we'll have to just work through catkin and update/fix bugs due to things being different on windows. Good news is that groovy's catkin is now looking close to being a finished product though.

 

- Has anybody successfully made use of the CMake 2.8.7 GUI to generate the files more easily?

Is this something new? I thought the cmake gui on windows was just a way of inspecting and modifying cache variables.

 

- There is a new Perforce Fusion plugin for Git, anyone used this yet?

Never tried this - I am still either command line or an eclipse git gui guy. 

In short, wanted to sync up with you as to where things were with win_ros/groovy/nodelets in terms of buildability, at some point I'd like to pick it up again, it's just a matter of where's a good pivot point for me. Meanwhile I went to Matlab/CUDA/C++11 code for simulations which is in itself rather involving but at the same time very powerful stuff.

 

Cool.  We're looking at about a 3-4 week window for attacking win-ros again. I'll keep you updated.

Cheers,

Daniel.

 

Cheers,
Predrag

---

From: p_e_...@hotmail.com
To: d.st...@gmail.com
Subject: RE: [win_ros] rosbag for windows (#54)
Date: Sat, 4 Aug 2012 17:23:32 -0600

Hi Daniel,

>>

Fuerte was a first trial run for catkin. Only the core stacks got converted - this gave them a good chance to road test it internally without disturbing the rest of the community just yet. It was a good thing as quite a few unexpected repurcussions arose.

 

True - it shouldn't take much work. win_roscpp_tutorials is a good example of the current state for creating c++ packages. If you look at the other packages (e.g. those from ros_comm), there's a fair bit of variation that happened as they were testing things.
<<

A little confused now, if other packages can still operate the old way, why can't the ones related to nodelet and nodelet itself? If one package is done the catkin way, do the other dependent (on it) packages also need to be? More specifically for windows, if it (nodelet) could be made to run on windows does ti matter which cmake scripts does the configuration.bat use, or are you implying that it needs to be catkin for windows?

I looked at http://www.ros.org/wiki/rosbuild/CMakeLists/Examples, ros_comm CMakeLists from diamondback/electric and from fuerte, even though there are some observable differences, most still don't resonate with me. It would be good to critically examine these diffs on one/same file pre- and post-catkin, and infer the rationale behind it. Once you are back online on Skype, maybe we could interactively go over an example CMakeLists from ros_comm or nodelet.

>>
... next is qt.

The sooner the better for us. I've been doing qt with mingw for a long time, that was good for us control guys. But I'm now passing ros onto the windows software team so the sooner they have a compatible build environment with us on linux, the better.
<<

Good news is that Qt works under MSVS, or side-by-side, made an example with signals/slots from scratch and can compile/link/debug it. The not-so-good is that plugins only work on standard(and up) versions of MSVS, so 2010 Express is unfortunately not compatible. Also the question of ownership Trolltech->Nokia->??? and the effect on further evolution for Qt5, MSVS12 and beyond.


>> Off to australia for holidays for a week! I'll not be far from email though. <<

Well, enjoy the Olympics.


Regards,
Predrag

---

Date: Mon, 30 Jul 2012 20:58:38 +0900
Subject: Re: [win_ros] rosbag for windows (#54)
From: d.st...@gmail.com
To: p_e_...@hotmail.com

On 28 July 2012 10:34, Predrag Djurdjevic <p_e_...@hotmail.com> wrote:

Hi Daniel,


>>

Passing should be fine, but what if you want to work on the image? Don't you have to copy out of the ros msg (Image.msg) format and into the cv_bridge/opencv image format, do the work, then copy back before publishing again?

The cv_bridge image container is cv::Mat, while the ros Image.msg container is std::vector.

<<

Trying to reinterpret their description (cv_bridge wiki) for bgr8/mono8, if one is getting an image out of the read-only accessor, I suppose due to linear packing of data, byte pointers underling 2D Mat and 1D vector are just cast to each other but pixel memory is unchanged. One the other hand if one wants to modify images, they need to get it out of the copy accessor, I presume it may just involve memcpy rather than pixel model change.

Indeed - I was looking at working on the image over a couple of levels without inducing delay. I wonder if most of the time I'd want to be making copies anyway.

 

>>

Good targets for porting. However these are all still using the old ros build system. Not the new catkin. We can either wait a bit (probably 2-3 months) at which point in time willow will convert/upgrade most of these stacks for the new ros release. Or we can make temporary patches - this would involve rewriting the CMakeLists.txt files to be in a similar format to the other winros stacks. Winros' configure script (and subsequently catkin) is looking for the new CMakeLists.txt calls to determine whether to include it in the build or not (if I remember correctly it is looking for cmake catkin_stack() and catkin_project() calls).

If you want to try, let me know and I can provide some tips on how to do that.
>>

I didn't realize that, I was under the impression that fuerte was synonymous to catkin, particularly on a package that's so pervasive ~70 dependents.  I may give it a shot if there is a well defined pattern/algorithm to changes and is confined to following dependency packages

Fuerte was a first trial run for catkin. Only the core stacks got converted - this gave them a good chance to road test it internally without disturbing the rest of the community just yet. It was a good thing as quite a few unexpected repurcussions arose.

 

\bond_core
\pluginlib
\driver_common\dynamic_reconfigure
\nodelet_core

and it takes less than  2-3 months ;)

True - it shouldn't take much work. win_roscpp_tutorials is a good example of the current state for creating c++ packages. If you look at the other packages (e.g. those from ros_comm), there's a fair bit of variation that happened as they were testing things.

 

>>
Qt used to have a dual license. If you wanted to use it on windows for free, you could use the LGPL licensed Qt with the Mingw compiler. If you wanted to use it with MSVisual Studio, you had to buy the commercial license.

After Nokia bought Qt, they dropped the commercial license, so I believe you can integrate Qt directly into the visual studio ide's without having to buy a license now. I have not tried this yet though, so I don't know how problematic/feasible this is.
<<

If that turns out to be feasible, it is going to be a win-win both for windows guys and contributing back for linux use, are you guys contemplating to attempt to go this route anytime soon?

Basically first target for us was ros comms (which is now good thanks to the actinlib port being finalised), next is qt.

The sooner the better for us. I've been doing qt with mingw for a long time, that was good for us control guys. But I'm now passing ros onto the windows software team so the sooner they have a compatible build environment with us on linux, the better.

Off to australia for holidays for a week! I'll not be far from email though.

Daniel.

--
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/

Yujin R&D: http://rnd.yujinrobot.com/

[Daniel Stonier]

On 20 November 2012 14:04, Predrag Djurdjevic <p_e_...@hotmail.com> wrote:

Hi Daniel,

great to hear from you, couple of additional clarifications, as always:

>>>>

- Last time we left of at the point where most of the non-core packages, like nodelets which PCL, OpenCV etc. depend on, were still in the process of being converted to catkin and you anticipated ~3+ months, which is just around the corner. I know these are not necessarily the packages you track, but is your assessment still that the pace of these is still on target? By that I mean just the CMakeLists, not the C/C++ code itself, as I'm sure there will be a lot required for me to adapt it to make it work transparently on windows.

It's shaping up well. It is much more logical and we might even be able to put an msi installer backend on their packaging scripts. Beta should become release in a week or two.

m

- Related to above, can nodelets be put on the win_ros roadmap, meaning is this a matter of adopting changes from Linux repositories or there would be further adaptations specific to win_ros on top?

Once beta is frozen and released, I'll start looking at updating win-ros - there's bound to be catkin cmake/python porting issues on windows since the catkin updates were quite sweeping Once that's done we can start looking at porting stacks again.

Nodelets floated to the top for me as well. Also - the blocker we had with a non-catkinized pluginlib is mostly gone. They only had about 50 packges catkinized for fuerte (pluginlib and nodelets weren't included). They've now got 260+ core stacks catkinized (including pluginlib/nodelet) so there's alot more to work with now.

<<<<

Are nodelets now included in those 260+ (for groovy?) and how does one check the list, as they were the stepping stone for some of the others (PCL, OpenCV, camera, Kinect)? Under the assumption it's there, for win_ros, are additional CMakeLists modifications anticipated to go on top, or is it some other aspect of configuration, excluding C/C++ sources which is a given?

 

You can check the sources for each package. The old style packages had a manifest.xml, the new style ones have a package.xml. For example. you can see nodelet here: https://github.com/ros/nodelet_core/tree/master/nodelet.

There is a complete list somewhere of 'catkinized' packages, but I can't recall where right now.

>>>>

- Has anybody successfully made use of the CMake 2.8.7 GUI to generate the files more easily?

Is this something new? I thought the cmake gui on windows was just a way of inspecting and modifying cache variables.

<<<<

Maybe I read to much into this, I assumed that it was also able to check the validity of the CMakeLists vs. the source folders, just that without help files, couldn't figure out how to use it. It always errors out on a bunch of stuff even thought the same folders build without any hiccups with win_ros.

I've only done the linux thing - cmake from the command line, rebuild via another make or cmake, then use the gui for cmake cache variable changes. You might be able to use it for the whole process though, never tried.  If you have issues trying it again in the future, copy/paste me the errors. It might be something simple.

 

Cheers,

Daniel.

>>>>
Cool.  We're looking at about a 3-4 week window for attacking win-ros again. I'll keep you updated.

<<<<

I'm still ~4-6 weeks away from my code where I want it, the timing alignment should turn out just fine.


Cheers,
Predrag

---

Date: Mon, 19 Nov 2012 11:56:48 +0900
Subject: Re: FW: [win_ros] rosbag for windows (#54)
From: d.st...@gmail.com
To: p_e_...@hotmail.com
CC: win...@googlegroups.com