Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix rosbag recording #38

Closed
chris-smith opened this issue Nov 2, 2016 · 3 comments · Fixed by #48
Closed

Fix rosbag recording #38

chris-smith opened this issue Nov 2, 2016 · 3 comments · Fixed by #48
Labels

Comments

@chris-smith
Copy link
Collaborator

rosbag seems to depend on publishers including the message definition in their connection header although that field is not mentioned in the spec. Without the message definition, rosbag tools complain about mismatching md5 sums.

Including the message definition still results in different bags, though I'm not certain if this is a problem.

Message definition in connection header for a rosnodejs bag

message_definition=# A Pose with reference coordinate frame and timestamp
    Header header
    Pose pose

Message definition in connection header for a rospy bag

message_definition=# A Pose with reference coordinate frame and timestamp
Header header
Pose pose

================================================================================
MSG: std_msgs/Header
# Standard metadata for higher-level stamped data types.
# This is generally used to communicate timestamped data 
# in a particular coordinate frame.
# 
# sequence ID: consecutively increasing ID 
uint32 seq
#Two-integer timestamp that is expressed as:
# * stamp.sec: seconds (stamp_secs) since epoch (in Python the variable is called 'secs')
# * stamp.nsec: nanoseconds since stamp_secs (in Python the variable is called 'nsecs')
# time-handling sugar is provided by the client library
time stamp
#Frame this data is associated with
#0: no frame
#1: global frame
string frame_id

================================================================================
MSG: geometry_msgs/Pose
# A representation of pose in free space, composed of postion and orientation. 
Point position
Quaternion orientation

================================================================================
MSG: geometry_msgs/Point
# This contains the position of a point in free space
float64 x
float64 y
float64 z

================================================================================
MSG: geometry_msgs/Quaternion
# This represents an orientation in free space in quaternion form.

float64 x
float64 y
float64 z
float64 w

@chris-smith
Copy link
Collaborator Author

The difference in message definition appears to break some rosbag tools, although rosbag play doesn't mind.

From running rosbag fix on the rosnodejs pose bag.

Traceback (most recent call last):
  File "/opt/ros/indigo/bin/rosbag", line 35, in <module>
    rosbag.rosbagmain()
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rosbag/rosbag_main.py", line 836, in rosbagmain
    cmds[cmd](argv[2:])
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rosbag/rosbag_main.py", line 371, in fix_cmd
    migrations = fixbag2(migrator, inbag_filename, outname, options.force)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rosbag/migration.py", line 152, in fixbag2
    res = checkbag(migrator, inbag)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rosbag/migration.py", line 76, in checkbag
    for topic, msg, t in bag.read_messages(raw=True):
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rosbag/bag.py", line 2119, in read_messages
    yield self.seek_and_read_message_data_record((entry.chunk_pos, entry.offset), raw)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rosbag/bag.py", line 2257, in seek_and_read_message_data_record
    msg_type = _get_message_type(connection_info)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rosbag/bag.py", line 1353, in _get_message_type
    message_type = genpy.dynamic.generate_dynamic(info.datatype, info.msg_def)[info.datatype]
  File "/opt/ros/indigo/lib/python2.7/dist-packages/genpy/dynamic.py", line 151, in generate_dynamic
    for l in msg_generator(msg_context, spec, search_path):
  File "/opt/ros/indigo/lib/python2.7/dist-packages/genpy/generator.py", line 736, in msg_generator
    genmsg.msg_loader.load_depends(msg_context, spec, search_path)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 344, in load_depends
    return load_msg_depends(msg_context, spec, msg_search_path)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 313, in load_msg_depends
    depspec = load_msg_by_type(msg_context, resolved_type, search_path)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 119, in load_msg_by_type
    file_path = get_msg_file(package_name, base_type, search_path)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 78, in get_msg_file
    % (base_type, package, search_path))
genmsg.msg_loader.MsgNotFound: Cannot locate message [Header]: unknown package [std_msgs] on search path [{}]

@ZHOUYue67
Copy link

If I understand it right, this commit (0b5c68d) trim the indent in message definitions if only we generate the messages using ros_msg_utils here. But some users may still use gennodejs which still generate spaces in message definitions. I'll create an issue there.

And since gennodejs is widely used, I think rosnodejs should consider the case that sometime users might need to use .js message files already generated by gennodejs even if gennodejs fixes the indentations in later versions, for compatibility reason. Maybe we can add an optional feature in rosnodejs which will trim the spaces when creating the publish headers. (here or here or wrap this class here)

By doing these we can fix this issue for good.

@ZHOUYue67
Copy link

I can do a pull request. But first I need some comments and feedback from other people.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants