CarRacing corrupt frames when not rendering visually
Closed this issue · 9 comments
When using CarRacing-v0 and not using render() explicitly, the frames from step() are corrupt. Mainly it's always 4 quadrants with a green or gray L shape regardless of what steps I perform (Attached 2 examples).
I've tracked it down to the call to 'win.dispatch_events()' in the render() function of the CarRacing() class, which isn't called in case of mode="state_pixels".
Calling the dispatch_events() even once after creating the window seems to solve it.
Attached also notebook which shows the issue and workaround.
I am also having this problem.
Same problem here. Just opened a similar issue #990 before noticing this one. Sorry for that. Thanks for your solution :)
#MeToo
Proposed workaround--something like:
if "dispatch_events_called" not in self.__dict__ and mode == 'state_pixels': win.dispatch_events() self.dispatch_events_called = True
At line 354 of gym/envs/box2d/car_racing.py
I am having a similar problem Issue #1267 . I cannot figure out how to run the modified SAC, which I think offers a solution to the problem.
@Bhaney44 I don't understand how SAC (modified or not) can offer a solution to a rendering problem in the environment. Moreover, to our best knowledge, the issue as described by @opherlieber should have been fixed by the commit above. If you are still facing the issue, please include the code / commands that you are running, versions of os and gym, and the details of the error - and we'll re-open this issue (or you can create a new one).
@pzhokhov see issue 1267. According to @jachiam
the default actor-critic code for SAC (and other algorithms in Spinning Up) creates MLP networks, which expect vector inputs and will produce errors for image-shaped inputs (as you have found). If you want to use the Spinning Up algorithm implementations with CarRacing-v0, you will have to write custom actor-critic functions that are compatible with image-shaped inputs.
Josh is right. So, to successfully execute an agent in this environment the user needs to write their own DRL algorithm because the default produces errors. And, users are unable to run the default from the command line.
In other words, success in this environment requires looking under the hood, finding where the default code is on the machine, and figuring out how to change the default code so it executes properly. I would love to work more on this, but I have other priorities consuming my time. I do plan to spend some time on this problem in mid-late April. However, if anything new arises in the interim - please let me know.
Thanks
@Bhaney44 @jachiam The code in spinningup can easily be modified to work with image-shaped inputs. Today, I modified PPO to work with environments like vizdoom and miniworld by modifying the following:
Instead of reshaping observations as o.reshape(1, -1), use o.reshape(1, *o.shape) (or other functionality to add batch dimension). In the core.py file, if you're extremely lazy like me and just want to have it work on image inputs, you can add some convolutional layers to the input then flatten it. I have found that this approach can solve some simple environments; I haven't done extensive testing beyond proof of concept and getting it to work.
@alexandervandekleut Prove it. OpenAI Leaderboard.