5 ms·

> real-world transmission times between e.g. London and San Francisco end up at around 150ms. That's [...] a catastrophe for self-driving cars needing to make r

> real-world transmission times between e.g. London and San Francisco end up at around 150ms. That's [...] a catastrophe for self-driving cars needing to make realtime decisions. Why in the world would/should a car in London be relying on a cloud computer in SF to tell it how to make real-time decisions...?

im_down_w_otp 8y ago
Most of the teleoperation companies at the moment. As far as I know. Worse still many are intending to gang onto the primary cellular infrastructure to perform the function. Which makes everything worse.
- perl4ever 8y ago
  It's fine if you are going to have your cars remotely controlled with a latency > 150 ms while they operate autonomously as things happen in a shorter time frame. But the other way around seems insane. It's reminiscent of the way people have switched from "human drives, computer deals with emergencies" to "computer drives, human deals with emergencies" as though it was no big difference.
  - Dylan16807 8y ago
    150ms is no big deal. That's on par with top-notch human reaction time. The big deal is the lack of reliability on that connection.
    - perl4ever 8y ago
      I would equate "lack of reliability" with "latency that is sometimes rather large".
      - Dylan16807 8y ago
        There is a qualitative difference between a jitter of a few dozen milliseconds, vs suddenly getting no data for twenty seconds because something went wonky.
    - tomxor 8y ago
      > 150ms is no big deal. That's on par with top-notch human reaction time. Comparing a single component latency in technology to human reaction time is a complete straw man i see far too often. (I'm not blaming you, you are probably just repeating it). 150ms _is_ a good human reaction time, but in technological terms that includes sensor, network, processor, network bus, actuator and finally any physical latency of action being achieved. A better and contextually relevant comparison here would be: human pressing a button after light turning on vs autonomous vehicle turning it's wheels 1 degree after seeing a light turn on. I bet you they are very similar, and I would not be surprised if the vehicle was slower. 150ms of network latency is significant because it's on top of the existing latency in the _whole_ system that makes up the car, including the sensors, the actuators whatever bus' inbetween them all. When you stick it's brain in the cloud and add 150ms of latency it's like a human trying to drive a car through a VR webcam, it will make it so much harder, 150ms latency between action and sensor is _very_ noticable even in humans, this is the same reason why cloud based FPS gaming (as in piping the result of the render over the network) doesn't work... no one is going to stick the brain of an autonomous vehicle behind 150ms of _additional_ latency.
      - Dylan16807 8y ago
        I evaluated those and left them out on purpose, because it doesn't change the answer. You can sample most sensors extremely fast, but let's say our camera is only 100Hz. 10ms there, 10ms for our processing loop, 0.5ms on each end for the LAN if you insist on it not being included in the 150, 5ms for a not-even-impressive actuator to affect the wheels... Now you're still under 180ms and you're still beating an average human. Being 'noticable' is a totally different thing. A human can notice single digit millisecond differences in timing. With adding control latency, there are two main problems, and neither one affects a system designed for remote control. One is that you're not used to it, and you have to undo a lifetime of learning to adjust. This goes the other way too, it would be very disorienting to magically make someone's body react 100ms sooner to every attempt at movement. The other big problem is that your movements and button presses no longer line up with the audiovisual feedback. It's really disorienting, and is going to make you miss a lot of shots in that FPS. If you could detach your hands and put them at the other end of the link somehow, that problem would be a lot easier. You already understand how to compensate for the latency of your fingers. You'd still have to get used to it, though.
