The native Python robot skill wasn’t completed. But it’s mostly working. I think the reason is it didn’t jump out to us as a useful addition. I can have it pushed out to see what can be done. But the thing is, only one copy of it can run. That means you have to add the entire Python code into one editor. It becomes a large unmanageable code. That’s what I try to avoid - but if it’s useful I guess we can finish it.

what I’d like to see is events from the Python script. For example, when servos move in ARC to have an event called for the Python script. Python is kinda weird with events. It’s not implemented naturally and we’d have to do more research to find a usable approach that’s dynamic enough to be useful.

but to be clear.. I don’t think we have a full grasp on how to implement the two environments. It would take time to figure that out.

Virtual COMs: The Door to the Outside World

Fundamentally, I don't believe that full integration of Python into ARC is necessary or even useful. Although Python is quite popular, especially with regard to AI, there are of course other interesting languages that could be considered.

With the "breakout interface" discussed above, it is easy to initiate ARC scripts, actions, and direct servo movements from outside ARC and conversely, to initiate ARC-external processes, in my case, Python programs from within ARC.

In addition, the servo commands from ARC are not sent directly to the real hardware COMs, but rather via virtual COMs to Python "servo routers" outside ARC. The "servo router" can access the servo controller directly via the hardware COM, route ARC commands directly, or, for example, adjust the baud rate, or query servo information such as temperature values, current values, etc., and communicate this back to ARC.

In principle, that's all there is to it, but these communication channels open up many interesting applications.

For example, selected ARC actions can be provided to GPT in a JSON file with aliases and runtimes. Using a prompt, GPT can then automatically and contextually select an action/movement from this library and thus control a robot independently. This isn't a best-fit process, but rather GPT's "free decision." Sometimes it's funny,  sometimes it's frustrating.:(

The idea pool for implementing interesting applications via the interface is brimming, especially since there are so many ARC skills that can also be used with external programs and vice versa.

Here are a few examples of what this might look like in ARC.

# ARC_Kommunikator_Control_Com32.py

import json

port = "COM32"
baud = 115200

if not COM.isPortOpen(port):
    COM.open(port, baud)

print("Kommunikator gestartet auf COM32 (nur noch ControlCommand) ...")

while True:
    if COM.available(port) > 0:
        try:
            daten = COM.readLine(port).strip()
            print("[Empfangen]:", daten)

            setVar("$exec", daten)
            ControlCommand("ARC Executors", "ScriptStart", "ARC_Executor_Action.ez")
        except Exception as e:
            print("[Fehler beim Empfang oder Verarbeitung]:", e)

    sleep(200)

And this is the appropriate executor.

# ARC_Executor_Action.ez

$feedback_file = "C:\\Users\\Rainer\\AppData\\Local\\GPT_Robo_Controller_V1\\arc_status_feedback.txt"

if ($exec != "")
  $feldzahl = Count($exec, "|") + 1

  if ($feldzahl = 3)
    $arg1 = Split($exec, "|", 0)
    $arg2 = Split($exec, "|", 1)
    $arg3 = Split($exec, "|", 2)
    ControlCommand($arg1, $arg2, $arg3)
    FileWrite($feedback_file, "OK: Action ausgeführt - " + $arg3 + "\n")

  ELSEif ($feldzahl = 2)
    $arg1 = Split($exec, "|", 0)
    $arg2 = Split($exec, "|", 1)
    ControlCommand($arg1, $arg2)
    FileWrite($feedback_file, "OK: Skript gestartet - " + $arg1 + "\n")

  ELSE
    FileWrite($feedback_file, "FEHLER: Ungültiger Befehl - " + $exec)
  endif

  $exec = ""
endif

Here is an example of how to organize virtual COMs. But there are also alternative approaches:

Results: Virtual COM interfaces for communication with and from ARC are well-suited to making ARC even more effective and flexible without having to develop new ARC skills.

ARC skills can certainly be more useful in some cases, such as functional skills for serial servos with full support for all servo properties. But the example shows, that there are other ways to achieve the goal. The concept isn't exclusively focused on Python. It can be combined with almost any language.It's simple, a bit old-fashioned, robust, and I find it practical.

Perhaps it makes sense to consider a data exchange (read/write) skill. The setup could include COM, baudrate, format (JSON, CSV, etc.), and polling frequency.

It should be easy to use without any programming knowledge, just like the ARC philosophy.

If it's interesting for the community, I'd be happy to post more implementation examples.

With that in mind, have fun! cool