Re: [ipwave] traffic lights status displayed in the car, and the latency problem

[Alexandre Petrescu <[e-mail]>]

Hi Chris,

Le 30/08/2019 à 10:52, Chris Shen a écrit :
> Hi Alex,
> 
> Thanks Alex, it is good to see this experiment.
> 
> About the latency, it seems that you use a shared cloud server for 
> both car and traffic light to access. That is the traffic light 
> updates its status to the cloud server, and the car queries the
> cloud server if there is any update. There is no direct
> communication between the traffic light and the car. So how do you
> measure the E2E latency from car to traffic light?

Thank you for the reply.

Do you consider a cloud server that stores the status of traffic lights?

We measure the E2E latency in two manners: the RTT displayed by ping
command between laptop and traffic lights controller, and the time
difference between the UDP DIASER request and response recorded on the
laptop.  See the points 1 and 2 below.

The car does not query the cloud server, but it queries the traffic
lights controller through VPN.  The traffic lights controller does not
send its status periodically to a server, but it responds to requests
issued by the laptop through VPN.  We do not store the traffic lights
status on the server. If we did this, then it would add up to the latency.

1. the VPN server in the cloud is a rendez-vous point.  It runs OpenVPN
software.  The car laptop opens an openvpn connection to this server.
Also the router-modem of the traffic lights controller opens such a
connection to the same VPN server.  Once the two VPN connections are
open, the car laptop can ping the router-modem of the traffic light
controller and thus note the RTT reported by ping command.  This ping
gets through the VPN server.

2. the laptop originates an UDP DIASER request for status of traffic
lights.  This request is captured by the wireshark in the laptop.  This
UDP DIASER request is sent on the Internet, arrives at VPN server and
gets forwarded to the router-modem attached to the traffic lights
controller.  The router-modem does port forwarding and forwards the
request to the controller.  The controller sends back the UDP DIASER
reply containing the status.  This UDP DIASER reply is captured by the
wireshark in the laptop.  The time difference between those two messages
makes for the E2E latency.


Alex

> 
> Thanks! Chris.
> 
> On Fri, Aug 30, 2019 at 5:15 PM Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
> 
> Hi,
> 
> Has someone else filmed a demo of displaying the traffic lights 
> status in the car?  (a communicated status, not a camera recognized 
> status).
> 
> We filmed recently several such trials.  We noticed a systematic 
> problem with latency.  This problem lies in the difference between 
> the color displayed by the traffic light bulb and the color
> displayed in the car.
> 
> Ideally, at no time should a human perceive a difference between
> what the light bulb displays and what the laptop displays in the
> car.
> 
> https://youtu.be/RR5hpL29-vk
> 
> At point 3 second, the bulb displays green whereas the laptop 
> displays red.  This undesirable situation lasts for 1 second.  It is
>  an enormous time lapse.  It is sufficient for the driver to loose 
> confidence in the laptop display, and it is ample time for a 
> self-driving car to do many undesirable things.  A typical reason
> for human loosing confidence in laptop display is that during such
> lapse of time (1 second) in many places in Paris area one gets
> honked (klaxonned) if one is first in line and does not leave at a
> moment's notice; because the last in line risks having to wait a
> second cycle - everyone in line knows that and at least one will honk
> (klaxon). It is forbidden to klaxon in city.
> 
> For this video, we did our best to reduce the latency.  The 
> communication path between the traffic lights controller and the car
>  was set with 4G.  There are two 4G links in sequence: one between
> the traffic lights controller and the VPN server in the cloud, and 
> another between the VPN server and the car.  The measured end-to-end
>  latency from laptop to traffic lights controller averages 100ms.
> The queries to obtain the status of lights are sent with a frequency
> of approx. 20 Hertz, which is approx. each 50ms. (DIASER on UDP on 
> IPv4).  The laptop is a recent thinkpad with python doing queries
> and display.  The traffic lights controller is an Aximum Maestro with
> a Motorola MC-something.
> 
> We could put 802.11-OCB there, to further gain on the communication 
> latency.
> 
> We could try recent pre-5G chipsets.
> 
> We could try the ITS-G5 SPAT-EM technology which relies on DIASER 
> still.
> 
> But we are not sure the 1s delay exposed above will get any 
> improvement by any of these steps.
> 
> This is why I am asking if this situation of latent display of 
> traffic lights in car was witnessed elsewhere, and which paths could
>  be explored to improve the latency?
> 
> Alex
> 
> 
> _______________________________________________ its mailing list 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/its
> 
> 
> 
> -- Yiwen (Chris) Shen, Ph.D. Candidate
> 
> Homepage: https://chrisshen.github.io IoT Lab: 
> _http://iotlab.skku.edu <http://iotlab.skku.edu/>_ Sungkyunkwan 
> University, Suwon, South Korea Mobile:[phone] Email: 
> [e-mail] <mailto:[e-mail]>