DennisAleynikov 8y ago
If you are asking this question you are clearly more informed than the sales rep asking about being on the edge. The point wasn't that a car would ever do this. The point is that it would be absolutely ridiculous to do real time computation with such a high latency. Unless your question is rhetorical, there is no answer except "you would not do that" Some people out there for sure have no idea that the cloud is still bound by the constraints of physics and spacetime and that there is latency based on how close your servers are.
rurban 8y ago
People should stop coming up with such wrong metaphors. Real-time doesn't mean fast, it just means reliable latency. If you miss a cycle it needs to reboot or stop. But it doesnt mean that they are particularly fast. They are rather slow in fact. A real time controller in car would be perfectly fine with 150ms cycles, it just depends what is controlled. An engine controller is fine with 500Hz, a GPS controller with 10Hz, Formula 1 has 10Khz controllers, ... So if a costly central computing service is fine to control something in a car, it might be done. But obviously not as described in the article, they are not stupid. A central service would be async and not RT of course. Updating maps, traffic warnings, eg.
- mindentropy 8y ago
  > People should stop coming up with such wrong metaphors. Real-time doesn't mean fast, it just means reliable latency. If you miss a cycle it needs to reboot or stop. But it doesnt mean that they are particularly fast. They are rather slow in fact. This! In other words it is determinism. It should be highly deterministic. Most of the real time controllers even suggest to disable cache to be highly deterministic.
Johnny555 8y ago
I think the better question is why should a car be relying on a cloud computer at all for real-time decisions -- what would that car do when it's in a cellular dead zone?
- kybernetikos 8y ago
  While I don't want safety critical decisions to be made by cloud services so that my provider can charge me a premium to unlock even safer decision making, I think that it's pretty reasonable to start with full autonomy only on preprepared stretches of road. If that was the deal then you could have connectivity built into the road or road furniture and if the car detected a lack of connectivity it should come to a safe stop or revert to manual control. It seems like we could benefit from a technological principle of Subsidiarity. https://en.wikipedia.org/wiki/Subsidiarity https://en.wikipedia.org/wiki/Subsidiarity
- qznc 8y ago
  There are edge cases where it is possible. My employer sells Automated Valet Parking [0] where the video cameras of the garage are used to steer the vehicle. Of course, this is a well controlled space where you can ensure connectivity and the car will drive slowly so you can ensure safety. I don't believe safe real time and 5G cellular networks can be combined at reasonable scale. The latency is enough for some use cases, but reliability/connectivity/safety is not enough. So we still agree here. [0] https://www.bosch-mobility-solutions.com/en/highlights/automated-mobility/automated-valet-parking/ https://www.bosch-mobility-solutions.com/en/highlights/autom...

im_down_w_otp 8y ago

Most of the teleoperation companies at the moment. As far as I know. Worse still many are intending to gang onto the primary cellular infrastructure to perform the function. Which makes everything worse.

perl4ever 8y ago
It's fine if you are going to have your cars remotely controlled with a latency > 150 ms while they operate autonomously as things happen in a shorter time frame. But the other way around seems insane. It's reminiscent of the way people have switched from "human drives, computer deals with emergencies" to "computer drives, human deals with emergencies" as though it was no big difference.
- Dylan16807 8y ago
  150ms is no big deal. That's on par with top-notch human reaction time. The big deal is the lack of reliability on that connection.
  - perl4ever 8y ago
    I would equate "lack of reliability" with "latency that is sometimes rather large".
    - Dylan16807 8y ago
      There is a qualitative difference between a jitter of a few dozen milliseconds, vs suddenly getting no data for twenty seconds because something went wonky.
  - tomxor 8y ago
    > 150ms is no big deal. That's on par with top-notch human reaction time. Comparing a single component latency in technology to human reaction time is a complete straw man i see far too often. (I'm not blaming you, you are probably just repeating it). 150ms _is_ a good human reaction time, but in technological terms that includes sensor, network, processor, network bus, actuator and finally any physical latency of action being achieved. A better and contextually relevant comparison here would be: human pressing a button after light turning on vs autonomous vehicle turning it's wheels 1 degree after seeing a light turn on. I bet you they are very similar, and I would not be surprised if the vehicle was slower. 150ms of network latency is significant because it's on top of the existing latency in the _whole_ system that makes up the car, including the sensors, the actuators whatever bus' inbetween them all. When you stick it's brain in the cloud and add 150ms of latency it's like a human trying to drive a car through a VR webcam, it will make it so much harder, 150ms latency between action and sensor is _very_ noticable even in humans, this is the same reason why cloud based FPS gaming (as in piping the result of the render over the network) doesn't work... no one is going to stick the brain of an autonomous vehicle behind 150ms of _additional_ latency.
    - Dylan16807 8y ago
      I evaluated those and left them out on purpose, because it doesn't change the answer. You can sample most sensors extremely fast, but let's say our camera is only 100Hz. 10ms there, 10ms for our processing loop, 0.5ms on each end for the LAN if you insist on it not being included in the 150, 5ms for a not-even-impressive actuator to affect the wheels... Now you're still under 180ms and you're still beating an average human. Being 'noticable' is a totally different thing. A human can notice single digit millisecond differences in timing. With adding control latency, there are two main problems, and neither one affects a system designed for remote control. One is that you're not used to it, and you have to undo a lifetime of learning to adjust. This goes the other way too, it would be very disorienting to magically make someone's body react 100ms sooner to every attempt at movement. The other big problem is that your movements and button presses no longer line up with the audiovisual feedback. It's really disorienting, and is going to make you miss a lot of shots in that FPS. If you could detach your hands and put them at the other end of the link somehow, that problem would be a lot easier. You already understand how to compensate for the latency of your fingers. You'd still have to get used to it, though.

