Hey Dennis, can you check if that is related:
https://github.com/orocos-toolchain/typelib/issues/95 Best Thomas On 09.06.2017 14:06, Alexander Fabisch wrote: > Hi Dennis, > > I think I have a similar problem: the problem seems to be the offset of > strings, right? I assume that if you subtract the offset of sourceFrame > from the offset of targetFrame you SHOULD get something like the size of > the the type that has been used to encode the length of the string (8 > Byte vs. 32 Byte)? I have a logfile that looks like type a and a logfile > that looks like type b but the actual length is encoded in the first 8 > Byte of the string in both cases. You can check that if you look > directly at the binary data in the logfile with "hexdump -C <file>": > > > 00000820 ... 0c 00 00 00 00 00 00 00 |9...............| <- 0c 00 > 00 00 00 00 00 00 == 12 > > 00000830 68 65 6c 6c 6f 77 20 77 6f 72 6c 64 02 ff 01 00 |hellow > world....| > > Best regards, > > Alexander > > > Am 09.06.2017 um 12:35 schrieb Dennis Hemker: >> Hey Guys, >> >> I encountered a weird problem during the use of the C++-based >> rock-replay2, which uses the local typekit definitions to load >> marshalled types from the log files. In some logfiles, the local and the >> marshalled typekit type mismatch in their sizes, for instance the >> RigidBodyState_m type. The log was recorded with the Sherpa-Bot in Utah: >> >> type a: >> compound /base/samples/RigidBodyState_m [416] { >> (+0) compound /base/Time [8] { >> (+0) sint(8) (/int64_t) microseconds >> }; time >> (+8) container /std/string</int8_t> sourceFrame >> (+16) container /std/string</int8_t> targetFrame >> (+24) compound /wrappers/Matrix</double,3,1> [24] { >> (+0) array[3] of >> float(8) (/double) data >> }; position >> (+48) compound /wrappers/Matrix</double,3,3> [72] { >> (+0) array[9] of >> float(8) (/double) data >> }; cov_position >> (+120) compound /wrappers/Quaternion</double> [32] { >> (+0) array[3] of >> float(8) (/double) im >> (+24) float(8) (/double) re >> }; orientation >> (+152) compound /wrappers/Matrix</double,3,3> [72] { >> (+0) array[9] of >> float(8) (/double) data >> }; cov_orientation >> (+224) compound /wrappers/Matrix</double,3,1> [24] { >> (+0) array[3] of >> float(8) (/double) data >> }; velocity >> (+248) compound /wrappers/Matrix</double,3,3> [72] { >> (+0) array[9] of >> float(8) (/double) data >> }; cov_velocity >> (+320) compound /wrappers/Matrix</double,3,1> [24] { >> (+0) array[3] of >> float(8) (/double) data >> }; angular_velocity >> (+344) compound /wrappers/Matrix</double,3,3> [72] { >> (+0) array[9] of >> float(8) (/double) data >> }; cov_angular_velocity >> }; >> type b: >> compound /base/samples/RigidBodyState_m [464] { >> (+0) compound /base/Time [8] { >> (+0) sint(8) (/int64_t) microseconds >> }; time >> (+8) container /std/string</int8_t> sourceFrame >> (+40) container /std/string</int8_t> targetFrame >> (+72) compound /wrappers/Matrix</double,3,1> [24] { >> (+0) array[3] of >> float(8) (/double) data >> }; position >> (+96) compound /wrappers/Matrix</double,3,3> [72] { >> (+0) array[9] of >> float(8) (/double) data >> }; cov_position >> (+168) compound /wrappers/Quaternion</double> [32] { >> (+0) array[3] of >> float(8) (/double) im >> (+24) float(8) (/double) re >> }; orientation >> (+200) compound /wrappers/Matrix</double,3,3> [72] { >> (+0) array[9] of >> float(8) (/double) data >> }; cov_orientation >> (+272) compound /wrappers/Matrix</double,3,1> [24] { >> (+0) array[3] of >> float(8) (/double) data >> }; velocity >> (+296) compound /wrappers/Matrix</double,3,3> [72] { >> (+0) array[9] of >> float(8) (/double) data >> }; cov_velocity >> (+368) compound /wrappers/Matrix</double,3,1> [24] { >> (+0) array[3] of >> float(8) (/double) data >> }; angular_velocity >> (+392) compound /wrappers/Matrix</double,3,3> [72] { >> (+0) array[9] of >> float(8) (/double) data >> }; cov_angular_velocity >> };Checking /body_joint.state >> >> Differences can be found in the source- and targetFrame definitions. >> >> Thank you and best regards, >> >> Dennis >> >> _______________________________________________ >> Rock-dev mailing list >> Rock-dev@dfki.de >> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev > -- Thomas Röhr (M.Sc.) Space Robotics Besuchsadresse der Nebengeschäftstelle: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 5 28359 Bremen, Germany Postadresse der Hauptgeschäftsstelle Standort Bremen: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 1 28359 Bremen, Germany Tel.: +49 421 178 45-4151 Zentrale: +49 421 178 45-0 Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen) E-Mail: thomas.ro...@dfki.de Weitere Informationen: http://www.dfki.de/robotik ----------------------------------------------------------------------- Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973 Steuernummer: 19/673/0060/3 ----------------------------------------------------------------------- _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev