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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 30 August 2019 08:14 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A012080A for <its@ietfa.amsl.com>; Fri, 30 Aug 2019 01:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.63
X-Spam-Level:
X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peXfPPjbQczz for <its@ietfa.amsl.com>; Fri, 30 Aug 2019 01:14:50 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5409120113 for <its@ietf.org>; Fri, 30 Aug 2019 01:14:49 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x7U8El3g094454 for <its@ietf.org>; Fri, 30 Aug 2019 10:14:47 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9318720373B for <its@ietf.org>; Fri, 30 Aug 2019 10:14:47 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 74EEC200DC5 for <its@ietf.org>; Fri, 30 Aug 2019 10:14:47 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x7U8ElZ3008153 for <its@ietf.org>; Fri, 30 Aug 2019 10:14:47 +0200
To: "its@ietf.org" <its@ietf.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b1f427f0-6ddc-89c9-1822-0bca8ce6185b@gmail.com>
Date: Fri, 30 Aug 2019 10:14:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------589A336827F8231BB6E7E953"
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/fjkBF6DT9POwyD8q9MSXfpC1S8s>
Subject: [ipwave] traffic lights status displayed in the car, and the latency problem
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Aug 2019 08:14:53 -0000

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