RL example: Platoon #1955
RL example: Platoon #1955
Conversation
Adaickalavan
commented
Apr 11, 2023
Adaickalavan
commented
- Added baseline example, consisting of training, inference, and zoo agent registration, for the platooning task in Driving SMARTS 2023.3 benchmark.
- Documented the challenge objective, desired inference code structure, and use of baseline example, for Driving SMARTS 2023.3 benchmark, i.e., platooning task.
| $ cd <path>/SMARTS | ||
| $ docker build --file=./examples/rl/platoon/train/Dockerfile --network=host --tag=platoon . | ||
| $ docker run --rm -it --network=host --gpus=all platoon | ||
| (container) $ cd /SMARTS/examples/rl/platoon |
There was a problem hiding this comment.
Is it worth it to instead set WORKDIR /SMARTS/examples/rl/platoon at the end of the image?
There was a problem hiding this comment.
Currently the Dockerfile sets WORKDIR /SMARTS , which I try to make consistent across various dockerfiles. This helps when we have examples in different paths, as the dockerfile can be built similarly and we only need to alter the command issued.
I simply reiterated the full path here $ cd /SMARTS/examples/rl/platoon to avoid any confusion for the users.
| agent_params = { | ||
| "top_down_rgb": interface.top_down_rgb, | ||
| "action_space_type": interface.action, | ||
| "num_stack": 3, # Number of frames to stack as input to policy network. |
There was a problem hiding this comment.
Is it worth it to integrate the frame stack as part of the agent interface? This seems to be a common case.
There was a problem hiding this comment.
If we were to include frame stacking inside AgentInterface, we would then have to provide a standard way of stacking the observations. It may or may not fulfill the users' requirements. Users might only need selected (and/or processed) observations to be stacked, whereas our standard frame stacking would have stacked entire observations. Considering the endless possible user requirements, I guess it is better we leave it to the user.
| class ObjDict(dict): | ||
| def __getattr__(self, name): | ||
| if name in self: | ||
| return self[name] | ||
| else: | ||
| raise AttributeError("No such attribute: " + name) | ||
|
|
||
| def __setattr__(self, name, value): | ||
| self[name] = value | ||
|
|
||
| def __delattr__(self, name): | ||
| if name in self: | ||
| del self[name] | ||
| else: | ||
| raise AttributeError("No such attribute: " + name) |
There was a problem hiding this comment.
This is fun I suppose, is this inspired by javascript?
There was a problem hiding this comment.
Yes, it is fun. ObjDict helps to access a key in a dictionary using . (similar to accessing attributes in a dataclass), instead of using string dict["key"]. I felt the former leads to nicer code and thus used it in the training script.
|
Really only suggestions rather than requirements. |
Co-authored-by: Tucker Alban <[email protected]>
… into platoon-example
