There’s a few options here: https://synthiam.com/Support/Tips-to-Make-a-Robot/headless-robot-sbc

Oh and also the Oculus Quest robot skill has a built in Remote Desktop utility if you end up going that route: https://synthiam.com/Support/Skills/Virtual-Reality/Oculus-Quest-Robot?id=21158

Thanks for the info. Interesting reading. However, I do want to avoid using the internet for remote control of the PC inside the robot. Internet may not available at the venue where I set up. Also I might be using it for a Chatbot.

You won’t need internet for those options. You will need wifi, however. So wifi between your computer and robot will be on the same network if you’re next to the robot. The only time an internet connection is used is when you’re at a remote location.

now, another option if you want a wired connection is to plug an Ethernet cable between the robot computer and your remote computer. That will be a direct wired network connection

As DJ recommended Tight VNC is probably your best option but I also just use windows remote desktop app to control my robots when they have an on windows board PC.

I would love to eventually see ARC migrate to HTML5 UI so we can use a browser (We have had some long conversations about GUI issues and converting  ARC .net to a HTML GUI in the past).

The most significant issue we experienced with research to have an HTML UI is performance. A single instance of a browser generally consumes 500-1GB of RAM for a basic webpage. The complexity of rendering a thousand+ UI elements would not only consume 100% CPU (just for the UI) but also use all available ram (just for the UI). Meanwhile, the UI would need to talk to a server that performs the robot skill processing and data for the UI elements.

We also had an issue with 3rd party robot skill development. The HTML integration would require the advanced coding ability for developers to implement and maintain web calls and UI elements. This means 3rd party robot skill developers would need to create both the client and server add-ons, doubling their workload. In addition, they'd need to use multiple programming languages between the JavaScript and HTML front-end and whatever the back-end would be. They would also need to follow strict CSS rules but could override the entire workspace if desired.

Another issue we experienced was network latency to synchronize all robot skill elements within a reasonable time. One test had a web service fail for a poorly written example of 3rd party robot skill, and it stopped the entire UI.

While HTML offers excellent convenience for many lightweight and non-realtime applications, it's still a development-hungry and volatile environment when pioneering new use cases.

I would love to see ARC HTML-based with a static server - but the browser and backend are still experiencing a hundred degrees of separation. Many attempts to resolve that with Ruby and others have demonstrated some success at lightweight web apps. Still, power-hungry applications have large teams dedicated to maintaining their stack (Facebook, youtube, etc.)

Take adobe photoshop, for instance; that is experimenting with Adobe Photoshop Online (it's in Beta). Firstly you'll notice how lightweight by missing over 90% of its features considering there's a HUGE development team behind it. And not only that, but it's missing all effects due to the lack of "plug-in" support - which is one of the most vital elements attributed to Photoshop's success. No one has quite figured that part out yet with a browser client/server solution.

So, we've been looking into it and will continue to do so. We also keep an eye on Linux binaries and .Net 6 with Maui UI for "somewhat" cross-platform. Of course, Linux is still a nightmare, and supporting our customers even to install the OS is FAR more work than using ARC. And Maui executes "apps" in a container that isolates the binary from dynamically loading 3rd party libraries (i.e., plugin robot skills).

One day we'll see an OS or company create a REAL cross-platform development environment that can develop apps more advanced than scrolling TikTok or social media calendar books. The Xamarin-style cross-platform UI tools remind me of people making recipe or phone book programs in Basic on their Commodore 64 back in the day. They find the "most common use-case" and create the development environment for that. But that, unfortunately, excludes the requirements of the uniqueness of Synthiam ARC.

More interesting reading. But I am thinking, if WiFi connection to an EZB tends to occasionally disconnect, then a WiFi connection to a controlling PC for a 'headless' robot may not be any more reliable. To me something like the AVA wirelessHD touchscreen which uses mmWave technology (whatever that is) with zero latency, is a game changer. A 'headless' robot could be controlled via this 4K touchscreen and possibly more than one robot at a time. Might have to wait a while for the product to be available and affordable. https://synthiam.com/Community/Questions/Remote-Control-of-hard-wired-EZB4-21289

Do you know why the wifi is disconnecting? That might be a good start to fix first. Even my telepresence robot that can explore the whole office will never disconnect from wifi.

There’s a good tool in the support section for scanning wifi to find a free channel. Check the section for wifi channel/signal scan on this page: https://synthiam.com/Support/troubleshooting/Troubleshoot-WiFi-Connections