Save gym data to tub files

[Bleyddyn]

I wanted to be able save data returned by the DonkeyCar simulator into tub files. Rather than having to add a new entry for each item (reward, done, cte, etc) I added support for saving dictionaries to the tub format. I also added support in the drive code and the DonkeyGymEnv class.

My fork has diverged quite a lot so I haven't created a pull request but I can if there's interest.

My changes are in these two commits

Bleyddyn@0964d0f
Bleyddyn@552493f

[tawnkramer]

the default setup from donkey will write out data returned from the sim to tub files.

[Bleyddyn]

I think I've checked everywhere in master that might have that code but I can't find it. Any suggestions where to look?

[tawnkramer]

If you run the Donkeycar framework with the DONKEY_GYM = True in myconfig.py then it will use the Tub manager to save data.

…

On Mon, Jun 8, 2020 at 10:08 AM Bleyddyn ***@***.***> wrote: I think I've checked everywhere in master that might have that code but I can't find it. Any suggestions where to look? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABKJZ6W7Y7VH4HUZBDBSL3RVULJ3ANCNFSM4M463V5Q> .

[Bleyddyn]

No-one else seems to be interested in this so it's kind of a moot point, but I ran this find in both master and dev of autorope/donkeycar:

$ find . -name '*.py' -exec grep -H '.info' {} ; | grep -v "logging.info" | grep -v "logger.info"
./donkeycar/parts/dgym.py: self.info = { 'pos' : (0., 0., 0.)}
./donkeycar/parts/dgym.py: self.frame, _, _, self.info = self.env.step(self.action)

So DonkeyGymEnv is collecting the info dictionary returned by the the simulator, but there's no code that I can find that's doing anything with it, like saving it to a Tub file.

[joostaafjes]

I like this option!! +1 @tawnkramer In my setup I have set DONKEY_GYM to True, no SYM data is written to the Tub record_*.json files, e.g. this is my output:

{"cam/image_array": "7072_cam-image_array_.jpg", "user/angle": 0.933952532316509, "user/throttle": 0.35, "user/mode": "user", "milliseconds": 373228}

[wallarug]

Hey @Bleyddyn do you still have issues with this in the latest Donkey V4.0 dev branch? Happy to pick this one up.

[Bleyddyn]

@wallarug Sorry I haven't checked out v4.0 yet. If there's any interest you're welcome to check out the commits I linked.

[wallarug]

Hey @Bleyddyn ,

I've taken a good look at the changes you have proposed. I've spent a lot of time the past few weeks working on exactly the same parts to get the 'extra' information back out to Donkey Car.

In particular, I wanted to speed variable out of that info array.

#673

I take a little bit of issue with the way you have done it here in your PR (because I made the same mistake as well when I first submitted a PR to get speed). It doesn't conform to the same standard as all the other Donkey Car Parts. All the other Donkey Car Parts that are sending back information from the simulator or a piece of hardware send back only single datatypes, not lists or dicts. For example: speed - float, throttle - float, angle - float, break - float, image - array. No two things are sent back and if they are, they are send separately like:

this

return throttle, angle, brake

not

ret = [throttle, angle]
return ret, brake

To make your change standard, instead of sending back info, only send back what you need/want out of that object. I could pass sending back coordinates in an array/list/dict/json because they will always need to be linked.

change to this style...

return self.frame, self.info['speed'], self.info['pos']

The other thing to note with this change - it is a breaking change. It affects all the template files and removes backwards compatibility from previous manage.py's in Donkey Car. I am not 100% of a fan of my own changes either but there doesn't appear to be a better way at this point to add the new features.

I did note you created another class - I still do not think this is the best way either to be merged into the core repository. I am more in support of putting the changes in permanently to the existing part and forcing everyone to update. I think it is a better long-term strategy.

Happy to take feedback on the above too, I am not the expert.

[Bleyddyn]

I'm fine with returning individual pieces of data, although in my case it will start to get messy pretty quickly since I want: speed, cross track error, reward, done flag, and yaw (which I will have to add to the simulator at some point).

As for the template files, whether I return to using the baseline donkeycar code or stick with my fork, I'm certainly not going back to using the template files. I overwrote my changes too many times for that and I really think the majority of that code should be moved into the library and only referenced from the template code (e.g. https://github.com/Bleyddyn/donkeycar/blob/dev/donkeycar/drive/drive.py).

[wallarug]

I highly recommend you update to a more current version of Donkey Car. It looks like your repo is well over 480 commits behind. 3.1.0 is very old. It will be very difficult for the maintainers to merge in any of your feature requests.

As for the template files, whether I return to using the baseline donkeycar code or stick with my fork, I'm certainly not going back to using the template files. I overwrote my changes too many times for that and I really think the majority of that code should be moved into the library and only referenced from the template code (e.g. https://github.com/Bleyddyn/donkeycar/blob/dev/donkeycar/drive/drive.py).

I have been discussing this problem with a few of the maintainers and I believe they are moving back towards one template file again. So this will not help yourself or anyone else who are making large changes.

[Bleyddyn]

I'm not sure when it happened but it looks to me like at least some of the sim data are now being saved to v2 Tub files.

[luigidiguglielmo-devel]

Commit #985 causes problems with saving gym data to tub files. I'm experiencing the very same issue described here:
#583 (comment)

Everything works perfectly until #983.