Scratching more and more into the RoboMaster S1 and its app/PC program, I have come to wonder if the eventual intent of using the Unity gaming development environment would not be twofold:
1) provide a simulated gaming environment for any of the supported Solo or Battle games; and
2) provide a simulated environment to test Scratch or Python programs in the Lab environment.

It would be possible, but like I mentioned in my other post: the heavy lifting of the Code is done locally on the S1 (it's running Android 4.4 & Python 3.6). There are "utilities" like UnityRemote and other stuff to get Python working in Unity. DJI uses UnityBridge (which is highly experimental) why shouldn't they use something like UnityRemote? ;)

I'm more of an Unreal Engine person and I've worked in my spare time on some VR stuff. A Robomaster S1 battle/code 3D simulator would need some real development power on their side and lots of the internal functionality would have to be rebuild in C# from scratch. You would need abstraction layers for the hardware, link it back to Python, a Lab code interpreter that is much more than just a dumb terminal, ...

Imho they used Unity for its cross-platform abilities & licenses are a steal Maybe we will see some fan-projects in the future? Prerequisite: DJI gives up the current sandbox approach, but AES encrypted .DSP files and a crippled Python environment are usually not a good sign for "do/code what ever you want...".

Cheers

sevreNniarB Posted at 11-11 18:59
It would be possible, but like I mentioned in my other post: the heavy lifting of the Code is done locally on the S1 (it's running Android 4.4 & Python 3.6). There are "utilities" like UnityRemote and other stuff to get Python working in Unity. DJI uses UnityBridge (which is highly experimental) why shouldn't they use something like UnityRemote? ;)

I'm more of an Unreal Engine person and I've worked in my spare time on some VR stuff. A Robomaster S1 battle/code 3D simulator would need some real development power on their side and lots of the internal functionality would have to be rebuild in C# from scratch. You would need abstraction layers for the hardware, link it back to Python, a Lab code interpreter that is much more than just a dumb terminal, ...

What I have seen done to work around the native RMS1 code is to host the Intelligent Controller on a QEMU émulator.

The Unity code then interacts with the QEMU hosted code as it would with the real RMS1. One instance of the RMS1 could run on the QEMU emulator whereas the other, simulated, RMS1s in the scenario could run using Unity supported logic or AI. Alternately, multiple machines could be networked together into Battle scenarios.

There are actually lots of references to an internal simulator in the S1 code so I am pretty confident this already exists. It is juts not public (yet?).