Internet access is optional, or can be intermittent.
If you use the cloud service (consumption based & optional) then you'll need internet access for configuration, logging, etc...
But if you lose connectivity, the robot will operate just fine until the TLS cert expires (always at least 30 days in the future).
Configs are cached locally so even a full robot reboot without internet access will work fine.
We think teleoperation is important as making perfect fully autonomous robots is incredibly hard, and by having humans in the loop, we can achieve much more tangible progress on real world problems.
Honestly, as someone who has been building robots full time for 7 years, I am struggling to guess which real world application use cases you are modeling your system design assumptions on and which alternative system architectures you believe you are delivering increased value against. Why don't you just describe them? It would be so much easier for people to grok what you're doing. The use cases section of your website lists is too meta to be useful. (PS. 'Modern' is not something people care for in most industrial use cases. In fact, they generally prefer 'reliable', 'well understood', 'cheap' or some combination thereof. You may wish to reconsider your marketing strategy.)
If you use the cloud service (consumption based & optional) then you'll need internet access for configuration, logging, etc... But if you lose connectivity, the robot will operate just fine until the TLS cert expires (always at least 30 days in the future). Configs are cached locally so even a full robot reboot without internet access will work fine.
We think teleoperation is important as making perfect fully autonomous robots is incredibly hard, and by having humans in the loop, we can achieve much more tangible progress on real world problems.