This repository has been archived by the owner on Jan 25, 2021. It is now read-only.
Added multiple enhancements, documented in Training_analysis.ipynb accordingly #12
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.
My racing name is Myth
This change has been submitted as part of the AWS DeepRacer Community Log Analysis Challenge. To join the community go to http://join.deepracing.io
In my log-analysis I have
removed the steps/time graph and replaced it with a new graph. This shows the difference between histograms of actions used in the first iteration vs the last iteration. When you want to speed up your model, this will be quite useful to see how frequently the actions with higher-speed values are triggered, and whether their frequency has increased over the training.
colour coded the almost useless total_reward/episode graph according to start_at. The original graph varies a lot over the episodes rendering it useless. This variation is because each episode starts at a different waypoint. So if there is a hard turn at waypoint 100, an episode starting at waypoint 0 will have a quite higher total reward than an episode starting at waypoint 80. But if total_rewards of episodes with similar start_at positions are compared, we are able to find a pattern, making it a quite useful tool. Colour coding this graph according to start_at solves this problem.
Added greyscale colourmap to the bottom 3 graphs of scatter_aggregates. This graph is very useful already, and helps us find bottlenecks in the track where our model is struggling by giving us exact waypoint numbers. But it tells very little about whether our current training session has improved the model in these bottleneck areas or not. Adding a grayscale colourmap shows movement of the 3 graphs across the iterations. This coupled with Enhance log analysis #2 makes for a very powerful analysis tool.
Improved the code for plotting paths taken in an entire iteration. This is a useful tool and is used by everyone who doesn't want to keep starting at the screen for the entire training session. In the original code it took about 10-20 seconds to plot all the paths in one iteration, making it very frustrating to keep checking up on the paths in each iteration during training. The enhanced code does this in less than a second. You can add code to plot multiple graphs of multiple iterations if you'd like to, without worrying about needing to wait for minutes.
Possible improvement: I am currently fiddling with the idea of using a similar code to improve the speed of 'heatmap plotter of all rewards' (the red and black graph). Similar to the above, this code is also used quite frequently but requires an unneccesarily long time to execute due to the 'for' loops.
I'd be really glad to see someone pull this off.
added a cell that plots the perfect race line within seconds. This code runs a dummy car across a dummy track using bresenham raycasting to find the perfect race line.
Possible improvement: Currently the perfect race line that is plotted will overlap a bit because I have not provided a very intelligent stopping condition. The code runs for fixed number of steps, this could be improved to merge the overlapping regions to get a final race line. Another improvement is printing the entire raceline's co-ordinates so that it could be used in the reward function. I have done this in my personal log-analysis notebook and intend to make a commit soon. In the meantime if you'd need to implement it for your own use right now, contact me on slack.
Added a boolean flag called "wp" that enables you to label waypoints on the track in any graph in the log analysis notebook.
Improved new_reward feature. This feature produced slightly inaccurate reward values due to different implementations of df_to_params function in the log_analysis.py and inside the actual simulation. Also it was incomplete. Now it is implemented exactly as inside the simulation, also 'track_width' and 'is_left_of_center' params are now available for those who use them in their reward functions (again, implemented exactly as inside the simulation).
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.