Open InigoMoreno opened 3 years ago
Hi @InigoMoreno ,
I will take a look at it soon. Maybe @vbargsten has a better idea of what is happening here, since he recently reimplemented this part.
After a first quick look at the logfile, here seems to be the error:
$ docker run --interactive --rm --tty --volume "$PWD":/wd --workdir /wd -it af01/pocolog2msgpack -l waypoint_navigation.log --only /gps.pose_samples -v 5
[pocolog2msgpack] Verbosity level is 5.
[pocolog2msgpack] Only converting port '/gps.pose_samples'.
[pocolog2msgpack] 1 streams
[pocolog2msgpack] Stream #0 (/gps.pose_samples): 25392 samples
[pocolog2msgpack] Converting sample #0
[pocolog2msgpack] Converting sample of size 429
20 ee 29 0b 8a 51 05 00 04 00 00 00 00 00 00 00 62 6f 64 79 09 00 00 00 00 00 00 00 77 6f 72 6c
64 5f 6f 73 67 00 48 5f 8a 65 17 65 40 00 00 f3 c4 bb 50 6e 40 00 48 e1 7a 14 ae 01 c0 a3 60 d6
15 eb 43 f5 3e 60 08 07 d5 11 da d2 3e 00 00 00 00 00 00 00 00 60 08 07 d5 11 da d2 3e 18 d0 fb
75 ef b9 f5 3e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c1 93 16
2e ab ...
Could you say what kind of data you expect in the first sample of the stream /gps.pose_samples
?
/gps.pose_samples
should contain values of gps data, with valid position and orientation. You can actually successfully run pocolog on it, and even replay it on a ruby script
pocolog waypoint_navigation.log -s /gps.pose_samples --to 0
gives us the first sample:
pocolog.rb[INFO]: loading file info from /media/heimdal/Dataset1/9June/Traverse/20170609-1909/waypoint_navigation.idx...
/gps.pose_samples.time.microseconds /gps.pose_samples.sourceFrame /gps.pose_samples.targetFrame /gps.pose_samples.position.data[0] /gps.pose_samples.position.data[1] /gps.pose_samples.position.data[2] /gps.pose_samples.cov_position.data[0] /gps.pose_samples.cov_position.data[1] /gps.pose_samples.cov_position.data[2] /gps.pose_samples.cov_position.data[3] /gps.pose_samples.cov_position.data[4] /gps.pose_samples.cov_position.data[5] /gps.pose_samples.cov_position.data[6] /gps.pose_samples.cov_position.data[7] /gps.pose_samples.cov_position.data[8] /gps.pose_samples.orientation.im[0] /gps.pose_samples.orientation.im[1] /gps.pose_samples.orientation.im[2] /gps.pose_samples.orientation.re /gps.pose_samples.cov_orientation.data[0] /gps.pose_samples.cov_orientation.data[1] /gps.pose_samples.cov_orientation.data[2] /gps.pose_samples.cov_orientation.data[3] /gps.pose_samples.cov_orientation.data[4] /gps.pose_samples.cov_orientation.data[5] /gps.pose_samples.cov_orientation.data[6] /gps.pose_samples.cov_orientation.data[7] /gps.pose_samples.cov_orientation.data[8] /gps.pose_samples.velocity.data[0] /gps.pose_samples.velocity.data[1] /gps.pose_samples.velocity.data[2] /gps.pose_samples.cov_velocity.data[0] /gps.pose_samples.cov_velocity.data[1] /gps.pose_samples.cov_velocity.data[2] /gps.pose_samples.cov_velocity.data[3] /gps.pose_samples.cov_velocity.data[4] /gps.pose_samples.cov_velocity.data[5] /gps.pose_samples.cov_velocity.data[6] /gps.pose_samples.cov_velocity.data[7] /gps.pose_samples.cov_velocity.data[8] /gps.pose_samples.angular_velocity.data[0] /gps.pose_samples.angular_velocity.data[1] /gps.pose_samples.angular_velocity.data[2] /gps.pose_samples.cov_angular_velocity.data[0] /gps.pose_samples.cov_angular_velocity.data[1] /gps.pose_samples.cov_angular_velocity.data[2] /gps.pose_samples.cov_angular_velocity.data[3] /gps.pose_samples.cov_angular_velocity.data[4] /gps.pose_samples.cov_angular_velocity.data[5] /gps.pose_samples.cov_angular_velocity.data[6] /gps.pose_samples.cov_angular_velocity.data[7] /gps.pose_samples.cov_angular_velocity.data[8]
1497028218187296 98 111 100 121 119 111 114 108 100 95 111 115 103 168.73114508256549 242.52292106114328 -2.2100000000000364 2.0280176035920025e-05 4.4946276180364683e-06 0 4.4946276180364683e-06 2.0719823964079979e-05 0 0 0 0.00019600000000000002 0 0 -0.39394190959093656 -0.91913533925524071 0 0 0 0 0 0 0 0 1918.4399999999998 nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan
Update, I ran rock-convert waypoint_navigation.log
and then pocolog2msgpack
was successful on the updated logfile.
While I managed to resolve my issue, I think a more detailed error message should be added to help future users.
OK, thanks. Do you have any idea how we can detect the old log format? What does rock-convert actually do?
I found about rock-convert
in this tutorial. Not sure where it is documented, but it seems to update the base-types in logs if they have been changed since the log was recorded.
As for detecting the old base-types I am not exactly sure, maybe we could check for the byte size of the type versus what is stored in the log, but I'm not sure how to do that.
OK, I think we can leave the issue open and I will add a hint to the readme. It has low priority for me at the moment so I'm not sure when I can take a closer look. I don't know how pocolog does it internally...
I checked yesterday and found that there is definitely a problem with the type initialization. At this point https://github.com/orocos-toolchain/typelib/blob/a247e11c8c7a3770fc5f81959a934178d1bf13d4/lang/csupport/containers.cc#L493, there is no valid string object in the memorylayout -- and thus clear or append won't work (it failed for a type of RigidBodyState with 2 strings being initialized).
Hello, I was trying to transform a log to msgpack and I got a segmentation fault. The file is included in this zip file.
I have been messing around to try to find the source of the error and I suspect the segmentation fault happens in this line.
Typelib::load( val, data.data(), data.size() );