search

duckietown / gym-duckietown

Self-driving car simulator for the Duckietown universe
http://duckietown.org
Other
51 stars 19 forks source link

Dynamic obstacles #39

Closed bhairavmehta95 closed 6 years ago

bhairavmehta95 commented 6 years ago

This PR deals with adding dynamic obstacles - in this case, only pedestrian duckies that walk across the road, which can be specified by adding:

static: False
pedestrian: True

To the object's description in the YAML File.

In domain rand. mode, they walk across the same specified distance (ROAD_TILE_WIDTH) at randomized speeds, and have randomized time intervals between their walks.

I tried to vectorize as much as possible (see _update_dynamic_obs() and update_pedestrians()) and I tried to run as many tests as possible, but we will need to play around with it to get especially the speed that they should walk across correct. I believe my current setting is a bit too high.

Tested w. draw-bbox mode + domain-rand mode, as well as different combinations of maps. To test, I've added a small map called loop_obstacles_pedestrians.

bhairavmehta95 commented 6 years ago

duckie

Why did the duckie cross the road? To get to his home in the master branch :sweat_smile:

nithin127 commented 6 years ago

Haha nice!

On Thu 12 Jul, 2018, 8:45 PM Bhairav Mehta, notifications@github.com wrote:

[image: duckie] https://user-images.githubusercontent.com/10503729/42666664-78a7856c-8614-11e8-8067-481cc9df420d.gif

Why did the duckie cross the road? To get to his home in the master branch 😅

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/duckietown/gym-duckietown/pull/39#issuecomment-404692479, or mute the thread https://github.com/notifications/unsubscribe-auth/AHSlFlhJlJ7wPKF15vOXQerRrQo3fKvdks5uF-3AgaJpZM4VOInx .

maximecb commented 6 years ago

Looks pretty cool.

The main thing I don't like though is that we're adding so many new variables to the simulator. This is a lot of code, and as you pointed out, the simulator class is getting a little too fat.

I'm a bit torn because I can see that you put quite a bit of efford trying to numpy-ify this code for efficiency. At the same time, I think maybe it's not necessary for this. We might only have a handful of moving duckies in a given map, so maybe we can make the tradeoff.

I'm thinking, we probably want to start factoring things in a more OOP way. Currently, I just have a dictionary for objects. We probably want to have a base class for objects. WorldObj or something like that. Each object should have a position, an angle, a step() method, probably also a render() method, and another method that tells us if its static or not, is_static. Then we can have a DuckieObj class that inherits from this base class. That way, all of the duckie's parameters can be encapsulated within the duckie object itself. What do you think?

Two other details:

bhairavmehta95 commented 6 years ago

Totally agree -- what I will say is that when I had some problems writing this efficient version, I switched to a more OO way, and while it ends up being way simpler, you can't use the advantages of numpy (which as you pointed out, for our use case is probably okay, but that's why I ended trying to make this version work).

I would prefer the class / OO method bc of the fact it makes the code way cleaner, and it seems that you do as well, so I will start making the switch to this. The nice thing is that if after that is implemented, it drops the efficiency by too much, we can always just revert and merge this commit.