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

Rosbag duration in index_recorded_data.py #240

Open
Nanoseb opened this issue Apr 30, 2018 · 8 comments
Open

Rosbag duration in index_recorded_data.py #240

Nanoseb opened this issue Apr 30, 2018 · 8 comments

Comments

@Nanoseb
Copy link
Member

Nanoseb commented Apr 30, 2018

In the generated html some durations are quite off, for example the bag from the 4th of September 2017 "14:49:47 [horten_fleetrace]" lasted only 1 minute but seems to be a bit longer ;)

@takluyver
Copy link
Member

Here's where it comes from:

duration = b.get_end_time() - b.get_start_time()

@Nanoseb
Copy link
Member Author

Nanoseb commented May 16, 2018

maybe related to ros/ros_comm#952

@Nanoseb
Copy link
Member Author

Nanoseb commented Jun 17, 2018

Ok the issue is more scary than that :/
The time is ok because the bagfile is not complete, 14:49:47 [horten_fleetrace] for example should be quite long but it lasts 1min and weight 13M... so we've lost some data.

@takluyver
Copy link
Member

Sometimes we get .bag.active files - I think when ROS isn't shut down cleanly. We copied some code we found to fix them up into usable .bag files, but I haven't looked into what it's doing. I assumed you lost some data in that case, but I would have expected it to be the last couple of minutes rather than most of your run.

If the Raspi lost power while ROS was running, that may cause further data loss - data written to file will initially be cached in volatile memory, so it can still be lost on a power failure. Maybe the system caches writes quite heavily to minimise write cycles on the flash storage.

If I found the time, I'd love to dig into this issue more. If Rosbag is doing something that fails badly when it loses power, a better recording system could be really valuable to a lot of projects.

@smaria
Copy link
Member

smaria commented Nov 9, 2018

Interesting. i was under the assumption the map plots are generated from the bags. However, looking at /dbg_distance_to_waypoint for 14:49:47 [horten_fleetrace], no waypoint is reached. Where does the complete plotted triangle race come from, if not from said bag?

(as a side note, it is rather inconvenient that the message types recorded in a rosbag are not contained in the bag, I currently don't have a workspace for sailrobot at hand, and it does put a question mark on data longevity, so I can't easily look at the actual gps data)

@Nanoseb
Copy link
Member Author

Nanoseb commented Nov 9, 2018

Map plots are generated thanks to the dump of the gps trace (.csv file formatted according to the rules). See https://www.southampton.ac.uk/~yc6n13/sailing-robot/gps-trace_horten_fleetrace_2017-09-04T14.49.52.csv

@smaria
Copy link
Member

smaria commented Nov 12, 2018

Thanks for explaining.
It seems to be accepted that rosbag drops messages if the storage device is not fast enough.
https://answers.ros.org/question/240948/rosbag-record-dropping-and-corrupting-data/
That seems an unlikely reason for our problem, both considering the low amount of data we generate and that the rosbag just stops rather than missing a couple of messages.

It may be worth setting the rosbag recording node to respawn, at least in the model launch file this is not the case: https://github.com/Maritime-Robotics-Student-Society/sailing-robot/blob/master/src/sailing_robot/launch/model_launch_file.launch

This won't get us to the bottom of this, but should this be due to rosbag crashing, the next time it happens we should notice two bags being recorded and we will only miss a smaller amount of data. Is it possible to dig out the ROS log files from that date? Is there any chance this rosbag is not the correct one for the map data?

There is also one more unsolved report of rosbag dropping data: https://answers.ros.org/question/62833/rosbag-not-recording-every-message/

@takluyver
Copy link
Member

At the moment the indexing uses the rosbag to define when a run starts and ends. If the recording restarts, you'll likely see an extra run in the index without the GPS trace or parameter dump. (Or the indexing might crash if it assumes the GPS trace is there). I'm sure there are ways to work round that.

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

No branches or pull requests

3 participants