WHAT'S NEW
Added Conquest Mode to Battle. Teams compete to occupy bases using visual recognition.
Added Intercom. Users can record sounds on the app and play them on the S1. Note that this feature requires your authorization to access the microphone of your mobile device.
Added Master Board. A feature of the new Mastery Tracker system. *
Added Drifting and Lightning Strike to Road to Mastery.

* Firmware version of v00.05.0046 or later is required.

Firmware:
Added support for SBus port.


All in all, seems a bit underwhelming (as we already knew most of the stuff). The SBus port support might be interesting.

Right now, the Windows and IOS apps were not updated yet.

Hello and good day BGA. Thank you for sharing these information with us today and thank you for your support.

I'm a bit worried to update the Firmware, because it could potentially stop the reverse engineering process - is everything still working @BGA?

Cheers

I did not update it yet. But I have 2 s1s so I can test on one first.

"The SBus port support might be interesting."
Hopefully so.
SBus can be almost as useful as a normal UART.
This should allow other microcontrollers to interface with the S1.
I've written a SBus parser for the Propeller microcontroller. I'm pretty sure there are Arduino SBus parser out there as well.
I'll try to check this out today.
Thanks for the heads up about it.

sevreNniarB Posted at 11-29 09:20
I'm a bit worried to update the Firmware, because it could potentially stop the reverse engineering process - is everything still working @BGA?

Cheers

Everything still works.

BGA Posted at 11-29 07:49
Right now, the Windows and IOS apps were not updated yet.

The Windows PC program download has been updated and the macOS version uploaded as of 3h45pm EDT.

Duane Degn Posted at 11-29 12:10
"The SBus port support might be interesting."
Hopefully so.
SBus can be almost as useful as a normal UART.

The programming guide was not updated and I did not notice anything new in the API to use the SBUS. Let me know if you find anything.

BGA Posted at 11-29 13:37
The programming guide was not updated and I did not notice anything new in the API to use the SBUS. Let me know if you find anything.

You should find a reference in the DJI.JSON, also duml_cmdset.py should have something in it. Please note that DUSS_MB_CMD_FC_SBUS_PACKET = 0xAA was already available in the last version, this is maybe not the new stuff we are looking for.

I will unpack the firmware later. It is encrypted so it will take me some time to decrypt it & search the files.

Cheers

I'm not sure exactly how this "S-Bus Support" will be made available to the ploebe!!! There are no new Scratch blocks related to this...
Has anyone found new Python functions for this port?

sevreNniarB Posted at 11-29 14:03
You should find a reference in the DJI.JSON, also duml_cmdset.py should have something in it. Please note that DUSS_MB_CMD_FC_SBUS_PACKET = 0xAA was already available in the last version, this is maybe not the new stuff we are looking for.

I will unpack the firmware later. It is encrypted so it will take me some time to decrypt it & search the files.

Could not find anything specifically related to that. It might just be that they enabled the SBUS port but did not expose it through the API.

rhoude57 - YUL Posted at 11-29 14:03
I'm not sure exactly how this "S-Bus Support" will be made available to the ploebe!!! There are now new Scratch blocks related to this...
Has anyone found new Python functions for this port?

Nothing so far.

Here is what's new:

• Protocol Parser & Plaintext SDK
  Don't know what this is... need to look at the code
  protocal_parer_ctrl = protocal_parser.ProtocalParser(event_dji_system)
  
  
• New Command Sets
  DUSS_MB_CMD_RM_SDK_MODE_SET = 0xD1
  DUSS_MB_CMD_RM_STREAM_CTRL = 0xD2
  
  
• Tons of changes in the Control module, like:
  self.attitude_status_dict['static_flag']
  self.attitude_status_dict['uphill_flag']
  self.attitude_status_dict['downhill_flag']
  self.attitude_status_dict['on_slope_flag']
  self.attitude_status_dict['pick_up_flag']
  self.attitude_status_dict['slip_flag']
  self.attitude_status_dict['impact_x_flag']
  self.attitude_status_dict['impact_y_flag']
  self.attitude_status_dict['impact_z_flag']
  self.attitude_status_dict['roll_over']
  self.attitude_status_dict['hill_static']
  self.sdk_applause_event_push_enable
  
  
• Internal ToDo List
  TODO LIST:
  1. add framework doc
  2. add plaintext sdk doc
  3. add custom UI doc
• Some stuff is mapped to
  WIFI_DIRECT_CONNECTION_IP = '192.168.2.1'
  WiFi direct was only used in the old FW when a USB WiFi stick was plugged into the S1
• More stuff under the hood, like drivers, the DUML interpreter, boot image and so on...
  

Cheers

sevreNniarB Posted at 11-29 15:31
Here is what's new:

Yeah, I juts posted about it. I noticed the plaintext SDK. Not sure if it is already possible to use it but at least all the specific ports are listed there. Let the games begin!

