# rosbag topics with same MD5sum

Hi,

I've recorded a bag file in which I've detected that two types has the same MD5sum, according with the output of rosbag info

types:       navigation_g500/PNIPrimeImu [98c511aab3d6095235f8db7d430feee5]


I've checked that the __s_getMD5Sum_ were the same in the PC I recorded the bag; probably because of some old bug of mine.

Could somebody help me to find out how to fix de bag file? I want to read the msgs with rosbag::View, and I have all the code done and working; I've been reguarlarly using it with other types/topics inside bag files.

UPDATE

For the particular problem I have, with rosbag fix I end up with the msgs of type PNIPrimeImu turned into XsensMTiImu, with is wrong.

I forget to say that the Raw view of rxbag shows the PNIPrimeImu msgs correctly.

edit retag close merge delete

What version of ROS and Ubuntu were you using when those MD5Sums were generated? And just to verify... the messages did not contain the same body at that time, right?

( 2012-04-30 08:40:53 -0500 )edit

ros-electric and ubuntu oneiric. The messages are different. For some reason the MD5sum (and the name) where the same in the PC I record the bags. I'll try Chad Rockey's steps so see if I can recover/fix the messages. Anyway, I've also repeated the experiments.

( 2012-05-02 09:00:21 -0500 )edit

Sort by » oldest newest most voted

This problem means that your message definitions are the same. Likely you have the same message with two different filenames.

You're having problems with 'rosbag fix' only right? I'm assuming that your bags are properly indexed and if they aren't you can run rosbag reindex on them.

In order to migrate, you'll likely have to first split the topics into two separate bags. The tool to use for this is rosbag filter. For example try:

rosbag filter original.bag PNI.bag "topic == '/pni_imu'"


Now that you have bags with only one of the problematic types, you should be able to set up your environment so that you can migrate. This is pretty complicated, so I can't give you a complete list of steps to take, but here's some things to check:

• Make sure your new messages don't have this same problem (identical datatypes in the definition).
• Make sure you only don't have the old messages built currently.
• Make sure you only have one migration rule exported at a time.

You probably don't have to make sure all of these are true, but if you keep having problems, if I didn't forget anything, that should be all you need to resolve this migration.

Good luck! :D

more

I'm going to try it, thanks! Not immediately tough, since I've repeated the experiment, and I can live without the "corrupted" bag file.

( 2012-05-02 09:01:47 -0500 )edit