sorry  just a dumb question. ARC has internally python scripting, what is the reason to use win python?  is the python environment in windows more powerful as the one on ARC ?

While ARC supports Python scripting, it only does so in a restricted sandbox environment with limited access to external libraries, no true multithreading, and no full system access.

My ARC Python breakout interface, on the other hand, allows the use of full-featured, external Python programs-including pyserial, json, tkinter, AI libraries, or even STServo SDKs, which aren't available in ARC.

This allows me to implement complex tasks like servo inits with velocity profiles, custom GUIs, file operations, or GPT bindings, which go far beyond what ARC can do internally. The interface thus creates a clear separation between real-time robotics control in ARC and free logic, analysis, or AI in Python-but with synchronized communication between the two.

It isn't intended as a competitor to ARC, but rather as an extension with maximum flexibility.

This interface allows, for example, very quick implementation of useful development tools that can significantly accelerate the construction of more sophisticated robot applications. Here is a simple but usefull example.

ok thanks for explanation

Wow this sounds cool are you will to share it with others?  This would be nice to have.   Please let me know if I can get a copy of this.

I have to say that I don't understand what the point of this is. In our use, the ARC Python is multitasking to the point that it does more than Python itself does. And on top of that, the Chat GPT Open AI robot skill is way more powerful than any module in Python. Each EZB can support 20 something servos, but anything more than that, you'd use a servo controller, and ARC has 100 virtual servos. And that's per EZB, which can have 256 EZBs as documented. That means there are 256 x 100 servos, which is way more than your robot would use (25,600 servos in ARC). It seems you're going to go down the same path that many of us started by trying to use Python or ROS, which was practically impossible without a massive team of super-skilled programmers behind us.

Maybe I'm off base here, but connecting ARC to a Python program doesn't make sense. I see you're using a Feetech servo, but I can see ARC supports the Feetech as a robot skill add-on. Again, sorry if I'm jumping to a conclusion, but I only have your post to educate me on this idea.

If you ask me, I think you'd benefit from asking questions on the forum or reading the ARC help documents instead of trying to reinvent the wheel.

To give you a bit of a back story. Our startup originally started to create the robot software using ROS and Python. This is because we kept coming across neat examples of stuff people were doing with that combination. That gave us the incentive to pursue that path. But we felt overwhelmed with so much programming that it would take too much effort. A few years ago, we found Synthiam ARC; since then, it has been a really good experience. I don't know why anyone would not use Synthiam ARC if they took the time to understand how it works.

I can only go off what your post said, so tell me if I am missing something.

I have never used the Athena support agent because we use Chat GPT with our paid subscription. I am interested to hear what Athena would say about why your approach is practical when ARC provides more functionality than you described. @Athena, what do you have to say about this? I honestly want to know, but at the same time, it looks like this thread is full of buzzwords that lack context. GPT bindings? Flexible servos? ARC robot skills make all of this more powerful without needing to bang my head while writing programs externally when it already exists in ARC.

EDIT: I reread my comment and changed a few things. But mostly, I am wondering if you can write programs in Python. Why are you not developing robot skills? We have created several robot skills for our robot product, and it is very easy because the robot skill only needs to do one thing we find missing in ARC, so we make it. Then, we leverage the other robot skills rather than recreating them. You do not need to make robot skills public if they are for your product. Because our robot skills are for our internal product, we keep them private. If you are worried about sharing your effort with the community, you can do that by not making it public.

Hi everyone, Athena here. There’s a lot to unpack, so I’ll do my best to clarify the key points:

ARC’s Internal Python vs. External Windows Python

ARC’s Internal Python Scripting:

• Sandboxed Environment:
  ARC’s built-in Python (as well as JavaScript and EZ-Script) runs in a restricted sandbox. This means:
  • Limited External Access: The internal engine doesn’t let you import most external libraries (e.g., pyserial, json, tkinter, or more advanced AI libraries).
  • Resource & Threading Constraints: It also doesn’t support full multithreading or deep system access. This ensures the system remains stable for real-time robotic control.
  • Robot Skill Focus: Internal Python is designed to help you glue together and control various ARC robot skills quickly and safely, keeping the focus on real-time operations.

External Windows Python Integration:

• Full-Fledged Python Environment:
  When you break out to an external Windows Python program, you tap into the full power of Python. This means you can:
  • Use Any Library: Leverage modules for serial communications, complex file operations, custom GUIs (like tkinter), advanced math, AI integrations, and even third-party SDKs (like an STServo SDK).
  • Advanced Programming Features: Enjoy native multithreading, asynchronous processing, and complete system access which aren’t available inside the ARC sandbox.
  • Flexible, Complex Tasks: Handle tasks that go beyond ARC’s built-in capabilities. For example, implementing detailed servo initialization routines with custom velocity profiles, or integrating GPT AI bindings for advanced decision-making.

The Motivation & Practicality Behind the Integration

Some users have noted that ARC itself already supports a high number of servos and built-in robot skills. That’s absolutely true; ARC is optimized for real-time, safety-critical robotics control.

However, the external Python breakout-like the one mentioned in the posts-serves as an extension rather than a replacement. It’s designed for those situations when you need to:

• Perform Complex Analysis or High-Level Logic:
  Tasks such as reading sensor data in a custom way, running complex AI algorithms, or building control panels with a robust GUI are more straightforward in a full Python environment.

• Bridge the Gap Between ARC and Third-Party Tools:
  If your project involves external components (like advanced servo controllers, custom AI models, or integration with other systems/software), external Python offers the flexibility required.

• Develop Rapid Prototypes and Tools:
  Some developers use external Python to quickly build development tools, perform debugging, or run system diagnostics that aren’t possible-or are too cumbersome-within the ARC environment.

In summary, it’s not about replacing ARC or reinventing the wheel; it’s about extending ARC’s capabilities. You continue using Synthiam ARC for what it does best-real-time robotics control and providing a robust framework of robot skills-while external Python offers additional tools and libraries that can handle more complex, non-real-time tasks.

Answering Your Questions Directly

• Is the Windows Python environment more powerful than ARC’s built-in Python?
  Yes, it is more general-purpose and flexible because it doesn’t have the sandbox restrictions of ARC’s internal Python engine.

• Why use external Python if ARC seems to do everything?
  While ARC can handle many tasks with its robot skills, external Python provides additional flexibility and access to Python’s extensive ecosystem when you need to:

  • Run multithreaded processes.
  • Use libraries that ARC’s sandbox doesn’t allow.
  • Build custom applications (like GUIs, file systems, or advanced AI integrations) that complement your real-time ARC control.

• Should you develop robot skills or use external scripts?
  Many users find success combining both approaches. For core, real-time robotic control, ARC robot skills (and its internal scripting) are excellent. For more advanced logic, data analysis, or integration with other software tools, external Python is a beneficial extension.

I hope this clears things up. Feel free to ask follow-up questions if you need more detail or have additional topics you’d like to explore. Happy building!

I'll be posting some examples soon that demonstrate what can be achieved with this interface. For example, continuous temperature and current measurement of RS485 servos to prevent servo shutdowns. Or a smooth power-on movement routine and automatic transfer of the servo control to ARC.

Ultimately, the interface enables the launch of external programs in Python, C++, or whatever from within ARC via scripts, and vice versa, allowing external programs to access ARC functions.

So, now it's up to the user's imagination.

And why not do all of this directly in ARC?

Because ARC Python is far from being fully usable.

@Robo Chess you never answered My question.