Traffic lights

[abdelq]

This PR includes blinking traffic lights.

A thing to note: added a third optional parameter to pos in the map format to allow the ability to specify the position in the y axis (see 4way.yaml).

[maximecb]

Code looks pretty good. A few things:

• Can you upload a screenshot/gif/YouTube?

• Why did you need to specify a Y coordinate for the traffic light? Does it not properly align with the ground automatically?

• I think it would be a good idea for the traffic light object to have either a state field which is a string (ie: 'red' or 'green'), or a function so we can do "trafficLight.is_green". This is because eventually other objects (including NPCs and possibly other traffic lights) are going to need to query their state.

[abdelq]

Quick screencast

Why did you need to specify a Y coordinate for the traffic light? Does it not properly align with the ground automatically?

For simplicity, the traffic light is the cube only, without the full metal support.

I think it would be a good idea for the traffic light object to have either a state field which is a string (ie: 'red' or 'green'), or a function so we can do "trafficLight.is_green". This is because eventually other objects (including NPCs and possibly other traffic lights) are going to need to query their state.

A question beforehand, are all the sides of the cube red/green at the same time? I never saw them in person, so I assumed N/S sides would be red when E/W are green, and vice versa.

By the way, a duckiebot might collide with the traffic light because the height is pretty damn low, since the angle of the bot is down and it needs to be visible.

[maximecb]

For simplicity, the traffic light is the cube only, without the full metal support.

Oh I see. I was imagining a more real-world-like setup with multiple streetlights, but the streetlight is centered and projects to all sides at the same time. That makes sense. I would still like to have the metal support be modeled (even if crudely).

A question beforehand, are all the sides of the cube red/green at the same time? I never saw them in person, so I assumed N/S sides would be red when E/W are green, and vice versa.

We will still need that method to query the street lights to know when crossing is allowed.

By the way, a duckiebot might collide with the traffic light because the height is pretty damn low, since the angle of the bot is down and it needs to be visible.

Yeah, I think we need to increase the FOV to match the wide-angle raspberri pi camera. We can't have the street lights be this low. That's nothing like the real-world ones.

[abdelq]

@maximecb Oops, I pushed after rebasing by mistake. I haven't finished yet implementing the changes.

[abdelq]

Changed the model and added the helper function. Let me know your thoughts.

As for the FOV, I will leave that to the expert :stuck_out_tongue:.

The collision is still a problem. I believe the collision box is maybe too big and doesn't fit the 3D model properly (shaped like a big box). One very simple solution would be to disable it, the car can't reach the box and getting near the beams is a collision with non-drivable terrain.

[maximecb]

Disabling collision detection with traffic lights seems like a good solution. We already disable collision checks for objects that are not on drivable tiles.