Closed miquelmassot closed 10 years ago
Hi,
I guess the issue comes from the ROS publisher, which is reading osg image buffer while it is being updated. I'm quite sure, it happens in every scene but usually rendering refresh rate is too high to see changes in the image, but cirs_sls scene requires rendering many cameras and refresh rate is not enough.
Another possible bug it comes to my mind is if moving vehicles in ros subscribers could cause something like this, but I think OSG has something to prevent it (moving cameras are quite common). So I would say issue comes from readings.
Can you check if it happens in ros images only?, I mean I wasn't able to reproduce it on uwsim main window (widgets) so I guess these images are from ROS readings?
True, those were saved in a bagfile for later image extraction. I'll try to see if I can see that happening on the widget. I'll report later.
I cannot see it in the widget. There may be something wrong with the ROS publisher.
It should be fixed on last commit.
In my computer, uwsim crashes after a couple of seconds. The window remains open and I have to kill uwsim_binary from another terminal. I'm using underwater_simulation from source and the other related packages from debians. (I'm on an optimus computer)
In another computer (non optimus), it's working flawlessly. Everything has been installed from source. Could you check also that?
Uhm,
I have it working both, everything installed from source and using other related packages from debians. Haven't tested it on an optimus computer.
Is every scene crashing or just cirs_sls scene?, does uwsim window open correctly, can you see the scene?. I've done some tests and I'm not able to reproduce it. It just crashes when I add around 6 cameras with high resolution(2048x1536), but I think my pc it is just not able to handle that amount of cameras (It works around 0.3 fps before crashing).
The same scene, cirs_sls.xml in 1.3.1 is working at 9 fps. With the new changes of image buffer, it crashes, at 6.61 fps in less that 5 sec. Same data in the xml. Is it my pc then?
No, anyway it shouldn't crash. I think the performance decrease it's fine as synchronizing rendering and publishing for many cameras takes some time.
Maybe if publishing needs too much time the callback draw is not able to copy the image and keeps waiting being unable to refresh main window. When it crashes, the main window freezes?. I was able to reproduce something like that adding delays on publishers. Is your roscore being executed in the same pc as UWSim?, that would explain publish times longer.
Yes, I've got a roscore and UWSim in the same computer. Nothing else is running in ROS appart from those two.
And yes, it freezes the window, and I have to kill directly the process with a "killall uwsim_binary".
So, should I move the core outside of the machine? Doesn't make sense to me.
On 23 May 2014 11:09, Javier Perez notifications@github.com wrote:
No, anyway it shouldn't crash. I think the performance decrease it's fine as synchronizing rendering and publishing for many cameras takes some time.
Maybe if publishing needs too much time the callback draw is not able to copy the image and keeps waiting being unable to refresh main window. When it crashes, the main window freezes?. I was able to reproduce something like that adding delays on publishers. Is your roscore being executed in the same pc as UWSim?, that would explain publish times longer.
— Reply to this email directly or view it on GitHubhttps://github.com/uji-ros-pkg/underwater_simulation/issues/37#issuecomment-43991707 .
Miquel Massot
miquel.massot@gmail.com http://www.facebook.com/massothttp://www.twitter.com/resisteixhttp://gplus.to/massot
Sorry I wrote it wrong, It would make sense if core was executed in another PC. But anyway that image freezing means it's stuck on drawing. Can you check if topics are still publishing while UWSim main windows is frozen?.
I will try to fix it soon.
Nice catch! True, it's publishing everything, even images. But the images are static, I cannot see floating particles moving on it.
On 23 May 2014 12:05, Javier Perez notifications@github.com wrote:
Sorry I wrote it wrong, It would make sense if core was executed in another PC. But anyway that image freezing means it's stuck on drawing. Can you check if topics are still publishing while UWSim main windows is frozen?.
I will try to fix it soon.
— Reply to this email directly or view it on GitHubhttps://github.com/uji-ros-pkg/underwater_simulation/issues/37#issuecomment-43995615 .
Miquel Massot
miquel.massot@gmail.com http://www.facebook.com/massothttp://www.twitter.com/resisteixhttp://gplus.to/massot
Are you forcing that the topics have to be published at a certain framerate?
On 23 May 2014 12:20, Miquel Massot Campos miquel.massot@gmail.com wrote:
Nice catch! True, it's publishing everything, even images. But the images are static, I cannot see floating particles moving on it.
On 23 May 2014 12:05, Javier Perez notifications@github.com wrote:
Sorry I wrote it wrong, It would make sense if core was executed in another PC. But anyway that image freezing means it's stuck on drawing. Can you check if topics are still publishing while UWSim main windows is frozen?.
I will try to fix it soon.
— Reply to this email directly or view it on GitHubhttps://github.com/uji-ros-pkg/underwater_simulation/issues/37#issuecomment-43995615 .
Miquel Massot
miquel.massot@gmail.com http://www.facebook.com/massothttp://www.twitter.com/resisteixhttp://gplus.to/massot
Miquel Massot
miquel.massot@gmail.com http://www.facebook.com/massothttp://www.twitter.com/resisteixhttp://gplus.to/massot
Yes, that was the problem. Publish topic is publishing at a fixed framerate, if this rate is high it does not allow to refresh main window, which waits for publisher in order not to overwrite the image is being published. Now I used a mutex to synchronize and limited publishing lock to image copy.
Now if I delay image copy in publisher it drops down fps but still refreshes main window. Hope it works for you and we can close the issue ;).
Nice and smooth. 9,5 fps in UWSim and 10fps in the image topic.
Hi there,
we've noticed a strange issue in UWSim when running with stereo cameras. Sometimes you can see that an image has not been fully updated to the current frame. That can be seen as an image, half of it belonging to the current frame, half of it to the previous. A jump can be clearly seen in the image.
Please find attached one example, ran with cirs_stereo.xml. This issue has been noticed both in computers with bumblebee and without it.
Left image:
Right image:
![right000003](https://cloud.githubusercontent.com/assets/1611148/2904313/8e0a3d9c-d5fa-11e3-94be-6f2bf16551ee.png)
I can't say if this has happened before. If it had, I didn't notice.