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

I don't know why the WiFi disconnects periodically. I had four robots set up at an Expo, all using different IP addresses, and they all disconnected at some point. I would imagine free channels might vary depending on the location. At an Expo, for example, there can be 50+ exhibitors with all sorts of equipment connected with wifi, bluetooth, etc. However, the scanning tool you mention is something I will definitely try next time I take a robot somewhere and it disconnects.

Thanks for the update on HTML and ARC @DJ. I know you have spent a lot of time looking into this and given it a lot of thought.

hi @afcorson the 2.4GHz spectrum is pretty crowded and the EZB just has an onboard etched PCB antenna and doesn’t have an external antenna.  It support 802.11b/g/n You maybe using 802.11b that doesn’t handle interference very well (microwave ovens/ pass through interference/ metal in robots etc) .

What wifi router are you using?

You maybe better off with an onboard PC and 5GHz /external antenna for a more reliable connection but you can try 802.11g or n on EZB. Not sure what features you use on EZB and if ESP would work instead but some ESP also support external antennas.

there is a new ESP32-C5 coming out that supports 5GHz  I guess we can try that when it becomes readily available.   https://www.espressif.com/en/news/ESP32-C5

@afcorson That's actually quite normal. We've had connection problems at trade shows and expos ourselves. When the 2.4GHz spectrum becomes saturated it's difficult for any radio to stay connected. The amount of people with WiFi/Bluetooth devices in their pockets and every vendor connecting their booth to WiFi definitely saturates the environment and creates interference. The radio on the EZ-B does not use a high-power antenna, nor do laptops and phones, but one device that does is a WiFi Router. You could increase signal strength by placing your EZ-Bs into client mode and connect to them via a router to create your own local area network which will boost the signal by quite a bit and allow you to keep a solid connection to your EZ-Bs.

@ jeremie thanks for this I dont think I have ever connected my robots via Client mode...I'm thinking about having a dedicated router for just the robots. Thanks!