@t.erin,  I read your post and wondered why you feel you should not share any of the skills with the rest of the users here.   Many of the skills here have been created by others.  This is what makes this a great platform as we all share with others to grow the hobby.

@smiller29

Yes, I'm happy to share the interface. However, it involves some Python and ARC scripts, and as the presentation suggests, a tool for setting up virtual COM interfaces is required. At the moment, I'm not sure how to send the files via the Synthiam platform? ZIP file? Perhaps a private method is easier? I'm currently traveling until the end of next week and won't have access to my software until then.

I have an idea after reading this thread. There are some good points made about the Python interpreter in ARC. While you can add libraries to it, there's some apparent limitations I think. I don't know why some libraries don't load into ARC Python, but it might be due to the Python interpreter. We identified that a native Python installation can't run multiple instances simultaneously, which is covered in the Python .NET module. However, I came up with a solution that I drew out to the team, and we're creating a new robot skill that runs a Python program using the native installed Python executable. That means the native Python executable you installed on your computer can be used with ARC using the new robot skill. The prototype created today looks like it'll be a good solution.

People are finding online Python programs to do a specific thing, such as maybe using C++ libraries with bindings, such as how feetech works. Feetech is the main reason for seeing this solution, the original poster aims for. Chat gpt and other Python libraries mentioned are not as powerful as the ARC robot skills, but using feetech servos is the primary reason for merging the two. So, while I can see a use case for using feetech (and perhaps other libraries), the mention of gpt "bindings" in Python being more powerful is not something I agree with. I suspect it's because finding an example on GitHub of someone doing something is easier than reading the ChatGPT manual and doing it easier in ARC.

So, the solution that we designed is to include a robot skill that uses the installed Python executable and provides bindings into the ARC framework. It'll take a few days, but I expect you'll see something soon. It's only useful to anyone who is experienced with writing the programs themselves in Python, but it provides leverage of ARC's framework.

Admittedly a bit late, but here are finally a few examples that show how you can use the ARC / Python interface effectively and what possibilities it opens up.

So DJ, have you made any headway on this feature in ARC?

What feature would that be? Everything in this thread in available in arc. The poster decided to replicate the features in Python instead of using existing robot skills. The OpenAI chat gpt robot skill, for example, can do far more as well - but you’d need to read the manual page for it.

Sorry DJ I was referring to post where you said you had some thoughts about the limitations in the ARC Python API.  It sounded like you may of had plans to make some improvements and I wondered if you had?

Hi everyone,

my initial motivation for building an ARC/Python interface was driven by the desire to utilize all the capabilities of Feetech and Waveshare servos.

This means accessing temperature, current, and position values, or adapting the baud rate to the servo type.

For example, the big Feetech SM-1500-C001 ( 115200 baud) can now be controlled with the Feetech skill in conjunction with the baud rate converter in the interface without adapting the servo skill.

This allows overload situations to be detected early and mitigation measures to be implemented programmatically. This already works very well and can be seen in the video.

Furthermore, I really appreciate the creative freedom of Python with its full range of functions and numerous modules/libraries, and combining these with the real-time kernel in ARC. At least when no suitable skill is available in ARC. Hardware manufacturers often offer SDKs or Python drivers for their hardware that can be used directly via the interface.

It is certainly true that this can lead to duplication, i.e., solutions that would also be possible directly in ARC. However, the ARC Python interpreter is proprietary and differs significantly from the current Python standard.

This is roughly how I see the division of responsibilities in my applications: ARC = "make this verified movement safe" Python = "decide wisely when and which movement."

Robustness & Security: Python crashes? ARC keeps the last stable action; ARC has emergency stop/whitelistable action names.

Maintainability: ARC actions remain the same, Python logic can grow (new heuristics/models) without risking the motion sequences.

Performance & Latency: Heavy AI/analysis in Python; real-time servo processing in ARC. No blocks/GC pauses in the motion loop.

Scalability: Multiple Python processes (watchdog, listener, temp monitor) a clear, lean ARC motion endpoint.

That's why I remain a big fan of ARC love, and with the interface, I feel even freer and faster to develop new robot applications.

I hope my contributions can inspire others to continue experimenting in this direction.

From time to time, I think about ROS and have even implemented a few smaller examples. But ARC is definitely much faster, easier to implement and more robust. Requires more hardware performance, though.

Besides, I'm not a Linux fan.:p