BGA Posted at 11-29 15:34
Yeah, I juts posted about it. I noticed the plaintext SDK. Not sure if it is already possible to use it but at least all the specific ports are listed there. Let the games begin!

There is a "debug folder" and you need to mkdir it (you will find it in the code), if it is present and the debug sdk variable is set to true it should work... problem is the damn watchdog. If you change the file, the checksum is different and the damn thing will reboot & initialize the S1 ^^

BGA Posted at 11-29 15:34
Yeah, I juts posted about it. I noticed the plaintext SDK. Not sure if it is already possible to use it but at least all the specific ports are listed there. Let the games begin!

Relevant ports in case someone wants to play with it:

Stream Port (video stream?): 40921
Control Port (robot control?): 40923
Push Port (?): 40924
Event Port (for callbacks?): 40925
Broadcast Port (probably for detection and pairing): 40926

I like where DJI is going with this!

It is in the dji_scratch.py

sys.path.append('/data/dji_scratch/src/robomaster/plaintext_sdk')
import protocal_parser

LOG_STREAM_OUT_FLAG = True
SDK_DEBUG = False


if SDK_DEBUG:
    protocal_parer_ctrl.init()
else:
    # CHECK SDK ENABLE
    if os.path.exists('/data/SDK_ENABLE'):
        protocal_parer_ctrl.init()

If the path is there it should work without manipulating the .py file...

sevreNniarB Posted at 11-29 15:38
There is a "debug folder" and you need to mkdir it (you will find it in the code), if it is present and the debug sdk variable is set to true it should work... problem is the damn watchdog. If you change the file, the checksum is different and the damn thing will reboot & initialize the S1 ^^

It appears you can also enable it by simply doing:

touch /data/SDK_ENABLE

I think this is less likely to result in a reinit. Will try later.

sevreNniarB Posted at 11-29 15:45
It is in the dji_scratch.py

sys.path.append('/data/dji_scratch/src/robomaster/plaintext_sdk')

It looks like we are racing to figure out who can find what first. ;) In any case, i am just happy that we found this.

BGA Posted at 11-29 15:47
It appears you can also enable it by simply doing:

touch /data/SDK_ENABLE

It seems to have worked (no reinit). Also, it persisted after a reboot. Now to check if it is really doing something.

BGA Posted at 11-29 16:09
It seems to have worked (no reinit). Also, it persisted after a reboot. Now to check if it is really doing something.

And it works!

$ go run udp_server.go
Data from 192.168.86.129:58010 : 726f626f74206970203139322e3136382e322e31
Data from 192.168.86.129:58010 : 726f626f74206970203139322e3136382e38362e313239
Data from 192.168.86.129:58010 : 726f626f74206970203139322e3136382e38362e313239
Data from 192.168.86.129:58010 : 726f626f74206970203139322e3136382e38362e313239
Data from 192.168.86.129:58010 : 726f626f74206970203139322e3136382e38362e313239
Data from 192.168.86.129:58010 : 726f626f74206970203139322e3136382e38362e313239
Data from 192.168.86.129:58010 : 726f626f74206970203139322e3136382e38362e313239

This is just an HEX dump of the messages being sent on the broadcast UDP port. Now to parse it .

BGA Posted at 11-29 16:14
And it works!

$ go run udp_server.go

Ok, that was fun... Parsing it was easier than I thought. ;)

$ go run udp_server.go
Data from 192.168.86.129:44379 : 726f626f74206970203139322e3136382e322e31
As string: "robot ip 192.168.2.1"
Data from 192.168.86.129:44379 : 726f626f74206970203139322e3136382e38362e313239
As string: "robot ip 192.168.86.129"
Data from 192.168.86.129:44379 : 726f626f74206970203139322e3136382e38362e313239
As string: "robot ip 192.168.86.129"
Data from 192.168.86.129:44379 : 726f626f74206970203139322e3136382e38362e313239
As string: "robot ip 192.168.86.129"
Data from 192.168.86.129:44379 : 726f626f74206970203139322e3136382e38362e313239
As string: "robot ip 192.168.86.129"
Data from 192.168.86.129:44379 : 726f626f74206970203139322e3136382e38362e313239
As string: "robot ip 192.168.86.129"

i.e. the actual message sent is "robot ip IP".

BGA Posted at 11-29 16:18
Ok, that was fun... Parsing it was easier than I thought. ;)

$ go run udp_server.go

Wow, plaintext... dreams come true



If we could send stuff it should be easy from there, because we have the parser duml code, the internal routes, sender-id, etc.

sevreNniarB Posted at 11-29 16:27
Wow, plaintext... dreams come true

Yep. Working in it next.

BGA Posted at 11-29 16:57
Yep. Working in it next.

Is your Battery level also at 0% when in SDK mode?

sevreNniarB Posted at 11-29 17:28
Is your Battery level also at 0% when in SDK mode?

You mean in the Robomaster app? I did not check but it is possible as sdk mode changes some of the code paths and is also obviously incomplete.