DennisAleynikov 8y ago

If you are asking this question you are clearly more informed than the sales rep asking about being on the edge. The point wasn't that a car would ever do this. The point is that it would be absolutely ridiculous to do real time computation with such a high latency. Unless your question is rhetorical, there is no answer except "you would not do that" Some people out there for sure have no idea that the cloud is still bound by the constraints of physics and spacetime and that there is latency based on how close your servers are.

rurban 8y ago

People should stop coming up with such wrong metaphors. Real-time doesn't mean fast, it just means reliable latency. If you miss a cycle it needs to reboot or stop. But it doesnt mean that they are particularly fast. They are rather slow in fact. A real time controller in car would be perfectly fine with 150ms cycles, it just depends what is controlled. An engine controller is fine with 500Hz, a GPS controller with 10Hz, Formula 1 has 10Khz controllers, ... So if a costly central computing service is fine to control something in a car, it might be done. But obviously not as described in the article, they are not stupid. A central service would be async and not RT of course. Updating maps, traffic warnings, eg.

mindentropy 8y ago
> People should stop coming up with such wrong metaphors. Real-time doesn't mean fast, it just means reliable latency. If you miss a cycle it needs to reboot or stop. But it doesnt mean that they are particularly fast. They are rather slow in fact. This! In other words it is determinism. It should be highly deterministic. Most of the real time controllers even suggest to disable cache to be highly deterministic.

Johnny555 8y ago

I think the better question is why should a car be relying on a cloud computer at all for real-time decisions -- what would that car do when it's in a cellular dead zone?

kybernetikos 8y ago
While I don't want safety critical decisions to be made by cloud services so that my provider can charge me a premium to unlock even safer decision making, I think that it's pretty reasonable to start with full autonomy only on preprepared stretches of road. If that was the deal then you could have connectivity built into the road or road furniture and if the car detected a lack of connectivity it should come to a safe stop or revert to manual control. It seems like we could benefit from a technological principle of Subsidiarity. https://en.wikipedia.org/wiki/Subsidiarity https://en.wikipedia.org/wiki/Subsidiarity
qznc 8y ago
There are edge cases where it is possible. My employer sells Automated Valet Parking [0] where the video cameras of the garage are used to steer the vehicle. Of course, this is a well controlled space where you can ensure connectivity and the car will drive slowly so you can ensure safety. I don't believe safe real time and 5G cellular networks can be combined at reasonable scale. The latency is enough for some use cases, but reliability/connectivity/safety is not enough. So we still agree here. [0] https://www.bosch-mobility-solutions.com/en/highlights/automated-mobility/automated-valet-parking/ https://www.bosch-mobility-solutions.com/en/highlights/autom...