QUIC will be more than a replacement for TCP once we will have broken the speed boundary that allows a distant server to control a robot (which requires quick reaction speeds to correct for instability time constants). For now, everyone is forced to embark their decision algorithms on Jetson Nanos to control robots, which makes prices quite high, in a certain future where time frames will be optimized, we can see "Robotic controlling as a service" platforms, that will make the price of robots drop by a significant ammount
So what are you going to do when (not "if") your internet connection suddenly drops?
Unless you are okay with robots crashing into things at full speed, you'll always need some kind of local control loop, so full-remote control will never happen.
Offloading the goal decision to the cloud is very much possible, but that doesn't require an ultra-low-latency connection as (due to the above) the robot should be fine with no new feedback for a second anyways.
Decoupling between layers will be essential ! You will have high level commands sent from a distant server to a local gateway, middleware running on the gateway, and very low level tasks delivered directly on the roadmap (like stabilizing loops to make sure your robot never falls apart)
QUIC will be more than a replacement for TCP once we will have broken the speed boundary that allows a distant server to control a robot (which requires quick reaction speeds to correct for instability time constants). For now, everyone is forced to embark their decision algorithms on Jetson Nanos to control robots, which makes prices quite high, in a certain future where time frames will be optimized, we can see "Robotic controlling as a service" platforms, that will make the price of robots drop by a significant ammount
So what are you going to do when (not "if") your internet connection suddenly drops?
Unless you are okay with robots crashing into things at full speed, you'll always need some kind of local control loop, so full-remote control will never happen.
Offloading the goal decision to the cloud is very much possible, but that doesn't require an ultra-low-latency connection as (due to the above) the robot should be fine with no new feedback for a second anyways.
Decoupling between layers will be essential ! You will have high level commands sent from a distant server to a local gateway, middleware running on the gateway, and very low level tasks delivered directly on the roadmap (like stabilizing loops to make sure your robot never falls apart)
> Decoupling between layers will be essential!
You then don't need to "break the speed boundary".
Yeah I keep thinking that Reticulum & QUIC are the TCP/IP of the future.
[dead]