[Rock-dev] Problem with mixed sizes of typekit types
Thomas Roehr
thomas.roehr at dfki.de
Thu Jul 20 19:21:39 CEST 2017
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 at 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.roehr at 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
-----------------------------------------------------------------------
More information about the Rock-dev
mailing list