yekigoc / rosjava

Automatically exported from code.google.com/p/rosjava
0 stars 0 forks source link

RosCameraViewPreview isn't properly recorded with rosbag #29

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Run the android_tutorial_camera project on an Android phone.
2. Record the /camera/image_raw topic using rosbag.
3. Play back the bag file.

What is the expected output? What do you see instead?
The expected output is that the CompressedImage messages are recorded and the 
image data will be visible upon playback.

Instead, the data field of the CompressedImage is empty in all recorded 
messages.

What version of the product are you using? On what operating system?
Using latest version of rosjava source compiled against electric.

Please provide any additional information below.
The images are viewable using image_view at the time of being recorded, however 
the bag file does not actually contain the image data. It appears that 
something is causing rosbag to record corrupted CompressedImage messages 
because running "rosbag check <bagfile>" causes very strange behavior, e.g. 
spawning many rospack processes and causing many strange errors to be output.

Perhaps rosjava does not properly implement something that prevents rosbag from 
properly recording the uint8[] data field in CompressedImage.

Attached is a sample bag file. Note that the topic recorded is not 
"/camera/image_raw", but "/camera/image/compressed" as I changed the published 
topic to properly conform to the expected topic names as mentioned in Issue #22.

I would really like to know if anyone else can reproduce this issue.

Original issue reported on code.google.com by ersso...@gmail.com on 31 Aug 2011 at 5:26

Attachments:

GoogleCodeExporter commented 9 years ago
I just repeated this test again tonight after updating the ros-electric 
packages and I am now able to properly record using rosbag! Not sure if 
something was fixed... the ros-electric-image-pipeline package was updated; 
perhaps a bug was fixed?  Or maybe something else changed on my end?  I did 
launch Wireshark to verify that the full packets were indeed being transmitted, 
but that's the only thing that changed other than the update.

In any case, I think this issue can be closed.

Original comment by ersso...@gmail.com on 1 Sep 2011 at 3:31

GoogleCodeExporter commented 9 years ago

Original comment by damonkoh...@google.com on 4 Jan 2012 at 9:54