I am writing a Python program and would like to read and write the result of the program to a file, but I came across this difficulty in Robomaster S1. Is there a way to do this using Lab Python?

There is no justification for this limitation, I would suggest to DJI that the API allow this kind of manipulation, since most programs require some kind of file manipulation, from artificial intelligence to simple logging. Also, we have the memory card as a great feature to be able to use.

The big problem I see today in Robomaster S1, despite being an incredible promise, is exactly being limited in the Lab by the API. There needs to be more freedom from robot manipulation.

I am trying to implement a q-learning algorithm using Robomaster, but I have a hard time programming, because of the limitations that DJI has imposed, which are not Python limitations, let alone physical limitations of Robo.

Well, it is possible: delete, write, read




You just don't have access... my bad sarcasm aside: You are right. It should be possible without hacking the thing. This is one of my biggest complaints.

sevreNniarB Posted at 12-8 04:37
Well, it is possible: delete, write, read

That being said, if I was the one to vote, file reading/writing would be probably at the bottom of my feature request list. For the type of programs one is expected to run in the S1, this is simply not required.

BGA Posted at 12-9 09:07
That being said, if I was the one to vote, file reading/writing would be probably at the bottom of my feature request list.  For the type of programs one is expected to run in the S1, this is simply not required.

Imho everyone has personal preferences, use cases and priorities. The system should be open in the first place and there is no point closing it down like DJI did it. The maximum level of protection should be that we are able to flash back the system any time over USB... just in case, if something goes really south during our engineering journey.

The whole limitation, encryption and secrecy is pointless and the implementation is done badly anyway. The sandbox approach is wrong. I already said this many times: It just will keep advanced users away.

I find myself spending less and less time with my RMS1, because I don't have time to reverse engineer protocols, DLLs and all that stuff. It was fun at first, but know it's just getting more & more frustrating with every additional line of code I have to analyze...

It would be easy for DJI to publish some additional/unofficial documentation, e.g.:

"Here is how the UDP communication works, still work in progress/development draft and may change in the future… have fun with it and tell us what you're thinking..."

"Here is a procedure how to unlock the Python limitations. Please be aware that you may have to reinitialize your system when you mess things up..."

Cheers

sevreNniarB Posted at 12-10 01:04
Imho everyone has personal preferences, use cases and priorities. The system should be open in the first place and there is no point closing it down like DJI did it. The maximum level of protection should be that we are able to flash back the system any time over USB... just in case, if something goes really south during our engineering journey.

The whole limitation, encryption and secrecy is pointless and the implementation is done badly anyway. The sandbox approach is wrong. I already said this many times: It just will keep advanced users away.

Oh, don't get me wrong, I am all for the Robomaster S1 being fully open. I just happen to think that this is not a likely scenario, unfortunately. I do think things will improve considerably (as you are aware) but I guess things like direct filesystem access support will never officially be there (well, there might be support for reading/writing from the SD card eventually).

The reason I am working on an external API is bacuse I believe that if we can directly control the robot using the same level of access the Robomaster app has, than it should be enough to do amazingly cool things. Even without direct access to the S1 internals (well, we needed the access to get this going, but users of an external API would not need it).