Open
Conversation
Contributor
Author
|
Oh I forgot to mention, if you want to test this out, just pull this branch and run |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I wanted to know what you guys thought about this. One thing some of us think would be really nice is if we had a way to log messages being published into the scrimmage system in some kind of binary format that could be played back later, sort of like rosbags. The main problem with this is that scrimmage messages are just shared pointers to c++ classes and can't be readily serialized and logged.
However, I think boost serialization might offer us a solution. It supports all native c++ data types for serialization, including STL containers, and allows you to write pretty minimal code to expose your own custom classes to its API. If you attempt to serialize a class that doesn't have the necessary hooks written, it will fail at build time. I was playing around with it and was able to write a plugin that publishes a std::vector of scrimmage::State objects, which is then serialized into XML and logged in a file. This could enable us to log all messages being passed through the system and be able to recreate them later, which would be especially helpful when running scrimmage plugins inside of a larger context.
Also, we could utilize this to create a "rostopic echo" like function that could read this log file during the simulation and print its data to the screen, which is another thing I know several people have been wishing for.
Let me know what you guys think.